svn rev #23611: trunk/src/lib/crypto/crypto_tests/

[Ezra Peisach]

I love replying to myself...

Anyways - I have trapped enctype = 0 i the key freeing code and can say 
except for the kdc fast code handling - in which enctype = 0 and length 
= 0 (which is ENCTYPE_NULL) - the tree runs now w/o enctype problems.  
So - I believe that unless someone is setting up a krb5_keyblock 
manually - everything is consistent.

Ezra

On 01/08/2010 07:59 AM, Ezra Peisach wrote:
> I spoke too soon...
> I added an assertion in the free code to see if enctype was 0...  Get 
> hit in a number of programs...  The kdc in verify_checksum from the 
> kdc_find_fast.  I think it using an empty krb5_keyblock - with zero 
> length - so in theory
> who cares about the encryption type...
>
> I also found another problem in krb5int_dk_string_to_key creating a 
> key w/o enctype - but that will be fixed soon...
>
> Ezra
>
>
> Ezra Peisach wrote:
>> The places that I   have seen problems with have to deal with
>>
>> a) crypto test programs
>> b) internal crypto functions - yarrow and derive key
>>
>> In both cases it is because we know what is happening under the hood. 
>> The (b) issues are easy fixes - the derive key problem was reported 
>> by Doug in 2001 (ticket 959) and the other is because we are using 
>> internal functions w/o full initialization.
>>
>> The problem will manifest itself in one of two ways... The easy to 
>> track down one is that valgrind will report a conditional jump based 
>> on an uninitialized variable.  However, if someone initializes the 
>> enctype to 0 - using the aes internal encryption code - will result 
>> in a memory leak.  I know that the test programs in the crypto 
>> libraries do not leak memory as I have fixed those over the years - 
>> so when leaks showed up in test-aes it was obvious.
>>
>> That said, I have run the test suite under valgrind - and right now 
>> (from what I can see) is that the only complaints about conditional 
>> jumps on uninitialized values is in the ssl code from the pkinit 
>> preauth plugin. (I do not know if this is a problem w/ the plugin or 
>> the ssl library).  This however produces a large amount of noise in 
>> the tests that I might have missed something.  I also cannot tell if 
>> there are problems w/ an enctype = 0 leaking memory.
>>
>> I believe however, that external interfaces to the crypto library do 
>> require a valid enctype - and this should be fine - unless
>> someone has cheated somewhere else.
>>
>> Ezra
>>
>> Ken Raeburn wrote:
>>> On Jan 7, 2010, at 22:43, epeisach at MIT.EDU wrote:
>>>> The key caching is causing memory leaks if enctype is not set as the
>>>> enctype specific cleanup handlers are not called.
>>> Are there likely to be many cases outside of enctype-specific test  
>>> programs where this shows up?  If so, perhaps we (I?) should make 
>>> the  caching dependent somehow on having a suitable enctype value 
>>> set.  But  currently that level of the code doesn't need to know 
>>> about Kerberos  enctype number assignments...
>>>
>>> Ken
>>> _______________________________________________
>>> krbdev mailing list             krbdev at mit.edu
>>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>
>> _______________________________________________
>> krbdev mailing list             krbdev at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/krbdev
>