Computer Journal

Practical Cryptography and Cryptanalysis
by Joel R. Voss aka. Javantea, help from Crash
jvoss@altsci.com
jvoss@myuw.net
Sept 22, 2006
Update: May 9, 2007

Crypto1 0.3 Source [sig]
Crypto1 0.2 Source [sig]

Neg9 Meeting thread

PGP/GPG

GPG is an easy and open source public key encryption solution. Many e-mail clients support it as well as a few IM clients. Neg9 uses GnuPG for secure e-mails. Crash's key expired recently, which allowed us to discuss how to update the key. Crash already generated a new key which he signed with his old key. You can download his new key at his website. When you import the key
gpg --import crash_pub.asc, it will be properly usable. with the signatures that you may have done during a keysigning with Crash's old key.

SSL/TLS

The SSL/TLS system is a combined public key authentication and key exchange with symmetric cryptography protecting application data. It is quite simple and rugged with support for many protocols and and programs. A capture of https traffic can be found in ssl1.cap in crypto1-0.2.tgz. Using Wireshark, we were able to see the common ssl handshake described below:

1. ClientHello (Version, Cipher Specs, 128-bit random).
2. ServerHello (Version, Cipher Specs, 224-bit random), Certificate, ServerKeyExchange, CertificateRequest, ServerHelloDone
3. Certificate, ClientKeyExchange, CertificateVerify, [ChangeCipherSpec], Finished
4. [ChangeCipherSpec], Finished

In Dan K's Black Ops talk at Defcon 14, he revealed that a certain large company uses the same SSL cert for all their machines. This is a massive problem since one compromise would lead to the decryption of all traffic on their network.

There are tools for ssl tunneling and so forth. The OpenSSL program has a command-line tool for testing SSL.

VPN

Neg9 uses an OpenVPN for security in local traffic as well as obsfucation of intent. This does not encrypt LAN traffic and it does not encrypt the traffic outside the VPN. Between hosts on the VPN, the traffic is encrypted. It is easy to setup and it is fast. OpenVPN uses OpenSSL. Crash explains how to setup OpenVPN on the Neg9 forums.

Disk Encryption

Dyn explains dm-crypt on his website. Crash explains how he setup an encrypted filesystem on deficit.neg9.org.

Cryptanalysis

The bar is being raised in cryptography at an alarming pace. Back when Triple-DES was considered secure, the Department of Energy was able to crack a strong password to reveal the exploits of Kevin Paulsen by cracking his files encrypted with Triple-DES. Each year at cons, groups like Shmoo provide new cracks wireless encryption protocols, WEP, WPA, and WPA2. These cracks are being put into use daily by hackers and laymen alike.

NTLM: Rainbow Tables

The Shmoo Group distributes rainbow tables for lanman passwords. Using these and the software rainbowcrack, Microsoft Windows passwords can be cracked. The lack of a salt when being stored on disk makes these NTLM passwords vulnerable to this attack. As the rainbowcrack page explains, NTLM passwords are salted when transmitted over the network and cannot be as easily cracked with rainbowtables. Neg9 is currently in the process of attempting to generate rainbow tables for md5 and other hashes.

Keysize

Keysize is an important factor in cryptography. When you reduce the keysize of good algorithms, you have a crack. Although my source is missing, there was a controversy about accounting software adding encryption to their files (which is quite important). The controversy was about the NSA requiring these companies to weaken the keysize so that it could be broken by the DoE like in the case of Kevin Paulsen. The compromise was that the key would be full size, but that the NSA would have control over a certain number of bits in the key. If the key was generated like this:
key = rand() + NSA key, then anyone could crack the key by simply cracking the program to find the NSA key, then cracking the random part of the key. However, a different way exists that software companies commonly use for this same tactic:
key = SHA(rand() + NSA key). The problem with this is the same as the first, though. Knowing the NSA key, any attacker could get the key by reverse engineering the program and then brute forcing the random part of the key.

Problem with simple passwords

Sadly, even when using the full keysize with pseudo-random data, you run into the problem of password protection. For example, OpenSSL's enc program can encrypt files or data with several algorithms. Blowfish-CBC is one of the more secure algorithms because it takes thousands of rounds of decryption to decrypt the first block. The blocks after that only take a single round. For brute force, this is quite difficult. However, against weak passwords, it is easy to brute force even the toughest cipher.

This makes for the premise of Blowfish Bruteforce Attack that I wrote to show the weakness of small passwords. The version 0.1 that I released at the Neg9 meeting attacks 3000-9000 passwords per minute depending on hardware. The version 0.2 that I released the next day attacks 11000 passwords per second (an improvement of around 16000%). This means that short/simple passwords are no match against attackers that have the ciphertext.

Decryption failed (bad password):
10333:error:06065064:lib(6):func(101):reason(100):evp_enc.c:461:
10333:error:0906A065:lib(9):func(106):reason(101):pem_lib.c:425:
You forgot to call OpenSSL_add_all_ciphers():
14617:error:0906B072:lib(9):func(107):reason(114):pem_lib.c:481:

The idea of using a key which is encrypted with a password was brought up. If you bring the only key around with you on a medium that you can reasonably expect to destroy without incriminating yourself in the process, then yes, this will work. Otherwise, it is as bad or worse than encrypting the data with the same password.

Problem with XOR

XOR is a popular encryption algorithm because of it's obvious simpleness and strengths. A pseudorandom secret can be protected by random key quite well. In fact, a completely random one-time pad is unbreakable for any secret. If the one-time pad remains secret for the duration of the use of the data, then the secret remains secret. However, the one-time pad must be the same size as the data. Being completely random, it is uncompressable. Most people wish to reduce this size to a managable number that remains secure.

