[Cryptography] Why prefer symmetric crypto over public key crypto?
Bill Stewart
bill.stewart at pobox.com
Sat Sep 7 14:07:39 EDT 2013
>On 7/09/13 09:05 AM, Jaap-Henk Hoepman wrote:
>>>Public-key cryptography is less well-understood than symmetric-key
>>>cryptography. It is also tetchier than symmetric-key crypto, and
>>>if you pay attention to us talking about issues with nonces,
>>>counters, IVs, chaining modes, and all that, you see that saying
>>>that it's tetchier than that is a warning indeed.
>>
>>You have the same issues with nonces, counters, etc. with symmetric
>>crypto so I don't see how that makes it preferable over public key crypto.
At 12:57 AM 9/7/2013, ianG wrote:
>It's a big picture thing. At the end of the day, symmetric crypto
>is something that good software engineers can master, and relatively
>well, in a black box sense. Public key crypto not so easily, that
>requires real learning. I for one am terrified of it.
Public-key crypto requires learning math, and math is hard (or at
least ECC math is hard, and even prime-number-group math has some
interesting tricks in it.)
Symmetric-key crypto is easy in a black-box sense, because most
algorithms come with rules that say "You need to do this and not do
that", yet the original PPTP did half a dozen things wrong with RC4
even though the only rule is "never use the same state twice."
But if you want to look inside the black box, most of what's there is
a lot of bit-twiddling, maybe in a Feistel network, and while you can
follow the bits around and see what changes, there can still be
surprises like the discovery of differential cryptanalysis.
Public-key crypto lets you use math to do the analysis, but [vast
over-simplification] symmetric-key mostly lets you play around and
decide if it's messy enough that you can't follow the bits.
But there are other traps that affect people with either kind of
system. Once PGP got past the Bass-o-matic stage, the biggest
security problems were mostly things like variable-precision numbers
that were trying so hard to save bits that you could trick the
program into interpreting them differently and accepting bogus
information. Fortunately we'd never have problems like that today
(yes, ASN.1 BER/DER, I'm looking at you....), and nobody ever forgets
to check array bounds (harder in modern languages than in C or
Fortran, but still quite possible), or fails to validate input before
using it (SQL injections), etc.
More information about the cryptography
mailing list