[ISN] Home grown crypto is bad crypto. (+contest)

From: InfoSec News (isnat_private)
Date: Thu Jan 23 2003 - 03:26:47 PST

  • Next message: InfoSec News: "[ISN] Master Key Copying Revealed"

    |  Linux Security: Tips, Tricks, and Hackery                       |
    |  Published by Onsight, Inc.                                      |
    |                                                                  |
    |  22-January-2003                                                 |
    |  http://www.hackinglinuxexposed.com/articles/20030122.html       |
    This issue sponsored by Onsight, your Security Solution
    Onsight, Inc is a consulting firm specializing in network security.
    Our network consultants have extensive experience in host security
    for all Unix flavours, from Solaris and *BSD to HP-EX and Irix. We
    can provide custom firewall solutions, Intrusion Detection systems,
    assist in log monitoring and analysis, and clean up your systems
    after successful cracker intrusions.
    Of course, our speciality is Linux security and systems - we wrote
    the book on it: Hacking Linux Exposed. If you want to protect your
    Unix network from crackers, you want to talk to us.
    For more information, see http://www.onsight.com or email 
    Home grown crypto is bad crypto. (+contest)
    By Brian Hatch
    Summary: Every programmer tries to build their own encryption
    algorithm at some point. In one word: Don't.
    Cryptography is a fun but tricky art. Almost every programmer has at
    some point in their career tried to write their own cryptographic
    algorithms. While the computations used to create the resulting
    encrypted output may be complicated and seem rock solid, usually
    custom cryptographic algorithms end up falling for one or more
    classic crypto pitfalls.
    Substitution ciphers
        While you may have pages upon pages of input manipulation, many
        custom written algorithms result in simple substitution ciphers.
        The most basic example, ROT13, shifts each English letter 13
        spaces, wrapping around at "Z". This simply replaces "a" with
        "n", "b" with "o", "c" with "p", and so on. Thus "Apple Baker"
        becomes "Nccyr Onxre".
        Custom ciphers usually create a much stronger illusion of
        security because the resulting output is less legible than the
        input. However this doesn't change the fact that the cipher boils
        down to a degenerate substitution cipher, which can be cracked
        fairly easily. Some would even consider substitution ciphers to
        be obfuscation, rather than a cipher in it's own right, they are
        so breakable.
    Poor key strength
        Ideally the security of a cryptographic algorithm should depend
        on the strength of the keys used for the encryption. Take for
        example an algorithm which relied on XORing[1] the unencrypted
        input with a stream of data. In this case, our stream can be
        considered a key[2]. So, say your key (some string of bytes) was
        100 characters long in this case - that'd be plenty to protect a
        message that was less than 100 characters long. But if you needed
        to keep reusing that key for a 1 Mb message, a cryptographer
        would have a much better chance of deciphering the message.
    Key Reuse
        Cryptanalysis, the attempt to decipher encrypted text, is easiest
        when you have the same message encrypted more than once (known
        plaintext attack) or the same key is reused to encrypt different
        plaintext streams. For example if we used our 100 character long
        XOR key to encrypt several different <100 character messages, we
        can perform some mathematical handiwork against the results to
        learn about and eventually discover the key itself.
    Failing to keep the key secret
        The worst case of key use is when you include the key in the
        encrypted message itself in some way that allows it to be
        recovered. A message encrypted with PGP, for example, has several
        keys. The message is encrypted with an encryption cipher (for
        example Blowfish, 3DES, or AES) using a random key for the
        message. This key is stored in the PGP file itself, however it is
        encrypted with the recipient's public key, such that only the
        recipient can decode the key and thus decode the message.
        Unfortunately, many home-grown crypto algorithms attempt to avoid
        key reuse by imbedding the key in the encrypted file itself with,
        perhaps, some minimal obfuscation. Not good.
    These are just some of the problems that come up time and time again
    when someone creates their own cryptographic algorithms. If you want
    to securely encrypt data, you should use any of the freely available
    systems, for example PGP for files, SSL for network connections, or
    Blowfish/AES/etc for arbitrary data encryption. When using public
    cryptographic systems you must still take care to use them properly
    -- don't use SSL unless you verify certificates on both ends, don't
    reuse the same key for Blowfish encryption, etc -- but at least the
    algorithm itself will be one that has been scrutinized by respected
    So, why did this all come up today? I was working with a client and
    was curious why their database was filled with seemingly meaningless
    data. They told me it was the encrypted billing info for the clients.
    Looking at it, I could tell that they'd whipped up some "encryption"
    algorithm on their own, and sat down and broke it.
    Now, it's your turn.
    I've encrypted five strings (normal printable English) using this
    week encryption algorithm. If you're able to decrypt the input
    strings, send me an email explaining how you did it. The best writeup
    works will get a copy of Hacking Linux Exposed, Second Edition in the
    On Sunday morning, I'll post a hint or two on this page[3] for those
    who need the extra help. Entries submitted before I post hints will
    be prefered over those received later.
    Here are the encrypted strings:
    Happy decrypting!
    [1] XOR is the exclusive bitwise OR operation, frequently used in
    cryptographic algorithms. It boils down to this: 0 XOR 0 == 0, 0 XOR
    1 == 1, 1 XOR 0 == 1, 1 XOR 1 == 0.
    [2] Usually this stream is actually created by some mathematical
    algorithm, where the algorithm is seeded by an actual key.
    [3] Those reading this newsletter in email, check the web page
    version at http://www.hackinglinuxexposed.com/articles/20030122.html
    for the hints.
    Brian Hatch is Chief Hacker at Onsight, Inc and author of Hacking
    Linux Exposed and Building Linux VPNs. He developed his first
    (horribly insecure) cryptographic algorithm when he was six. It was
    no better than ROT13, but took up a lot more space and CPU power.
    Brian can be reached at brianat_private
    This newsletter is distributed by Onsight, Inc.
    The list is managed with MailMan (http://www.list.org). You can
    subscribe, unsubscribe, or change your password by visiting
    http://lists.onsight.com/ or by sending email to
    Archives of this and previous newsletters are available at
    Copyright 2003, Brian Hatch.
    ISN is currently hosted by Attrition.org
    To unsubscribe email majordomoat_private with 'unsubscribe isn'
    in the BODY of the mail.

    This archive was generated by hypermail 2b30 : Thu Jan 23 2003 - 06:21:58 PST