In case anyone is wondering...

[mdlbear]

Yes, I did go to Fry's this morning and buy the new DVD edition of Star Wars. Apart from that it was a fairly unproductive day, though I did manage to get some implementation details sorted out on the program I'm writing at work.

The amount of Java you have to write to run a command and pass its output into STDOUT of the calling program is distressing, even if you already have a convenient and well-tested stream-to-stream copy class.

Especially when you compare it with the corresponding C or Perl code, which is simply passing the command string as an argument to the system function. And the Perl will run faster, too, because all it has to do is wait while the command runs, rather than sitting there frantically shovelling bytes from the program's output stream into its own.

Well, I'll eventually end up doing it both ways: shelling out to openssl, and using the Java crypto insanity (and hope that I can figure out the right set of magic parameters to get it to hash passphrases the same way openssl does). Then I'll go back and do a clean implementation in Perl, which will end up taking about a page and running an order of magnitude faster.

Comments

[chatworthy.livejournal.com]

Which is why I avoid Java.

Unfortunately, I work in a mostly-Java shop.

Fortunately, I'm one of the Oracle guys, so I work mainly in PL/SQL and some
shell scripting.

[aerowolf.livejournal.com]

Is this to handle the X.509 certificate encryption for the private key? The passphrase hashing and application is well-specified in that case.

What other forms of passphrases are you looking at?

[mdlbear]

No, it's secret key: PBEwithMD5andAES, most likely, or in any case whatever openssl uses. (The PBE stands for "Password Based Encryption".)

The general idea is to encrypt a document using a random, unguessable identifier as the passphrase, then store it at a URL derived from the SHA1 hash of the same identifier. The result is something that you can store on a public server and pass around freely, because you need the identifier in order to retrieve it.

I'm still not quite certain what you're looking at...

[aerowolf.livejournal.com]

OpenSSL uses HMAC, md2, md4, md5, mdc2, ripemd, and sha1. It doesn't appear that AES has been implemented.

But... if I'm understanding correctly, you're going to basically use a hash function for its standard purpose? :) (someone knowing the hash will be able to look up the encryption key, in other words -- so the hash becomes as important to keep secret as the key?)

Re: I'm still not quite certain what you're looking at...

[mdlbear]

You may be looking at an old version of openssl; 0.9.7 has AES-128, -192, and -256 (look in the cyphers rather than the hashes).

The trick is that the URL and encryption keys are derived from the identifier via different hashes -- the URL path is SHA-1, and the key is an MD5 hash of the identifier with a salt. Knowing the original identifier gets you both; knowing only the hashed URL doesn't get you anything else.

In any case, all of this works fine as a Perl one-liner, the rant was about the difficulty of doing the same thing in Java. Took me about a day and a half of research, and a long afternoon of coding.

Re: I'm still not quite certain what you're looking at...

[aerowolf.livejournal.com]

Huh. (I was looking at the documentation on openssl.org, which apparently hasn't been updated.)

So. It gives me an identifier, I upload my document to the URL derived from identifier via SHA-1, and it's automatically encrypted AES(document,MD5+salt(document))? So, even if you download from the URL, you still can't decrypt it without the identifier, and it's infeasible to derive that identifier from the one hash you do have?

Interesting concept. How would I determine the salt that was applied to the MD5 for decryption, given the identifier?

Re: I'm still not quite certain what you're looking at...

[mdlbear]

The salt goes into the encrypted document -- it's just there so that even if you have the MD5 hash of the identifier, you don't know the actual key.

It's in one of the PKCS documents from RSA; PKCS5, I think.

Actually, it's the client's job to do both the hashing and the encryption -- that way, no plaintext is ever transmitted over the wire. What I'm actually writing is a proxy that does all of the necessary magic on behalf of an ordinary browser running on the same machine, or at least the same LAN.

I can talk about it because it'll all be open source fairly soon; there are no IP protection issues because I found prior art in the public domain, after re-inventing the technique independently.