Deprecating Keyczar?

[Steve Weis]

Keyczar is getting out of date to the point where I think it might be time to deprecate it. It is still using SHA-1, doesn't support GCM, and doesn't support ECC algorithms by default. It only supports DSA and RSA, and I wouldn't use either for new code.

There doesn't seem to be much activity or drive behind Keyczar. Shawn Willden is doing almost all the Keyczar maintenance on his own. Otherwise, Google seems to be using the internal Keymaster on BoringSSL for new projects. I know there was a K2 project in the works at one point, but that seems to have died.

Without a driving force to push new development, I think it would be hard to modernize implementations in three different languages while maintaining backward compatibility.

I would probably deprecate Keyczar and suggest that users start migrating to something else. Unfortunately, I don't have a drop-in suggestion to replace it. I'd probably use libsodium with some Keyczar-like key versioning.

I might be off-target if there are people who depend on Keyczar. If that's the case, those users should probably come up with a plan to modernize Keyczar and at least deprecate outdated modes and algorithms.

I'd be happy to talk about potential replacement designs if anyone were interested.

[Will Sargent]

Is there any word about K2?

Will.

--
You received this message because you are subscribed to the Google Groups "Keyczar Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keyczar-discu...@googlegroups.com.
To post to this group, send email to keyczar...@googlegroups.com.
Visit this group at https://groups.google.com/group/keyczar-discuss.
For more options, visit https://groups.google.com/d/optout.

[David Norman]

I tend to agree (and poor Shawn being on his own all these years).

I know Andrew, Shawn and I had grand plans to do a rewrite for K2, but we all got busy with other projects and various start-ups. With Andrew back at Google he may have more time than the rest of us, so will let he and Shawn chime in. It would be great to get the rewrite under way since I have several of my own uses I could use keyczar for, but just don't have the time.

--

You received this message because you are subscribed to the Google Groups "Keyczar Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to keyczar-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to keyczar-discuss@googlegroups.com.

[Will Sargent]

Okay, K2 has died.  

I know that there’s a couple of libraries based on libsodium, and I’ve been using Kalium in a couple of projects.

The key management is the really interesting part of Keyczar to me — I don’t know of any other OSS tool that does quite the same job.  Would it be possible to add it as a layer on top of Python Cryptography or a libsodium-type library, and focus on the higher end crypto parts of things?

Will.

[Jay Tuley]

I have had similar thoughts of a libsodium with keyczar-like keyversion. Possibly using something like flatbuffers instead of json for the keystore, just to reduce the amount of keydata thrown about when deserializing into memory. Also making keystores more forward looking by being able to switch out algorithms as well.

FlatBuffers: http://google.github.io/flatbuffers/index.html.

Keyczar metadata update proposal: https://github.com/google/keyczar/issues/121

[Steve Weis]

A standard key format and minimal set of supported algorithms would be nice. Though once you plug in a crypto library you basically have Keyczar again.

Re: key and secret management, there are a whole slew of projects now:

KeyWhiz: https://github.com/square/keywhiz

Vault: https://github.com/hashicorp/vault

Knox: https://github.com/pinterest/knox

Confidant: https://github.com/lyft/confidant

Secretary: https://github.com/meltwater/secretary

Sops: https://github.com/mozilla/sops

Summon: https://github.com/conjurinc/summon

Biscuit: https://github.com/dcoker/biscuit

I don't know if any are appropriate for integrating directly into a crypto library or what kind of key rotation they support.

On Wed, Sep 7, 2016 at 9:19 AM Jay Tuley <j...@tuley.name> wrote:

I have had similar thoughts of a libsodium with keyczar-like keyversion. Possibly using something like flatbuffers instead of json for the keystore, just to reduce the amount of keydata thrown about when deserializing into memory. Also making keystores more forward looking by being able to switch out algorithms as well.

FlatBuffers: http://google.github.io/flatbuffers/index.html.

Keyczar metadata update proposal: https://github.com/google/keyczar/issues/121

On Wed, Sep 7, 2016 at 11:00 AM, David Norman <dash...@gmail.com> wrote:

I tend to agree (and poor Shawn being on his own all these years).

I know Andrew, Shawn and I had grand plans to do a rewrite for K2, but we all got busy with other projects and various start-ups. With Andrew back at Google he may have more time than the rest of us, so will let he and Shawn chime in. It would be great to get the rewrite under way since I have several of my own uses I could use keyczar for, but just don't have the time.

On Wed, Sep 7, 2016 at 9:55 AM, Steve Weis <stev...@gmail.com> wrote:

Keyczar is getting out of date to the point where I think it might be time to deprecate it. It is still using SHA-1, doesn't support GCM, and doesn't support ECC algorithms by default. It only supports DSA and RSA, and I wouldn't use either for new code.

There doesn't seem to be much activity or drive behind Keyczar. Shawn Willden is doing almost all the Keyczar maintenance on his own. Otherwise, Google seems to be using the internal Keymaster on BoringSSL for new projects. I know there was a K2 project in the works at one point, but that seems to have died.

Without a driving force to push new development, I think it would be hard to modernize implementations in three different languages while maintaining backward compatibility.

