search

turiya / keyczar

Automatically exported from code.google.com/p/keyczar
0 stars 0 forks source link

Key sets by kind (symmetric, public, private) vs by algorithm #121

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Keyczar currently can only have one encryption algorithm per key set. This 
presents a user unfriendly issue that doesn't seem to go with the 
KeyczarPhilosophy as an algorithm may be a appropriate at the time, in the 
future it may not, and then the user is stuck without changing out their keyset 
completely as opposed to rotating a new algorithm in.

It was mention in issue 17, by bleichen@goog that Keymaster does not have this 
limitation. 

Design wise because of the algorithm encapsulation in keyczar, changing this 
behavior is not that difficult. Really only the metadata has to change, as the 
KeyType can be stored in the KeyVersion of the KeyMetadata. This is a small 
format change, and still provides the KeyType information for Key json 
deserialization in the same place for Keyczar.

Additionally, keysets need additional algorithm separation, separating 
symmetric and asymmetric algorithms and then public and private key material. 
Using (SYMMETRIC,PRIVATE,PUBLIC) along with purpose in the KeyMetadata allows 
for much of the same checks that having a one KeyType per KeyMetadata, just 
more generalized.

I've made a commit on a separate branch on the C# keyczar that demonstrates 
these proposed changes and passes all of my 534 unit tests.  

https://github.com/jbtule/keyczar-dotnet/commit/ac81a543fff0383da6dbeafa51459127
35988adb

To keep things simple, I support reading the original KeyMetadata, and only 
write the new KeyMetadata.  I added a format version identifier to KeyMetadata 
as well as adding the KeyKind(SYMMETRIC,PRIVATE,PUBLIC) and moving the KeyType 
for the new version. The biggest change for the user is in the KeyczarTool as 
the defaults override for KeyType is in "addkey" instead of "create". I also 
added a new KeyczarTool command "keytypes" to list the KeyTypes and sizes 
supported by the implementation organized by purpose and kind.

This will make keeping current with "reasonable algorithms and sizes" much 
easier for both developers and users of the Keyczar framework, as it makes it 
easier to add new algorithms too as suggested by bleichen@goog in issue 17.

Original issue reported on code.google.com by jtu...@gmail.com on 28 Jan 2013 at 2:28