Easy Encryption In Java and Python With Keyczar

rsk writes "Keyczar is an encryption toolkit born out of the Google Security Team and released under the Apache 2 license. Keyczar's purpose is to make managing encryption of secured data much easier than it has been, with the following features: a simple API; key rotation and versioning; safe default algorithms, modes, and key lengths; automated generation of initialization vectors and ciphertext signatures; Java and Python implementations (C++ coming soon); and international support in Java (Python coming soon). The example on the website is only 2 lines long, and a more fully worked out example is also provided for folks wanting to get started 'for reals.'"

Comments

What about...

[Malevolyn]

Jython? Serious question.

Re:What about...

[maxume]

If the python version wraps C code, you would probably have to use the Java version from Jython, which apparently isn't a big deal:

http://www.jython.org/docs/usejava.html

Re:What about...

[timothyb89]

Jython is a scripting language in java (see the Java scripting project). As per the specification for Java scripting languages, you can run Java code just like code written in the scripting language (jython, in this case)

Keyczar?

[Naughty Bob]

As in Söze???

Well then, I trust this product immediately and fully.

Re:Keyczar?

[Anonymous Coward]

well, I believe in God, and the only thing that frightens me is Keyczar.

standard API as well ?

[johnjones]

does it implement the java crypto api (JCE) and how does it compare to The Legion of the Bouncy Castle ?

can it do PGP otherwise its just another api wrapper essentially because its not a standard i.e. it is no good locking something up if you cant give someone else the keys...

regards

John Jones
http://www.johnjones.me.uk

Re:standard API as well ?

[bratgitarre]

It's waaaay smaller than Bouncy Castle. The focus of Keyczar seems to be on usability, to the point that it's seems rather black-boxy. Here's an encryption example from their page: Crypter crypter = new Crypter("/path/to/your/keys"); String ciphertext = crypter.encrypt("Secret message"); Notice that it's not at all clear what this does. Is it symmetric or asymmetric encryption? Deterministic or nondeterministic? Authenticated? It's all under the hood. If you don't care to look, you don't have to know. They try to provide safe defaults, but it won't the developer from understanding some basic crypto concepts. Bouncy Castle is a lot more comprehensive and (most likely) mature.

Re:standard API as well ?

[Seakip18]

http://www.keyczar.org/javadocs/index.html

From what I gathered (and I'm probably wrong. I'm not the best when it comes to understanding cryptography.), you've got a private/public key or symmetric key setup, depending on your choice.

Sorry I couldn't be more helpful.

Wait... Google Has a security team??

[Anonymous Coward]

No offense to google, but they've had their share of horrible security mistakes.

And this simplifies things... how?

[debatem1]

Using AES256 in Python is about three lines of simple, readable code that will do the same damnable thing every time. This takes two lines of magical code that may wake up one day and decide to not even be the same class of cipher. Does this make sense to anybody? Can you explain why?

Re:And this simplifies things... how?

[wbren]

I think this is similar to the programming books that say, "Look how easy it is to create a real C program! Just one line of code!" Yeah, it technically compiles and runs, but it doesn't do much of anything. This is a fairly common problem with crypto libraries in my experience: making things seem simpler than they should be in return for the "wow factor" of two-line examples, like the one provided.

This library seems to be making a big deal about "secure defaults", but I think trying to provide defaults of any kind is a really bad idea. Cryptography is something that should be thought out on a case-by-case basis. Providing defaults of any kind can lead to misuse of otherwise safe algorithms. The safest gun is still dangerous in the hands of an inexperienced person.

Re:And this simplifies things... how?

[debatem1]

Well said. I'm doing a little series of talks on crypto later this year and one of the hardest things to do in it is to convince people that good ciphers do not make secure cryptosystems. It becomes doubly hard when somebody slaps Google's name all over a new codebase and proclaims that you, too, can have security with nary a troublesome thought.

Re:And this simplifies things... how?

[jilles]

I think you are both wrong. The issue here is not the algorithms but how you combine them to do the right things. This process includes things like generating keys, storing and retrieving them, exchanging them with other parties, etc. This is surprisingly difficult to get right if you are not an expert. Many existing cryptography frameworks provide plenty of room for mistakes to be made. A single configuration error can defeat the whole purpose of using encryption. Doing things on a case by case basis only creates multiple opportunities for doing the wrong thing.