Stream ciphers are one way to do this. Stream ciphers work by seeding a psuedorandom gamma generator (like srand or sha1(data+key+iv)) with the key. To crack this, the attacker must try each permutation of the key (which is fairly impossible). However, this method of encryption is vulnerable to know plaintext attack.

Dmitry Sklyarov points out a simple example of this. If the data is 0x00000000, the cipher text is equal to the key used at this point.

enc = key & 0x00000000?

gamma(key)[200:256] == ciphertext[200:256]

Problem with EBC

Block ciphers are commonly used in encryption for their strength. EBC is the simplest mode of block ciphers where the same key is used on each block of plaintext. There is a weakness in this mode that large data sets will show statistical concurrance. A good example of this is Wikipedia's article on Block cipher modes where an uncompressed image is encrypted with EBC. It is easily identifiable by looking at the raw ciphertext as an image.

CBC is a common mode used since it's use of the initialization vector (iv) makes it resistant against this attack.

Corporate crypto implemented improperly

Dmitry Sklyarov's book is an excellent example of corporate cryptography gone wrong. Instead of protecting sensitive data with cryptography like they should, corporations have built business models around encryption of data that consumers must view. This system of DRM robs the consumer of their fair use right to read as they wish, lend, and copy their data. The only benefit that consumers or businesses see from DRM is the slight reduction in piracy by consumers. However, since DRM cracks are so widespread and easy to use, piracy is still rampant even in the less technical crowds that respect property rights.

Common attacks against DRM are: debugging, reverse engineering, analog hole, and illicitly obtaining the plaintext via other means. For example, DRM programs often look for drivers and programs that hook into existing kernel drivers which can view memory. By viewing the memory of a DRM program, a key can be found either plainly or in an obsfucated fashion. Keys are sometimes stored in the client executable or in a registry. Often, however, the key is sent over the wire unencrypted, so it can be sniffed with a packet capture program. If none of these work, the output of the program can often be grabbed on its way to the renderer or after the renderer has rendered it either via digital interface built into the kernel or via the analog output signal.
The common explanation of cracking DRM is that at some point the attacker has both the ciphertext and the key and the plaintext, therefore ensuring the eventual crack of the DRM.

Outdated technology

MD5 hashes
MD5 hashes are no longer considered secure. For passwords and data integrity, MD5 is bad news. Simple collisions can be generated in ~1 min. Many groups including Neg9 are generating rainbow tables for MD5. Like NTLM, using a salt helps for passwords. Still, MD5 should not be used since SHA1 is quite a bit better in general security.

SHA1 hash
Due to recent attacks on SHA1, it is also being deprecated in favor of more secure hashes (SHA256 and SHA512). If you have a different library available, you should work on switching. SHA1 is also vulnerable to the rainbow tables attack. SHA1 is still usable if you require backwards compatibility, but do not use it if you can avoid it. Also, don't keep a sha1 hash of any password in your source code or executable. It will be easily broken.

Coding mistakes

While simple coding mistakes have still not been eradicated, they top the list of cryptography errors. Buffer overflows, heap overflows, data leakage, file permissions, shell injections, and so on plague the security community. However, great advances have been made in the general security of most open source programs so that cryptographers and cipher punks alike can rest easy that their code is ok for the next 2 months. The relentless pursuit of secure code remains an important task for any cryptographer.

Advanced coding mistakes find their way into sloppy implementer's code quite often, which makes for very odd manual hacks against individual targets. These include, but are not limited to:

• Not shredding memory after use
• Getting xor and pow mixed up
• A plus where a minus should be
• Encrypting something, then giving the data away.
• Long urls make your e-mail look like a phish.
• Akamai makes your site look like a phish.
• nyud.net looks like a phish.
• No peer review
• No independent oversight

Pseudo-random passwords

Pseudo-random passwords are related to cryptography in that they cover similar areas. A psuedo-random password is often generated when the user of a website or a program is not trusted to create a strong enough password. However, since the user cannot remember their password, they will store a copy of the password. This is insecure that any compromise to the machine will compromise the access to the service as well. Pseudo-random passwords can be temporary or they can be used for passwordless entry. Many websites use session cookies to keep the logged in state of a website visitor. This session cookie is as good as a password for the duration of the session. If the website stores an autologin variable as a cookie permanently, this widens the attack vector by a large margin.

Craig's List is a recent example of passwordless entry to sensitive information. When a user posts a listing, they receive an e-mail with a url that allows them to publish the listing. The pseudorandom editing password is contained in the url. The password is in the form xyzf5, which has the strength of 26^4 * 10 = 4,569,760. It's either pseudo-random or cryptographically secure random, so a pseudorandom generator would be the best bet for a bruteforce attack.

An easy solution to this problem, which I expect that Craig's List has implemented is IDS: anyone giving a wrong combination 10 times is blocked. However, this may deter legitimate users, so an exception to this IDS is to only block for 1 minute with a message: "Sorry, check back later." This method may be defeatable by Tor/botnets though. However, a method of blocking frequently attacked posts may work against this attack.

How many custom/ready-to-serve web systems use bad password systems? Easily half of all web password systems are insecure to reasonable attacks. Also, the lack of SSL on extremely sensitive websites makes the sniffing of passwords much more a threat. Yahoo didn't use SSL until recently, Gmail also. The Wall of Sheep at Defcon grows each year with a list of inane sites that do not use SSL encryption.

The tarball should be almost self explanitory.
More detailed information coming soon.

Cryptography is an important security topic with many practical uses and new implications. The poor use of cryptography makes a large gap between perceived and actual result of cryptography. Best practices and peer review is an excellent method of ensuring cryptographic security in the year 2006.