Easy Encryption In Java and Python With Keyczar 19
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.'"
What about... (Score:3, Funny)
Re: (Score:3, Informative)
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 [jython.org]
Re: (Score:1)
Keyczar? (Score:5, Funny)
Well then, I trust this product immediately and fully.
standard API as well ? (Score:4, Interesting)
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 ? (Score:4, Interesting)
Re: (Score:3, Interesting)
http://www.keyczar.org/javadocs/index.html [keyczar.org]
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.
And this simplifies things... how? (Score:2)
Re:And this simplifies things... how? (Score:5, Insightful)
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: (Score:3, Insightful)
Re:And this simplifies things... how? (Score:5, Informative)
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: (Score:2)
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 (Score:2, Informative)
We need to simplify the setup, not the action. (Score:4, Informative)
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: (Score:1)
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 onl