bugs / PR status?

[Will Sargent]

Hi all,

I notice that there are 57 issues open and 3 PRs open on KeyCzar's github page right now: it looks like the bulk of them were imported on March 7th.

I'm interested in this PR in particular, the "aes 256 keys not creating the correct hash in Java" from April 16th:

https://github.com/google/keyczar/pull/165

Does anyone know what the status is on these bugs and PRs?

Will.

[Shawn Willden]

I somehow missed that PR. I'll take a look at it (and likely merge it) today.

I'm not aware of any other work being done. If you want to send PRs, I'll commit to getting them reviewed quickly (in a day or so, usually, depending on size).

--
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 http://groups.google.com/group/keyczar-discuss.
For more options, visit https://groups.google.com/d/optout.

[Will Sargent]

Thanks Shawn.

How is the K2 coming along? Is there a migration path from KeyCzar from K2?

https://github.com/google/K2/wiki/What-is-K2

[Shawn Willden]

K2 is stalled, unfortunately.

The plan is for K2 to be interoperable with KeyCzar at the wire level, but I can't promise it will ever see the light of day. I'd really like it to, but I wouldn't want you to make decisions that depend on it.

[Daniel Bleichenbacher]

No Shawn.

It has never been the plan to make K2 interoperable with keyczar. There are just too many design problems with keyczar. Hence a fresh start was really the goal.

I'm also quite annoyed that you are constantly modifying the design goals. This is very disrupting and really doesn't help the project in any way.

[Will Sargent]

Maybe some background would help -- I'm trying to find a "reasonable default" in Play, for end users who have encryption needs without digging into the cryptographic primitives.  

The comments and Github issue are here

https://groups.google.com/forum/#!topic/play-framework-dev/Rlrt89Ky_Rk

https://github.com/playframework/playframework/issues/4407

It looks like Keyczar is a good engine for this, but ideally we'd like people to be able to swap out the implementations while having the same API (i.e. if you just want to encrypt, there shouldn't be a difference between KeyCzar and K2).  But if we can't put together a generic enough play.api.libs.crypto API, then packaging KeyCzar with Play and working with it directly is probably the best option.

[Shawn Willden]

On Tue, Jul 7, 2015 at 2:09 AM 'Daniel Bleichenbacher' via Keyczar Discuss <keyczar...@googlegroups.com> wrote:

No Shawn.

It has never been the plan to make K2 interoperable with keyczar. There are just too many design problems with keyczar. Hence a fresh start was really the goal.

We (Andrew and I, at least) planned from the beginning to make the message formatting and other relevant bits pluggable and to include KeyCzar modules. That was a low-priority goal, though.

 

I'm also quite annoyed that you are constantly modifying the design goals. This is very disrupting and really doesn't help the project in any way.

I don't think I've ever changed the design goals... not my view of them, at least :-)

[Shawn Willden]

On Tue, Jul 7, 2015 at 8:43 AM Will Sargent <will.s...@typesafe.com> wrote:

Maybe some background would help -- I'm trying to find a "reasonable default" in Play, for end users who have encryption needs without digging into the cryptographic primitives.  

The comments and Github issue are here

https://groups.google.com/forum/#!topic/play-framework-dev/Rlrt89Ky_Rk

https://github.com/playframework/playframework/issues/4407

It looks like Keyczar is a good engine for this, but ideally we'd like people to be able to swap out the implementations while having the same API (i.e. if you just want to encrypt, there shouldn't be a difference between KeyCzar and K2).  But if we can't put together a generic enough play.api.libs.crypto API, then packaging KeyCzar with Play and working with it directly is probably the best option.

The K2 API will be quite different from the KeyCzar API, because the KeyCzar API is at too low an abstraction level. The goal for K2 (as I understand it; Daniel may disagree) is to provide a "goal-oriented" API, which allows the user to specify the security properties they want to obtain and leaves it up to the library to decide what algorithms and constructions are appropriate.

I think that's a better approach for Play than KeyCzar, but has the minor disadvantage of being vaporware.

[Will Sargent]

