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.