All this framework does is provide a reasonable implementation to support a range of common use cases in a more or less fool proof way. It reduces the amount of decisions that need to be taken by a programmer and that reduces the amount of room for mistakes. In cryptography, default settings are good: you rely on proven algorithmic strength & best practices and not on obscurity. These breaking down is a lot less likely than you making a mistake.

Re:And this simplifies things... how?

[wbren]

I never took issue with the algorithms in my reply. In fact, I said exactly what you did about the "combining" step being the most difficult part, albeit in a less verbose way. Defaults in cryptography APIs allow inexperienced (in terms of security) programmers to blindly implement things and hope it "just works". Common use cases are great, but they can get you into trouble too...

jasypt

[Uberdog]

Sounds a lot like jasypt, which I just used in a project.

We need to simplify the setup, not the action.

[dwarfking]

Encrypting a simple text string is not that difficult in Java, once the environment is properly configured. That is the tricky part.

In our environment we are trying to move to a model where our internal servers are all communicating over secure connections with certificate based authentication and I am working on a mechanism to do Certificate authentication from a Java client that is an application running in a J2EE container (JBoss).

We can use self-signed certs as it is all internal, but the setup has been a nightmare.

First we create a root cert with OpenSSL for the web server, not too bad to do. Then we create a user certificate to allow access to a certificate protected URL under the web server. Again, fairly simple. Now, we have to get the SSL cert and client cert into the Java client, and this is where it gets difficult. We bundle the client credentials into a PKCS12 file and import it into a browser to ensure it works, and we can get to the certificate protected resource.

The mechanism pushed by the Java specs is to either import the certs into the root certificate store for the installed JRE, or use a newly created certificate store that is identified by global properties. Neither works for us as we run multiple app servers on the same box (would share the JRE) and multiple client applications in the same JBoss (different apps need different credentials).

After much research and testing, I finally found a mechanism for creating a custom SSLSocketFactory (using the Apache HttpClient package allows using a custom factory per connection, doesn't require it globally replace the default) that loads the server cert into the TrustManager, and reads the client key/cert (in PKCS12 format without a password on the key) into an in-memory KeyStore. Turned out I couldn't use the Sun provider to read the PKCS12 file because that version required a password be provided (can't use NULL) and if you use an empty string ("") it generated a divide by zero error. Bouncy Castle though, works fine.

My point in this is that more code might be written more securely if some time was spent to make it easier to actually use the security. This one took me most of a week to finally work out the details and have a working prototype, with many many hours searching for samples.

So ok, maybe two lines to do a simple encryption is nice, but can we now do something to simplify the management of the keyring?

Re:We need to simplify the setup, not the action.

[DirtMcGirt]

Man, I hear you. I ran into the same problems with cert management and SSLSocketFactories a couple of times over the last 2.5 years in an app I work on. It's good to know it wasn't just me having this trouble.

The Sun solution of setting some global System properties seems insane. It vastly complicates one of my cases, where the client portion of app A that talks to the server portion of app A is embedded in app B. There are race conditions about setting the global properties, and on and on. We were only able to work around things with some fairly nasty hacks.

What I found was that the problem leads back to the implementation of the SAAJ library, which does the low-level SSL communications. The sun-supplied version of SAAJ - which is required by other libs we use, like the JAXWS reference implementation - requires setting JVM-wide properties. The Apache Axis version of SAAJ allows (fairly) easily setting up non-global SSLSocketFactories. Predictably, the two SAAJ impls are incompatible; and besides the SSL issue, Axis is a huge pain to use compared to JAXWS, so it seems you really can't win.

I think the Google lib is a good idea, generally. I made a quite similar set of classes for the apps I work on. It's simplified our use of crypto quite a bit, and got us to use crypto much more widely. It seems like a fairly straightforward application of the 80-20 rule.

Duhhhh

[Anonymous Coward]

for i=1 to strlen(cleartext)
    cleartext[i]=cleartext[i] xor i