[ISN] Top 10 candidates for a "duh" list (general sec/crypto)

From: cult hero (jerichoat_private)
Date: Fri May 28 1999 - 19:16:42 PDT

  • Next message: cult hero: "[ISN] What's a Little Hacking Between Friends?"

    [Very good run-down on what isn't acceptable crypto. - Jay]
    Forwarded From: "Jay D. Dyson" <jdysonat_private>
    Originally From: "Arnold G. Reinhold" <reinholdat_private>
    Courtesy of Cryptography List.
    At 1:36 PM -0400 5/27/99, Kawika Daguio wrote:
     What I would like to know from you is whether you and others have been
    able to construct a "duh" list of typical, but unacceptable current
    practices that can easily be remediated.
    Here are my top 10 candidates for a "duh" list:
    1. Keys that are too short: Anything less than 80 bits for symmetric
    ciphers (128-bits prefered), or 1024 bits for integer-based public key
    systems. In particular this precludes use of 56-bit DES. (112-bit 3DES is
    2. Poor quality random number generation. Random quantities are needed at
    many places in the operation of a modern cryptographic security system. If
    the source of randomness is weak, the entire system can be compromised. 
    3. Use of short passwords or weak passphrases to protect private keys or,
    worse, using them to generate symmetric keys. Bad passphrase advice
    abounds. For example, both Netscape and Microsoft advise using short
    passwords to protect private keys stored by their browsers. The simple fix
    is to use randomly generated passphrases of sufficient length. See
    4. Re-use of the same key with a stream cipher. I have seen this done many
    times with RC4.  Even Microsoft appears to have gotten this wrong with
    their VPN (I do not know if it has been fixed). There are simple
    techniques to avoid this problem but they are often ignored.  See
    http://ciphersaber.gurus.com for one method. The potential for slipping up
    in stream cipher implimentation makes a strong case for using modern block
    ciphers wherever possible. 
    5. Using systems based on encryption techniques that have not been
    publically disclosed and reviewed. There are more than enough ciphers and
    public key systems out there that have undergone public scrutiny.  Many of
    the best are now in the public domain: 3DES, Blowfish, Skipjack, Arcfour,
    D-H, DSA. Others, e.g. RSA, IDEA can be licensed. 
    6. Ignoring physical security requirements for high value keys. In
    particular, no secret key is safe if it is used on a personal computer to
    which someone who is not trusted can gain physical access. 
    7. Lack of thorough configuration management for cryptographic software. 
    The best software in the world won't protect you if you cannot guarantee
    that the version you approved is the version being executed. 
    8. Poor human interface design. Cryptographic systems that are too hard to
    use will be ignored, sabotaged or bypassed.  Training helps, but cannot
    overcome a bad design. 
    9. Failure to motivate key employees. Action or inaction, deliberate of
    inadvertent, by trusted individuals can render any security system worse
    than worthless.  David Kahn once commented that no nation's communications
    are safe as long as their code clerks are at the bottom of the pay scale. 
    10. Listening to salesmen.  Any company that is selling cryptographic
    products has a good story for why the holes in their product really do not
    matter. Make sure the system you deploy is reviewed by independent
    Arnold Reinhold
    Subscribe: mail majordomoat_private with "subscribe isn".
    Today's ISN Sponsor: OSAll [www.aviary-mag.com]

    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:24:03 PDT