[Info-vax] VSI has released 9.2-1

[John Dallman]

In article <u6r05u$2b1q4$1 at dont-email.me>, davef at tsoft-inc.com (Dave
Froble) wrote:

> People who really care about security of course may use SSL, but 
> then what happens when the encryption is broken?  The user's data 
> is available to the hackers.  But what if the app developers 
> insured that the data, if encryption is defeated, doesn't really 
> mean anything to the hackers.  Some custom stuff in addition to SSL 
> and such.  Yeah, even then, some hacker might figure out the data.  
> But isn't it better to make it as tough for the hacker as one can?
> 
> Now I'll hear from some "you got to use standards".  I'd ask "why?" 
> The problem with standards is, everybody knows them.

The SSL standards, and the TLS standards that have succeeded them, do
something that's actually quite hard, which is to let two ends of a
communication link agree on an encryption key without ever passing that
key over the link, or having any kind of default key or other shared
secret. 

They do that part via cleverness with public-key encryption, and use it
to agree on a key for symmetric encryption. Those are significantly
different kinds of encryption: you can't do the key-agreement part in a
practical way with only symmetric encryption, and public-key encryption
is too slow for sending any volume of data. 

<https://en.wikipedia.org/wiki/Public-key_cryptography>
<https://en.wikipedia.org/wiki/Symmetric-key_algorithm>
<https://en.wikipedia.org/wiki/Transport_Layer_Security> 

Note that you do get to tell your end of the TLS link what public- and
symmetric algorithms you are willing for it to use, and what key lengths
you demand. If the other end can't meet your demands, you can't
communicate, but that's failing to the secure case. 

The main reason for using standard TLS, rather than creating your own
version, is that doing that right is /hard/, and anyone doing it
themselves is certain, at a practical level, to create something worse
than TLS. 

The standards have been reviewed and attacked by large numbers of experts
over years. Versions 1.0, 2.0 and 3.0 of SSL have been cracked and
deprecated; versions 1.0 and 1.1 of TLS are also cracked and deprecated.
TLS 1.2 has vulnerabilities that are currently difficult to exploit and
will be deprecated in the next few years; TLS 1.3 is currently sound. 

Cracks of those standards aren't a question of finding out how to read a
secret code or cipher that they use, or cracking public-key encryption,
but of finding flaws in the way that they /use/ public-key encryption so
as to give clues about the (entirely random) symmetric encryption key
that they are used to agree on. Those standards are treated as cracked as
soon as a way to get significant information about the negotiated key is
published. That doesn't mean that everything sent over them has become
readable: being able to discover a few bits of a 128- or 256-bit key is a
"crack." Thereby, they are deprecated long before breaking them becomes
practical. 

Now, using additional encryption on the data you're sending over TLS is
certainly possible. However, it isn't all that practical. You need to
agree an encryption key between the two ends. You can do that via
communication through the TLS link, but if that's being read by an
opponent, they just got the key you're about to use for your data. 

If you do TLS-through-TLS, that could work, provided the TLS you're using
is not cracked. But it's just easier to use a single layer of TLS and
require it to use longer public keys and stronger symmetric algorithms. 

The secondary reason for using standard TLS is that it allows you to
communicate with anything else that uses it. Other implementations, other
operating systems, and so on. 

Now, that may not be important to you. You may be building a system where
only specific computers are to communicate with each other. It is still
worth considering using standard TLS, for several reasons: 

* The protocols are very likely better than anything home-built. 
* If the TLS protocols are cracked, you'll hear about it early on.
* If a homebrew protocol is cracked, your opponent won't tell you. 
* Distributing symmetric keys any other way is harder. 

Alternative ways of distributing keys require sending some kind of
computer-readable physical medium. It needs to be hard to copy, and it
needs to arrive /very/ reliably. If your system won't be in use long,
this may be practical.   

How do you tell which public-key and symmetric algorithms are good?
Knowledge of the field. 

The current gold standard for symmetric is the Advanced Encryption
Standard, which is approved by the NSA for Top Secret information. 
<https://en.wikipedia.org/wiki/Advanced_Encryption_Standard>

The current gold standard for public-key is RSA with a key of 4096 bits
or longer. This is currently expected to be menaced by quantum computers
within a decade, and the NSA is starting a transition to post-quantum
cryptography. For now, it's the best we have and is very unlikely to be
broken soon. 

John