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

[Ezra Peisach]

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
>