The uncertain future of Keyczar
The cryptographic world changed a lot since 2008 when Google’s Keyczar library showed up. However, one thing is still the same - effective cryptography is really hard to implement. Keyczar library was a quite successful attempt to provide easy to use crypto solutions based on current security standards to Java, Python and C++. Now, after 9 years of its development, the future doesn’t look so bright.
Ain’t no sunshine when it’s old
In the late 2016 Keyczar’s maintainers announced that:
KeyCzar has some known security issues which may influence your decision to use it.
First of identified issue gives a good overview of the project’s current state:
Keyczar uses 1024 bit DSA keys with SHA1.
SHA-1 has been considered insecure for some time and we all should use at least 2048 bit keys (or switch to elliptic curves based algorithms), but’s that just a tip of the iceberg. A quick look at the list of supported algorithms (and key lengths) reveals that the whole project is a little bit outdated. The discussion about deprecating Keyczar started with:
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.
Despite speculations about Keyczar 2 we still didn’t get any clear statement about it.
Insecure or just weak?
Let’s look at the issue list again. Besides 1024 bit DSA keys with SHA-1 there are two other points. The first one is clear - Signed Session Encryption feature is broken and we shouldn’t use it at all:
Keyczar signed session encryption does not include the key ID of the signing key inside the encrypted plaintext. This makes is possible for an attacker to strip the signature from a message, and re-sign it using their private key, making it look like they sent the original message
The fix is not trivial most likely due to backward compatibility issues. If you’re using this feature in your software I would recommend you to change it immediately.
The last security issue on the list describes resolved old DSA Signature problem. Why didn’t anyone spot this bug before? That’s probably the most interesting part:
Some crypto libraries - including many JCE implementations - stop checking the signature after finding both ints, which means that they will verify signature that have extra data. This is why keyczar did not discover the extra data in DSA signatures.
Again, the backward compatibility requirement struck in - after the fix, Keyczar trims out any extra data (but doesn’t reject it). Another insecure feature? Not this time! Setting keyczar.strict_dsa_verification system property enables strict (and secure) verification mode.
What about other algorithms and supported key lengths? So far we should consider some of them a bit weak and outdated but not insecure. That means if you’re still using Keyczar for existing project you don’t have to change the library ASAP (except for Keyczar’s Signed Session Encryption).
Post-Keyczar world
For now, it looks like we should seek some more up-to-date replacements - especially for all new projects. What to choose instead of Keyczar? The most popular library libsodium provides modern cryptography solutions (via NaCl) and simple API. Libsodium is a native (but cross-platform) library that requires (at least for JVM languages) appropriate wrapper - eg. kalium for Java - but this is just a small inconvenience.
The biggest problem with finding an one-to-one replacement is a lack of easy and automated key rotation and versioning (Keyczar’s feature described here) mechanism. Migrating to other solution may require to just implement it or use a third-party library.