# Which cipher to use with openssl for shortest output?

I'd like to encrypt my 12-24 words seed for my bitcoin wallet with openssl command line tool to be able to have it with me on paper without the risk that somebody could use it

Which cipher should I use for the shortest output in base64? The seed consists of just a-z characters and is case insensitive

Main requirements are short length and decodable on any computer with openssl installed - nothing exotic

• Assuming you mean enc some builds of openssl support zlib compression (and decompression) of plaintext, or at least did before CRIME, but for this short a plaintext the fixed overhead of zlib (not to mention the encryption overhead described by Maarten) may offset the compression. Try -z and see. – dave_thompson_085 Jan 29 '18 at 4:08
• The output should be in ascii so I can write it down and not binary – jeff Jan 29 '18 at 7:34

It could be better to use PGP, which has been designed to encrypt files.

Only OpenSSL v1.1 latest versions contain a command line switch to choose the number of iterations (the work factor) to configure the password hash when using password based encryption (PBE). This is something that is required, otherwise the password must be of about the same strength as your original password. That would of course not help you any further.

As you require just normal confidentiality you could just use AES-CTR mode for PBE. Then there is just 16 bytes of overhead for the salt and header (you could remove the first 8 bytes of magic and replace it back afterwards as optimization). So then the ciphertext would be only 8 bytes more than the password. Base 64 - you can forgo the base 64 padding characters - will just expand this by one third.

However, the password consists solely of lowercase characters. So each character only needs to take 5 bits (2^5 = 32 which is greater than the 26 values required). So that way you can save 3 bits per character.

So the minimum size of the maximum value would then be 24 * 5 / 8 = 15, 15 + 8 = 23 bytes, expanded to (24 / 3) * 4 = 32 base 64 characters.

But don't forget to write down or remember the iteration count and - of course - the algorithm itself.

It might be easier to use e.g. an IronKey to store your passwords on a USB stick (or two), which would cost you about 50 Euro per piece. Remember that flash may not last forever though, it can leak state over time.

• Are you looking at head? Released 1.1.0 commandline has -iter for pkcs8 but not for enc (or pkey or pkcs12 for that matter). PGP has good PBE, but a significant size overhead (especially if 'armored' = base64+check+BEGIN/END) for very small data like this case. – dave_thompson_085 Jan 29 '18 at 4:27
• @Maarten thx for the long answer, I could understand like 50% - could you maybe provide some sample commands which I can try for encoding? I didn't quite understand how I can utilize the fact that I only use lovercase. Optimally I will get a hardware wallet, but as a temporary solution I want to write down the code on paper but obscure it as much as possible – jeff Jan 29 '18 at 7:31
• Well, if it is possible to do it without re-encoding I would even if the result is a bit larger... the general idea is to subtract the ordinal value of the character 'a' from the character so you get something in the [0, 26) range, and then encode the number into 5 bits. But that would be tricky to do from the command line - far from impossible but nevertheless. Apologies about the OpenSSL -iter hint; dave is usually right about this; I wasn't expecting that they forgot to take away all the other places where they do password based key derivation. Programming this in C is much easier. – Maarten Bodewes Jan 29 '18 at 12:02