1 | function xorConvert (text, key) { |
My Handy openssl
command list;
Generate a password hash
1 | openssl passwd -1 |
Really handy, if you vitally need to store users passwords in you system
Generate Randomness
1 | openssl rand -base64 128 |
A nice comparison of this wold be with
1 | cat /dev/urandom | head -c 128 | base64 |
Although it seems openssl
actually uses /dev/urandom
under the hood, when hardware is specified
Generating Keys
RSA Key
1 | openssl genrsa -aes256 -out node.key 2048 |
Public Key
1 | openssl rsa -in node.key -pubout -out node.pub.key |
DSA key
1 | openssl dsaparam -genkey 2048 -out node.dsa.key |
or simpler;
1 | openssl dsaparam -genkey 2048 | openssl dsa -out node.key -aes256 |
ECDSA key
1 | openssl ecparam -genkey -name secp256r1 -out node.ecdsa.key |
or simpler;
1 | openssl ecparam -genkey -name secp256r1 | openssl ec -out node.key -aes256 |
Self signed Keys
In order to request a new self signed certificate, and a new private key:
1 | openssl req -new -x509 -keyout privkey.pem -newkey rsa:2048 |
req
: certificate request and certificate generating utilitynew
: generates a new certificate requestx509
: creates a test certificate or a self signed root CAkeyout
: the filename to write the newly created private keynewkey
: creates a new certificate request and a new private key
Also
Examine and verify certificate request
1 | openssl req -in node.key -text -verify -noout |
Creating a csr with a key
1 | openssl req -new -key node.key -out node.csr |
Requesting a custom siggning certificate
1 | openssl x509 -req -days 365 -in node.csr -signkey node.key -out node.crt |
or without a csr
1 | openssl req -new -x509 -days 365 -key node.key -out node.crt |
Then creating a csr from an existing certificate
1 | openssl x509 -x509toreq -in node.crt -ou node.csr -signkey node.key |
x509
Display the contents of a certificate:
1 | openssl x509 -in cert.pem -noout -text |
Display the certificate serial number:
1 | openssl x509 -in cert.pem -noout -serial |
Display the certificate subject name:
1 | openssl x509 -in cert.pem -noout -subject |
Display the certificate subject name in RFC2253 form:
1 | openssl x509 -in cert.pem -noout -subject -nameopt RFC2253 |
Display the certificate subject name in oneline form on a terminal supporting UTF8:
1 | openssl x509 -in cert.pem -noout -subject -nameopt oneline,-esc_msb |
Display the certificate MD5 fingerprint:
1 | openssl x509 -in cert.pem -noout -fingerprint |
Display the certificate SHA1 fingerprint:
1 | openssl x509 -sha1 -in cert.pem -noout -fingerprint |
Convert a certificate from PEM to DER format:
1 | openssl x509 -in cert.pem -inform PEM -out cert.der -outform DER |
Convert a certificate to a certificate request:
1 | openssl x509 -x509toreq -in cert.pem -out req.pem -signkey key.pem |
Convert a certificate request into a self signed certificate using extensions for a CA:
1 | openssl x509 -req -in careq.pem -extfile openssl.cnf -extensions v3_ca \ |
Sign a certificate request using the CA certificate above and add user certificate extensions:
1 | openssl x509 -req -in req.pem -extfile openssl.cnf -extensions v3_usr -CA cacert.pem -CAkey key.pem -CAcreateserial |
Set a certificate to be trusted for SSL client use and change set its alias to “Steve’s Class 1 CA”
1 | openssl x509 -in cert.pem -addtrust clientAuth -setalias "Steve's Class 1 CA" -out trust.pem |
Securing local files, it’s a problem solved by a variaty of aps. Though each app are falling
into the falacy of providing their own way to encrypt and package the outputed file.
Now imagine the app developer deciding to discontinue the development and support of the app,
or even worse a known vulnerability of the app goes public (or worse, it never goes public).
Then you data are as unprotective as they were in their raw form. Why shouldn’t be an eay way
to make use of a trusted way? I guess the first solution that pops to our mind is openssl
,
right? So why not using just openssl
to do the heavy ligting?
TL;DR; evancrypt.sh
Using the force of openssl
Encrypting
So all you need is;
1 | openssl aes-256-cbc -salt -in raw.file -out encrypted.aes |
Done, you can now delete your raw.file
and store your encrypted.aes
file into an untrusted store!
Wait, a file? what about a whole directory? Well a file is all we can do, if only we could point
to a directory like it was a file?
tar
ladies and getlemen, to the rescue! We can tar -cf
our directory and pass the the .tar file to
be encrypted.
Yes you can pipe! So;
1 | tar -cf - raw.file.or.directory | openssl aes-256-cbc -salt -out encrypted.aes |
Done! With the command above you can securly generate an encrypted file, and being agnostic whether you are
tranforming a file or a dir, as all openssl
get is a stream generated from the tar
command.
Decrypting
Well an encrypted file, with no way of return has no better value than a deleted file, unless you are trying
to generate some randomnes, in that case all you need is;
1 | cat /dev/urandom | head -c 10 |
and you’ll have your first 10 random bytes.
If on the other hand though, you intend to reuse your files, you are required to decrypt the file, by using
the same Cipher and salt.
1 | openssl aes-256-cbc -d -salt -in encrypted.aes -out raw.file |
But again, a tar file, has no better value as well, so why not piping the outcome to tar
in order to magically
have our file;
1 | openssl aes-256-cbc -d -salt -in encrypted.aes | tar -x -f - |
The above command should generate back, whatever was passed as input.
Further thoughs
Piping to openssl
seems like a super skill that is freely available. Hacking with it can make your saturday evening
more fun than spending it on a sundbed near a tropical beach. Some ideas to get you into the rabbit hole;
Secure one-directional text service
1 | #server |
Done! With the code above, a client can send a text to the server, by passing it first to a proxy. The only job that proxy has
is to double encrypt the message, acting as a “carrier” signal.
Well having a whole setup to only send randomness from one node to an other makes no sense, so please don’t use the code above
as it is.