Converting RSA.pub keys to word list

Question

RSA keys are notoriously blobs. I'm looking to make something more human readable. I want to take the mathematical operation and convert it to a number that can be easily expressed as a series of words against a set indexed wordlist. The first step is converting the RSA.key file to a binary number. Next step is subtracting, or adding one, and dividing by 24. Number theory.

Once that number is obtained, the words that make up the dictionary, and their respective numerical value, or even the raw value of the word, depending on its position, say for instance, "helpful" could have an index value of 1171 or could be given a value of "85121662112" based on a concatenation of the index value of the letters against a standard alphabet. These words are operated on, exponents, multiplication, division, addition, etc., until the original value of the RSA key can be recreated. This should allow the RSA keys to be easily checked for manipulation and verify the authenticity, or easily communicated by phone.

Any thoughts? It isn't exactly pure cryptography, but cryptographic adjacent.

My question is "Does anyone have any input on pseudocode or python implementation?"

Answer 1

I think the comments bring up some good points that make this potentially intractable. However, I figured I'd give the initial thoughts that come to mind.

This immediately reminded me of Bitcoin BIP-39, which might be a part of your impetus for asking, since it's pretty much identical to what you described, but since you didn't mention it and its reference implementation was in Python, it seems worth calling out.

The obvious downside to this approach is that it would take a considerable number of words to encode an RSA key. And I know from experience that even the 24 words for a Bitcoin private keys (256 bits) are a pain to communicate verbally.

Something like Base58Check encoding would perhaps be a bit more compact, and still lend itself somewhat to be communicated verbally (in terms of minimizing/auto-correcting mistakes), but would still very long.

You could potentially look into compressing the public key and then using some sort of encoded like the above options, but the answers to that question still don't get you down to 256 bits which, again, is already cumbersome to communicate verbally.

All-in-all I think it depends on the level of effort you're expecting users to put in and the level of technical knowledge they having. Two technologists communicating a very long Base58Check string would be a huge pain but would likely work. With any other scenario I expect a mnemonic phrase might be better, but you'd probably have to find something better than the BIP-39 definition. And even then I'm not sure you'd get to a level that wouldn't cause people to switch to another method (e.g. emailing a PEM file).

Answer 2

I've done considerable work in encryption and compression in the past. Roughly, 300 decimal points for a 2048 bit key doesn't necessarily have to be incredibly difficult to access with bracketing. I saw very similar issues in compression. Basically sequences come down to Kolmogorov and non-Kolmogorov. The issue was addressed by ignoring Kolmogorov sequences, because they are definitionally impossible to compress and diffuclt to compute and prove Kolmogorov complexity, in favor of high information density sequences then bracketing in. The biggest question is if modern personal pcs have sufficient computing power to make the mathematical operations accessible, which if they can run a standard TLS sequence, shouldn't be that much more difficult.