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: someone@yourdomain.com. Doing the following
openssl genrsa -out someone@yourdomain.com.key 4096
openssl req -batch -new -key someone@yourdomain.com.key -subj '/C=SE/ST=Göteborg/L=Göteborg/O=Some Company AB/OU=Dev/CN=someone' -out someone@yourdomain.com.csr
openssl x509 -req -days 365 -in someone@yourdomain.com.csr -signkey someone@yourdomain.com.key -out someone@yourdomain.com.crt
will produce the public key:
someone@yourdomain.com.crt
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 someone@yourdomain.com.crt
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 someone@yourdomain.com.key
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
[cryptography] [x509]