
PKI for busy people - crehn
https://rehn.me/posts/pki-for-busy-people.html
======
hannob
The part about signatures is not really correct.

It says: " To sign a message, encrypt it with the private key To verify a
signature, decrypt it with the public key and make sure it matches the
message"

This is only half true for one algorithm: RSA. But even there it's only true
for something called "Textbook RSA", which is an insecure variant of RSA
nobody should be using. It's not true for any real algorithm.

I'm really not a fan of such sloppy "I want to explain it easy" crypto
introductions that are simply not correct.

(Also found it odd that he uses "Verisign" as an example for a CA. Verisign
has been bought by Symantec and Symantec was distrusted by browsers recently,
so it's as dead as it can be.)

~~~
cheez
I presume what you're saying is that there is a whole set of missing
verification additions, but if not, what are you referring to for textbook RSA
being insecure?

~~~
tialaramex
You need to "pad" the number that will be signed so that it's the right size
and shape to fit, or else bad guys can choose for you to sign a number that
makes it very easy to find your private key by looking at the signature which
is clearly a terrible outcome.

Remember RSA is just very simple maths, done with huge numbers. If you pick
the right "huge" numbers things that look hard become very easy indeed. So we
need to ensure we never pick them.

The correct way to do this, which a lot of systems haven't adopted yet, is
called RSA-PSS, the Probabilistic Signature Scheme. PSS has a proof that says
if you believe RSA works, and assume certain other reasonable things, this is
actually safe.

Before RSA-PSS (and still today in lots of backwards compatible systems),
people used PKCS#1 v1.5 which has a scheme somebody threw together to do some
padding but without any great insight. There is no security proof for PKCS#1
v1.5, it's probably safe, ish, but we can't be sure.

~~~
consp
> There is no security proof for PKCS#1 v1.5, it's probably safe

As long as you avoid the known problems, it probably is safe for signatures
and the main problem now is that PSS is not included in lots of standards
which thus require PKCS1_1v5. This prevents major implementation due to those
standards not being updated fast enough.

As an example of slow adoption: The HSMs i'm currently using only started
native support for PSS last year, about 20 years after it's introduction.

Please note that pkcs1_1v5 is never secure for encryption/decryption schemes.

------
cwingrav
The author of this needs to write a few more on other topics. The succinctness
and simplicity (i.e. minimum bits) is a nice change from so many documentation
sites. Can Amazon get him to rewrite their documentation?

~~~
Edmond
I suspect it only seems succinct because you're familiar with the details...I
like it too for that reason.

However for anyone who doesn't have the requisite background it will just be
abstract and impenetrable.

~~~
chrismeller
I somewhat agree. I feel like this is a nice glossary that I could hand my
boss so he would understand what we’re talking about and stop asking what each
one is, but he still wouldn’t really “get” the process for any of the
examples.

If it tried to explain the full process you’re now diving into the
explanations of GPG and buying SSL certs, etc and that feels like their eyes
would simply glaze over.

I would like to see a tad more separation between the types of PKI
(specifically GPG vs TLS type clarity).

------
nlawalker
Is there something like this specifically for certificates that goes into a
little more technical detail? Every description I've ever read of certificates
doesn't go much further than what's in this article ("a name and public key
bound by a signature").

I've never really been able to get my head around things like when and how a
certificate also contains a private key (and when that private key is
"exportable"), what all the "key usages" are and where they get their strange
identifiers from (and how those things are actually enforced and used), etc.

EDIT: I should have kept reading, the linked Wikipedia articles on X.509,
ASN.1, DER and PEM in the next section appear to be about what I'm looking
for. I suppose I've just always been confused by all the formality and the
number of specifications about different things.

~~~
malingo
This article has some good depth; it was posted on HN a few months ago.
[https://smallstep.com/blog/everything-
pki.html](https://smallstep.com/blog/everything-pki.html)

~~~
mdaniel
Wow, that is a _crazy good_ article. I aspire to be able to write that clearly
about such a complex and messy topic. And, it did its job as a promotional
piece because TIL about Smallstep

------
seertaak
This was incredibly useful, many thanks for posting. In particular I was
really confused about the difference between ".der" files and ".pem" files.
The concise, pithy, style makes reading very easy.

------
kgoutham93
> Since binary data can be a pain to transmit, it’s often further encoded into
> PEM. PEM is essentially just Base64-encoded DER.

Why's binary data a pain to transmit and how does base64 encoding help with
that?

~~~
munchbunny
There are usually far more ways to move text around than arbitrary binary
bits, such as copy-pasting in terminals and web forms. It also lets you embed
certificates in formats that don't normally support literal binary data, such
as JSON.

~~~
mdaniel
To add to this already good explanation, it's my understanding that base64 and
the MIME packaging scheme were invented because many early Internet protocols
made a distinction between text mode and binary mode due to the majority of
the protocol framing being text. You can thank them for that textual
decision(?) when you're debugging SMTP with a copy of netcat, but it means
that a PDF attachment needs to be encoded to travel over email.

To bring this conversation back to PKI, base64 encoding means you can embed
the GPG signature of your email body in the text itself, without having to
deal with attachments like S/MIME does

------
AnonC
> Root certificates are trusted and stored locally. They’re usually shipped
> along the OS.

They're also shipped with the browser, as is the case with Firefox. They may
also be shipped with applications (some versions of Visual Studio seem to have
their own certificate store).

~~~
Spivak
They're also shipped with application runtimes in the case of Java.

------
chrisweekly
This is an excellent summary. Helpful to have such a clear and concise
overview to share as a reference when working with clients with varying levels
of understanding. Bravo, and thank you!

------
runiq
While it's great to have resources like this, I feel that this should come
with a giant disclaimer at the top, reading something like:

>WARNING: This is just the tip of the iceberg. Also, ice is generally
slippery. If your crypto knowledge amounts to the stuff presented here, stick
to known, battle-tested implementations.

------
ggm
Seems a bit over-brief in some ways, hashing needs a little more. But overall,
this is very useful. It gave me some confidence over slidepacks I've done as
basic introductions, but rather then spin my own I'd like to point to words
like this which are both curated and reviewed.

So. .. thanks!

------
gerdesj
_A certificate is a name and public key bound by a signature. It identifies
the owner of a public key._

A certificate _identifies_ a name.

 _The signee is called a certificate authority (CA). The CA is often some big
company, like VeriSign. With internal PKI, it can be any entity that nodes
have been configured to trust._

A CA _authenticates_ the identity claimed by a certificate.

 _A CA’s certificate can be signed by another CA, and so on. The last
certificate in the chain is called a root certificate. Root certificates are
trusted and stored locally. They’re usually shipped along the OS._

There can be a chain of trust whereby one CA authenticates the next.

Its a tricky subject and I don't think it is really possible to get too far
beyond "give me £100 for this SSL certificate" ... "because" ... _sigh_ [fill
in your own SSL related conversations with your PHB stupidity here]

------
ct520
Interesting.. Wait till you get validating cert chain without the carts
issuing cert. following AIA fun stuff the things cert issuers can return

------
leowoo91
PKI stands for "Public Key Infrastructure" in the article, I thought it would
be about performance key indicators.

~~~
cpach
You’re probably thinking of KPI, Key Performance Indicators.

~~~
leowoo91
Right, thank you for heads up.

