Slashdot Mirror
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.'"
Jython? Serious question.
Your ad here.
As in Söze???
Well then, I trust this product immediately and fully.
"Be light, stinging, insolent and melancholy"
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
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.
-William Brendel
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.
Sounds a lot like jasypt, which I just used in a project.
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.
Jilles
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?