Right, well… I don’t know of any cryptographic solution that isn’t too low level and OOTB configured for footgun operation, so it’s the API ergonomics I’m really concerned about. KeyCzar is closer than anything else I’ve looked at, and Play can severely constrain and document the more dangerous use cases (as in the case of HTTPS https://www.playframework.com/documentation/2.3.6/LooseSSL).

What’s your recommendation?

[Shawn Willden]

It sounds like KeyCzar is the best approach on offer.  NaCl is another option which is perhaps even less of a footgun, though it's implemented in C and you're looking for Java/Scala.

[Daniel Bleichenbacher]

On Tue, Jul 7, 2015 at 6:14 PM, 'Shawn Willden' via Keyczar Discuss <keyczar...@googlegroups.com> wrote:

On Tue, Jul 7, 2015 at 2:09 AM 'Daniel Bleichenbacher' via Keyczar Discuss <keyczar...@googlegroups.com> wrote:

No Shawn.

It has never been the plan to make K2 interoperable with keyczar. There are just too many design problems with keyczar. Hence a fresh start was really the goal.

We (Andrew and I, at least) planned from the beginning to make the message formatting and other relevant bits pluggable and to include KeyCzar modules. That was a low-priority goal, though.

 

Please stop pretending that K2 is your idea. This is getting annoying. The K2 design came from analysing the library keymaster used internally in Google (which is better maintained than

Keyczar) and fixing some of the design decisions that made extending the library difficult. In fact the message format is one of the things that is not great.

In particular, the first byte is a version byte. The original plan was to increase this byte with new versions and thereby allow to improve existing implementations.

But increasing the version byte was never used. The reason is simple: if the library is used for encrypting data at rest, then it should be able to decrypt even after years.

The solution is rather simple too: instead of having a version in the wire format, the version should be stored in the key material. Then it is possible fix problems in such a way

that they become active after a key rotation, but not disturb old ciphertext.

[Shawn Willden]

On Wed, Jul 8, 2015 at 4:23 AM 'Daniel Bleichenbacher' via Keyczar Discuss <keyczar...@googlegroups.com> wrote:

Please stop pretending that K2 is your idea. This is getting annoying.

To be precise, what I present as the goals for K2 are the ones that my team came up with. They're the ones that are most important to me, and so are the way I describe the project. When we met with you to discuss the concept those ideas got blended with yours to produce a combined approach, which was labeled with the project name you came up with. I should be more careful to include your goals in my description of the project, I suppose.

Regarding message formatting, during our initial planning meeting in Zurich I know Andrew and I mentioned the idea of providing an interoperability option. I don't recall if you responded, but I do know that you didn't object at the time, because we'd have discussed it in more depth if you had.

In any case, this is a discussion that's more appropriate for the K2 forum.

[Daniel Bleichenbacher]

On Wed, Jul 8, 2015 at 6:18 PM, 'Shawn Willden' via Keyczar Discuss <keyczar...@googlegroups.com> wrote:

On Wed, Jul 8, 2015 at 4:23 AM 'Daniel Bleichenbacher' via Keyczar Discuss <keyczar...@googlegroups.com> wrote:

Please stop pretending that K2 is your idea. This is getting annoying.

To be precise, what I present as the goals for K2 are the ones that my team came up with. They're the ones that are most important to me, and so are the way I describe the project. When we met with you to discuss the concept those ideas got blended with yours to produce a combined approach, which was labeled with the project name you came up with. I should be more careful to include your goals in my description of the project, I suppose.

Wow, Shawn.

You are calling design docs written behind my back with dozens of serious design flaws a "combined approach"?

 

Regarding message formatting, during our initial planning meeting in Zurich I know Andrew and I mentioned the idea of providing an interoperability option. I don't recall if you responded, but I do know that you didn't object at the time, because we'd have discussed it in more depth if you had.

The interoperability option consists of not using a 0 byte header, so that it is possible to write a wrapper in your application that can distinguish between legacy ciphertexts and 

new ciphertexts. That's all. It should be obvious that there can be no expectation for support of KeyCzar keys in a new library.

For example, it would be a mistake to add any support for cryptographic primitives that can't even reach a 80-bit security level.

Hence, since keyczar still uses SHA1 for all public key signature schemes, there will be no replacements for these keys.

Upgrading to better cryptographic primitives is long overdue.

The main interface for symmetric encryption is AEAD, which again is not compatible with keyczar keys among other reasons for incompatibility.

 

In any case, this is a discussion that's more appropriate for the K2 forum.

It does belong here. You are trying to sell keyczar. The library is badly maintained and out of date. You are trying to offset this by claiming it

will be somehow compatible with a new library.  

[Shawn Willden]

On Thu, Jul 9, 2015 at 9:02 AM 'Daniel Bleichenbacher' via Keyczar Discuss <keyczar...@googlegroups.com> wrote: 

Wow, Shawn.

You are calling design docs written behind my back with dozens of serious design flaws a "combined approach"?

Actually, I was calling the goals we discussed together a combined approach. And nothing was done behind your back. I just checked and not only have all of the K2 docs been shared with you, you have edit rights -- and have commented on many points.

In any case, this really isn't the place for this discussion, so I'm going to stop here.

[Daniel Bleichenbacher]

Maybe it should also be mentioned that the state of keyczar is not representative for the state of crypto at Google.

Of course, typically, security reviews are done to catch the use of weak algorithms and other problems. 

[Will Sargent]

It does belong here. You are trying to sell keyczar. The library is badly maintained and out of date. You are trying to offset this by claiming it
will be somehow compatible with a new library.  

From an end-user perspective, whether or not it's badly maintained and out of date hardly matters: KeyCzar's the only option available. 

End users are not cryptographers, and will not put together the crypto primitives correctly.  It's been tried again and again, and it doesn't work.  From my perspective, SHA1 with an HMAC is better than SHA512 with no HMAC.

Will.