etypes - weak vs medium vs strong

Ken Raeburn raeburn at MIT.EDU
Mon Apr 6 19:46:03 EDT 2009

On Apr 6, 2009, at 18:36, Zhanna Tsitkova wrote:
>> I was looking @ etypes.c and found that some of the enc types are
>> marked as ETYPE_WEAK ( des-cbc and friends ) while the others are
>> not classified at all. I think it would be a good idea to
>> categorize  them as weak-medium-strong and in the config file allow
>> to indicate just a type, for example
>> default_tgs_enctypes = ETYPE_HIGH

I'd be concerned with backwards compatibility if the definition of  
"ETYPE_HIGH" changes across releases.  The issue exists even with weak  
vs non-weak, but adding more gradations gives more opportunity for  
problems.  I'm not sure that's a big problem though, compared to the  
ability to say, "*this* machine/service/whatever requires use of the  
strongest encryption systems we've got".

>> High - AES128-AES256  - key length > 128
>> Medium - 3DES - key length == 128 bits    ( currently, our's des3-
>> cbc-raw  is  ETYPE_WEAK)
>> Low - DES  - key length < 128

The 3DES we use has a key length of 168 bits, longer than AES128,  
though by some measures the strength is only 112 (twice that of DES).   
Also, note that des3-cbc-raw is not an encryption type you'd use in  
Kerberos -- the "raw" encryption (without integrity protection) was  
stuck in using the same interface as integrity-protection encryption,  
and only the latter should be used in Kerberos.  And it's only there  
for DES and triple-DES, not for AES or RC4.  I think in an API  
redesign, the two types of functionality (encryption with vs without  
integrity protection -- and similarly keyed vs unkeyed hashes) should  
perhaps be made separate interfaces, to remove any possibility of  

Triple-DES with a SHA-1 HMAC is not marked as weak.


More information about the krbdev mailing list