I would probably deprecate Keyczar and suggest that users start migrating to something else. Unfortunately, I don't have a drop-in suggestion to replace it. I'd probably use libsodium with some Keyczar-like key versioning.

I might be off-target if there are people who depend on Keyczar. If that's the case, those users should probably come up with a plan to modernize Keyczar and at least deprecate outdated modes and algorithms.

I'd be happy to talk about potential replacement designs if anyone were interested.

--
You received this message because you are subscribed to the Google Groups "Keyczar Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to keyczar-discu...@googlegroups.com.
To post to this group, send email to keyczar...@googlegroups.com.

Visit this group at https://groups.google.com/group/keyczar-discuss.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Keyczar Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to keyczar-discu...@googlegroups.com.
To post to this group, send email to keyczar...@googlegroups.com.

Visit this group at https://groups.google.com/group/keyczar-discuss.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Keyczar Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to keyczar-discu...@googlegroups.com.
To post to this group, send email to keyczar...@googlegroups.com.

[Shawn Willden]

Andrew has been doing some work on K2. In addition there's another initiative from Google ISE, going by the same name. I'm not sure at this point how things are going to shake out, but I think we should know what the direction is going to be, in Google, in the next few months. One thing that is very clear is that we won't make the mistake of building a purely internal library again. Whatever the future Google corp solution turns out to be, it will be open source. That will make maintenance much more reliable, since there will be people actually assigned to work on it.

Shawn Willden | Software Engineer | swil...@google.com | 303-709-2258

[devin lundberg]

I can speak to Knox (https://github.com/pinterest/knox) since I wrote it. It was designed to provide access control for secrets, provide rotation capabilities, and be highly available for a large fleet of machines. It uses rotation statuses like primary, active, and inactive for key rotation so it could be combined with something like libsodium. I even hacked up a little python script internally that allows knox to be used with the python version of keyczar. We don't use knox+keyczar too much since many of the ciphers in keyczar aren't acceptable for use anymore, but making a wrapper around libsodium might be a worthwhile project when I get some time.

Also I'm excited to hear the K2 project isn't completely dead.

To unsubscribe from this group and stop receiving emails from it, send an email to keyczar-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to keyczar-discuss@googlegroups.com.

Visit this group at https://groups.google.com/group/keyczar-discuss.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Keyczar Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to keyczar-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to keyczar-discuss@googlegroups.com.

Visit this group at https://groups.google.com/group/keyczar-discuss.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Keyczar Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to keyczar-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to keyczar-discuss@googlegroups.com.

Visit this group at https://groups.google.com/group/keyczar-discuss.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Keyczar Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to keyczar-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to keyczar-discuss@googlegroups.com.

Visit this group at https://groups.google.com/group/keyczar-discuss.
For more options, visit https://groups.google.com/d/optout.

--

Shawn Willden | Software Engineer | swil...@google.com | 303-709-2258

--

You received this message because you are subscribed to the Google Groups "Keyczar Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to keyczar-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to keyczar-discuss@googlegroups.com.

[Andrew Sacamano]

Hi all,

Where I've been going with (what I think will need to new name) is focusing on:

1. Semantics of use
   
1. Declare the guidelines you want to follow (e.g. NIST 2015)
2. Declare the properties (or shorthand property set) you want - i.e. SAFE_ENCRYPT_FOR_OTHER_PARTY = ASYMMETRIC, CONFIDENTIALITY, ROTATABILITY, MESSAGE_INTEGRITY, SENDER_AUTHENTICATION (sorry, Shawn and I settled on some property names,  which I'm blanking on at the moment).
3. Then operating on it
2. Tying keys to channels - i.e. use this key for sending messages in format X to other party Y.
3. Pluggable operational components
1. Key storage
2. Crypto engine
3. Logging
4. Monitoring
5. Message encoding (from a logical message to bytes - could be compact binary, ASCII protos, JSON, whichever)
4. Separating the layers of the API to make it easier to write tooling.

I've been sucked into a bit of a crash project at work, but I do expect to have something that can be looked at in the next 4 - 6 weeks.

I'll definitely have to do some research on the the other things going on here to make sure I'm not reinventing the wheel.

My design doc is a bit of a mess now - but I'll post a link next week if anyones interested. I'm very eager for feedback and collaborators.

Cheers,

Andrew

[jacobwilder...@gmail.com]

Hi Andrew, Whenever you do have something to be share I'd be interested in looking at it (design document, prototype, API specification, anything). 

As much as I like libsodium I've spent significantly more hours than I'd like to have making it easily deployed as part of a JAR'd java project. 

[Will Sargent]

Hi Jacob,

I'd be interested in hearing how you set up libsodium in a Java project, if you have time and can share it here.

_____________________________
From: jacobwilder...@gmail.com
Sent: Friday, September 30, 2016 7:46 AM
Subject: Re: Deprecating Keyczar?
To: Keyczar Discuss <keyczar...@googlegroups.com>

--

You received this message because you are subscribed to the Google Groups "Keyczar Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to keyczar-discu...@googlegroups.com.
To post to this group, send email to keyczar...@googlegroups.com.

[Andrew Sacamano]

I will definitely share it here - I've been sucked into some other things - but I did make some progress recently. I should be able to put it out next week.