key hash collisions are not handled the same across implementations

[GoogleCodeExporter]

key hash collisions are not handled the same across implementations

Python version regenerates a random key to avoid collisions in a keyset,
but if loading a keyset that did have a collision would just overwrite
http://code.google.com/p/keyczar/source/browse/python/src/keyczar/keyczar.py#192
http://code.google.com/p/keyczar/source/browse/python/src/keyczar/keyczar.py#69

C++ version also regenerates a random key to avoid collisions, and
fails to add additional keys that collide on read
http://code.google.com/p/keyczar/source/browse/cpp/src/keyczar/keyset.cc#171
http://code.google.com/p/keyczar/source/browse/cpp/src/keyczar/keyset.cc#138

java version does not guard against generating collisions, and
overwrites the existing key in hashmap
http://code.google.com/p/keyczar/source/browse/java/code/src/org/keyczar/Keyczar
.java#131
http://code.google.com/p/keyczar/source/browse/java/code/src/org/keyczar/Keyczar
.java#102


Each version should handle should handle keys with collisions consistently with 
other versions so that a keyset with collisions would have the same behavior 
when used by any versions. 

I also think that since each version also has the feature to import keys, which 
in a collision case could only stop importing in a non end user useful way, 
that they should handle key collisions as acceptable, I have this implemented 
in the C# version. In which the get a key from a hash returns a list of any key 
that matches the hash and that list is looped through during 
decryption/verification until authentication/verification is successful similar 
to how an UnversionedVerifier works in other implementations but over a subset 
of keys rather than the whole keyset.

http://code.google.com/r/jtuley-dotnet/source/browse/dotnet/Keyczar/Keyczar/Keyc
zar.cs#156
http://code.google.com/r/jtuley-dotnet/source/browse/dotnet/Keyczar/Keyczar/Cryp
ter.cs#95
http://code.google.com/r/jtuley-dotnet/source/browse/dotnet/Keyczar/Keyczar/Veri
fier.cs#146

Original issue reported on code.google.com by j...@tuley.name on 22 Oct 2012 at 4:11

[GoogleCodeExporter]

Added support to python for handling key collisions.

Unit Tests for crypt and sign with data using a collided AES Key and collided 
Hmac key
http://code.google.com/r/jtuley-python-collisions/source/detail?r=3debcb276d50e6
367d77465b18db44baaf129024

Patch that supports decrypting and signing when key hash collisions occurs.
http://code.google.com/r/jtuley-python-collisions/source/detail?r=d1426443944ce1
8d54da4df0739cc31b8dae2c8d

I had to omit the stream decrypt, because it requires giving a chunk and 
getting a chunk back and that isn't possible when you aren't sure which key is 
which.

Original comment by jtu...@gmail.com on 6 Feb 2013 at 4:26

[GoogleCodeExporter]

Original comment by jtu...@gmail.com on 2 Mar 2013 at 9:16

• Added labels: Type-Patch, Implementation-Java, Implementation-Python, Implementation-Cpp
• Removed labels: Type-Defect

[GoogleCodeExporter]

Has this implemented and tested for Java, Python2 & 3 in

https://code.google.com/r/jtuley-keyczar-dev/

Also implemented and tested in C# and Go

Testdata for Aes, Hmac, Dsa, Rsa, and Rsa-sign located under special case of

https://code.google.com/r/jtuley-keyczar-testdata/

Original comment by jtu...@gmail.com on 4 Jul 2013 at 4:32

• Changed state: Started

[GoogleCodeExporter]

Are there plans to add this functionality? Given the wiki at 
https://code.google.com/p/keyczar/wiki/KeyHash pretty definitively states that 
"Keyczar implementations will handle collisions by exhaustively trying all keys 
with the same key ID" I had mistakenly thought this was supported.

Reading the current code, for java at least, shows that this is not, in fact, 
supported

Original comment by jaco...@gmail.com on 24 Sep 2014 at 4:40