On converting openssh's id_rsa.pub to openssl, interface design, and lazy people

I just spent two hours trying to find the information needed to convert an openssh public key to openssl format (All hail and kudos to Lars and his awesome post on the subject). It has been a fun time, spent amongst acronyms such as PEM, DER, PKCS#1, PKCS#8, ASN1.1 and content-rich error messages suc as "cannot uudecode" and "Expected PUBLIC_KEY".

So, how is this different from a standard day at the office? In a way it is not - after all,This is not the first time I meet the SSL zoo and wrestle with it. It's just the fact that this kind of wrestling is becoming more and more frequent, as demands for encryption grow - courtesy of the Snowden-NSA snafu.

Problem: the entire field is way too mysterious, laden with three-letter acronyms, and dark corners that nobody cares to document.

Even worse, this is all FOSS software, that should put a premium on good software engineering, be standards minded, have good documentation.

Sheesh. Take my problem. ssh comes with a tool (ssh-keygen) that generates the public/private key pair for ssh usage. Given the private key, you can always reconstruct the public part:

# ssh-keygen -y -f ~/.ssh/id_rsa > ~/.ssh/id_rsa.pub

The private key is in a format (PKCS#1, PEM-encoded) that openssl understands. Crucially, the .pub file is in a different, largely undocumented, format. And my problem was: convert the .pub part of an openssh key pair to an openssl compatible format without having access to the private part. In fact. If the private key is available, that is easy:

# openssl rsa -in mykey.pem -pubout > mykey.pub

Most of my time was spent in finding out that - if you have access to openssh 5.6 and later (not to be found on several servers, chiefly the RHEL6 based ones) ssh-keygen will do the deed for you:

# ssh-keygen -e -m pem -f id_rsa.pub

But God helps you if your version is less than 5.6, because - in that that case - ssh-keygen will happily perform several tricks on your .pub file except the one that's needed. And openssl. will not help either. So what you need is a custom program (Hello, Lars!) - and not even one that any schmuck could write.

Which takes me to my rant.

Why is the field of encryption cursed with scores of obscure, incompatible formats that almost no one cares to make explicit (yes that's PEM, DER, PKCS#1, PKCS#8, ASN1.1, BER...I could go on, but won't). Why do we need more than one? (because none of these formats is worth its salt, that's why)
And, most importantly, why none of the aforementioned formats is self documenting? Why won't the toolset be so kind to inform its user on what's going on, or even, for God's sake agree with itself?

Take Bob - a not very experienced, not very cultured sysadmin which receives a file named fubar. Bob's task is to figure it out. Now, Bob suspects fubar may have something to do with encryption (generally) and openssl (specifically). So, being a sysadmin, Bob tries to throw the toolset at fubar.

If the toolset was sane that's what would happen:

# openssl fubar

RSA Public-Key: (2048 bit)
Modulus:
...

But the toolset is insane, so what actually happens is this:

# openssl fubar
openssl:Error: 'fubar' is an invalid command.
[...Bob selects a random command and tries again...]

# openssl x509 fubar
unknown option fubar
usage x509 args
[...Bob reads usage....] 

#openssl x509 -in fubar
unable to load certificate
140191632783176:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:703:Expecting: TRUSTED CERTIFICATE

[man openssl,head,..... gotta be a public key (rsa? dsa? coin toss)]

# openssl rsa -in fubar
unable to load Private Key
140524681410376:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:703:Expecting: ANY PRIVATE KEY

[...time and 10001 curses pass....]

# openssl rsa -pubin -text -in fubar
Public-Key: (2048 bit)
Modulus:

Note that, throughout this process,  Bob is not gaining any useful insight on the world of encryption, data security, etc. He is just being trained with electric shocks, mouse-in-a-maze like, to remember the quirks of one of the quirkiest user interfaces ever.

I find the bit where "openssl rsa -in " refuses to yield any information on fubar unless the right switch is flipped particularly delightful. This is bad interface design at its finest: it doesn't get any worse than that.

The rant would go on (why do CAs that have certificate chains do not distribute them along with their certificates? and why o why cannot it be all in the same file? and why o why o why they change it every other Wednesday and hide it in a different web place? and why o why o why o why if you forego the chain file - whose internal composition has to be guessed by trial-and-error -  browsers react as if your cert had been signed by George "Baby Face" Nelson?) but I feel that, for today, this may be enough.

Next guy that tells me "You know, people don't really care about data privacy, 'cos they're lazy", ends up on a gore image board. I guarantee it.

P.S.: Don't get me wrong: I do think that openssl and openssh are a godsend gift to the computing world, and I am thankful for that. But their UIs? Ouch.