Share secrets with public cryptography
The job of the developer is sometimes an ungrateful one. We are supposed to implement code that deals with people's data, possibly sensible one. We are supposed to abstractly deal with that, but also without ever touching the real data, because that is private stuff, and it should not be on the public. That's where it feels close to magic, until ... something breaks, and we eventually need to take a closer look at the actual data that flows through our code.
That is where someone will call unto you and try to explain a problem and would push for sending some sort of data over that is sensible and it's not supposed to be shared in cleartext. Of course, everyone is supposed to have some encrypted mail account with a CA that costs billions, or the like.
The problem with solutions that are inpractical or do not have a shared understanding, is that people will try to walk around them.
But cleartext, no, we don't want that to happen.
So, this is suboptimal, of course, but if you bear with me, what you can do is generate a pair of keys, a private and a public one. All you need to do is share the public one over a channel that you reasonably trust, in terms that your peer can get it and be sure it is your own. It does not need to be encrypted, it's not a secret, it's you public key.
Let us say that you name the keypair after your email: email@example.com. Doing the following
openssl genrsa -out firstname.lastname@example.org 4096 openssl req -batch -new -key email@example.com -subj '/C=SE/ST=Göteborg/L=Göteborg/O=Some Company AB/OU=Dev/CN=someone' -out firstname.lastname@example.org openssl x509 -req -days 365 -in email@example.com -signkey firstname.lastname@example.org -out email@example.com
will produce the public key:
that you want to send over to your peer. And the secret *.key is for you to keep safe, possibly protect with a password.
To encrypt data for you, your peer will need to be instructed to do something like:
openssl smime -encrypt -binary -aes-256-cbc -in yoursecretfile.txt -out yoursecretfile.enc -outform DER firstname.lastname@example.org
and when you receive yoursecretfile.enc you'll have to decrypt with:
openssl smime -decrypt -binary -in yoursecretfile.enc -inform DER -out yoursecretfile.txt -inkey email@example.com
Now, wouldn't it be marvelous if you also had a script that saves you from all this mess, and possibly enables you to maintains different profiles for different kind of secrets ?
Something that, given a profile for which you have a keypair (profile.key,profile.crt) will handle all of the jazz and use like:
x509crypt <profile> -E <file> : Encrypt <file> x509crypt <profile> -d <file> : Decrypt <file> x509crypt <profile> -g : Generate keys x509crypt <profile> -x : eXport pub key x509crypt <profile> -s : export private key x509crypt <profile> -X : eXport pub key details x509crypt <profile> -i <file> : Import pub key x509crypt -l : List profiles
What if I ended up bothering with such implementation, would you end up using it?
I named it x509crypt and it solves the problem that I used to have.
Paolo Lulli 2021
Keywords: [ cryptography ] [ x509 ]