[Cryptography] Why prefer symmetric crypto over public key crypto?

[Bill Stewart]

>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.