Hackszine.com: Cryptography Archives

Archive: Cryptography

Page 2 of 2 << 1 2

November 18, 2007

MD5 collision demonstration

MD5, the cryptographic hash function that's often used to verify that files have not been tampered with, has been broken for a couple of years now. A lot of times when you hear about some algorithm being compromised, it's not something that's immediately practical to exploit... an encryption algorithm's effective strength is reduced by a bit or two, or maybe a hash function has been compromised such that a huge amount of computational effort can make a completely bargled file that has an identical checksum to a known source. Not so in the case of MD5, as Peter Selinger describes:

It is now well-known that the crytographic hash function MD5 has been broken. In March 2005, Xiaoyun Wang and Hongbo Yu of Shandong University in China published an article in which they describe an algorithm that can find two different sequences of 128 bytes with the same MD5 hash. ... As we will explain below, the algorithm of Wang and Yu can be used to create files of arbitrary length that have identical MD5 hashes, and that differ only in 128 bytes somewhere in the middle of the file.

Selinger's example exploit will allow you to produce two working executable files with different behaviors, but matching checksums. Presumably, one would be a file with the intended behavior, and the other an "evil" version that could be slipped in as a replacement without anyone knowing. Pretty interesting stuff.

Collisions in the MD5 cryptographic hash function - Link

November 5, 2007

How NOT to use TOR

A lot of people use TOR as a sort of anonymity and encryption magic bullet, but that's really not what it's designed for. Your packets are encrypted and routed through various TOR nodes, each node only knowing about the node on either side of it and unaware of the full routing path, until finally it pops out of an exit node, is decrypted and then sent along its way to the destination. The fundamental idea is that only the exit node knows the final destination, and it doesn't know where the packet originated unless the operator of the exit node is in cahoots with all the other nodes along the packets' route. TOR is a routing anonymization service.

A couple of months ago, 100 government and embassy email account passwords were published by Dan Egerstad. What did these email accounts have in common? Individuals from these organizations were presumably using the TOR network to protect their communications, but by sending unencrypted traffic over the TOR network, they were actually exposing this data to a lot of potentially nefarious parties. But wait, the data moving over the TOR network is encrypted, right?

Which brings us back to the exit node. Your data leaves the TOR network in its raw form. So if you are using an unencrypted protocol, your communication can be read (or modified) by the exit node or anything between the exit node and the destination server. So while your immediate ISP can't really tell who you are sending packets to, someone at an exit node can, and chances are good that that someone is more interested in your communications than the average server on your normal routing path.

This someone might be a government entity, a criminal organization, or maybe just some Swedish security researcher dude who is interested in what's going over his five exit nodes and decides to publish the more interesting tidbits for the world to see.

Just to give you something to think about we did look into a few servers out of 1000 we thought looked interesting. We aren't trying to tell you what to think, you will have to do that yourself.
Example of Exit-nodes that can read your traffic:

• Nodes named devilhacker, hackershaven...
• Node hosted by an illegal hacker-group
• Major nodes hosted anonymously dedicated to ToR by the same person/organization in Washington DC. Each handling 5-10TB data every month.
• Node hosted by Space Research Institute/Cosmonauts Training Center controlled by Russian Government
• Nodes hosted on several Government controlled academies in the US, Russia and around Asia.
• Nodes hosted by criminal identity stealers
• Node hosted by Ministry of Education Taiwan (China)
• Node hosted by major stock exchange company and Fortune 500 financial company
• Nodes hosted anonymously on dedicated servers for ToR costing the owner US$100-500 every month
• Node hosted by China Government official
• Nodes in over 50 countries with unknown owners
• Nodes handling over 10TB data every month

We can prove all this but not the intentions of each server. They might be very nice people spending a lot of money doing you a favor but it could just as well be something else. We don't however think it's weird that Universities are hosting nodes, just that you need to be aware of it. Criminals, hackers and Governments are running nodes, why?

The moral of the story is that you shouldn't use TOR for the purposes of secure communications. You should be using TOR to anonymize routing. If you are passing indentifiable information over the wire that you don't want read, such as your email or bank information, you need to use a secure end-to-end encrypted channel, like ssh, https, or ssl-imap. What TOR provides is a mechanism for anonymizing the routing of your communications so that people in your routing path don't know who you're sending a message to.

Moral #2 is that information you send through the TOR network is more than likely under higher scrutiny by many interested parties. Encryption matters here more than anywhere else.

How 100 sensitive accounts were compromized - Link
Anonymity and the Tor Network (Schneier) - Link

October 31, 2007

Decrypting GSM

Check out this video from last August's CCC Camp, which describes using a Universal Software Radio Perhiperal (USRP) to record GSM messages, and then using an FPGA to defeat the A5/1 encryption that's used to secure an encrypted GSM channel in the span of a couple weeks. By spending a couple months to precompute a 5 TB lookup table you could bring the decryption process down to just a few minutes.

First half of the talk is an introduction into GSM interception. Second half presents a new method for cracking the GSM encryption A5/1. This is a new attack that can crack any encrypted channel (SMS, Voice) within 3-5 minutes regardless of how long the conversation is (e.g. can crack a telephone conversation that only lasts 4 seconds).

Now, most of us won't be running out right now to grab an FPGA and a software radio so we can start cracking GSM voice converstations and SMS messages, but the actual discussion of how GSM works and how the team went about putting together a real-time cracking method for A5/1 is fascinating. What's really crazy is that for a few thousand dollars, anyone could really set up a GSM recording and cracking system. This isn't just NSA or government-funded spy stuff.

At about the 19 minute mark, Steve talks a little about how mobile identification and position information is transmitted. If you've ever called the phone company to track down a stolen phone, you've probably been told this isn't possible. Turns out that if you've had a phone lost or stolen, it actually transmits its position information _all_the_time_. So, technically, your network operator should be able to tell you the phone's location to within 200 meters.

The A5 Cracking Project - [via] Link
GNU Radio - Link

September 17, 2007

Make new iPods work with Linux

With the new Nano, iPod Classic and iPod Touch devices, Apple altered the iTunes database slightly to include a cryptographic checksum, which immediately broke all third party iPod management software. Since there's no iTunes for Linux, this essentially meant that Linux users had to look for another solution for putting music on their devices. Great software like gtkpod and Amarok no longer worked.

This was a few days ago, and it looks like the hash used by iTunes has already been reverse engineered. Every time the database is updated--whether you change the name of a song file, or add or remove music--a new checksum needs to be calculated, based on the contents of the library and your device's unique ID.

Right now, you can continue to use your current software, and then generate and update the checksum in the database manually. No doubt that within another three days all of the nitty gritty details will be automated for you in your favorite open source iPod software.

Ian Monroe, makes this valid point, however:

Really the only "correct" solution is for folks to stop using Apple products. The iPod might have its own version of DAAP's iTunes 7 which has a checksum more difficult (apparently) to crack. But for the time being, things are fine.

Fifteen years ago, a lot of us started making the switch to Linux from Windows, even though the platform was a little foreign, took some work to learn, and was a bit crusty around the edges. The real catalyst was that Linux had a hell of a lot more to offer in terms of networking capabilities, a programmer-oriented free development environment out of the box, and a level of performance and stability that the Microsoft operating systems couldn't touch.

I'm not sure what the final motivating factor will be for people to switch to an open hardware/software platform for their mobile connectivity and media devices. The ability to use it with your preferred desktop OS--not to mention the ability to share your data between multiple devices and multiple desktop clients--is enough reason for me.

Making New iPods work in Linux - Link

September 13, 2007

How a quantum computer can factor a large number

An article today in New Scientist discusses two quantum computers, independantly built by two different research teams, that are capable of running Shor's quantum factorization algorithm. The current machines are only large enough to factor a small number--in this case, the number 15--but assuming the engineering challenges can be overcome and a larger quantum computer with more qubits is created, the quick factoring of large numbers (like those used in RSA public key cryptography) will be possible using the same algorithm.

Scott Aaronson wrote a most excellent essay titled "Shore, I'll Do It" that explains, in man on the street terms, how Shor's algorithm and the quantum Fourier transform works.

Look: if you think about quantum computing in terms of "parallel universes" (and whether you do or don't is up to you), there's no feasible way to detect a single universe that's different from all the rest. Such a lone voice in the wilderness would be drowned out by the vast number of suburb-dwelling, Dockers-wearing conformist universes. What one can hope to detect, however, is a joint property of all the parallel universes together -- a property that can only be revealed by a computation to which all the universes contribute.

If you've ever wondered how a quantum computer actually accomplishes work, have a read.

Shor, I'll do it - Link
Quantum threat to our secret data - [via] Link

September 2, 2007

NSA@home - distributed FPGA MD5 cracker

Here's an innovative use of recycled HD-video electronics:

NSA@home is a fast FPGA-based SHA-1 and MD5 bruteforce cracker. It is capable of searching the full 8-character keyspace (from a 64-character set) in about a day in the current configuration for 800 hashes concurrently.
The cracker is built out of surplus Grass Valley HD video transform boards, scrapped by GV because of defects. A useful tool was developed to assist the board reverse-engineering effort.

The author, Stanislaw Skowronek, will be providing a web interface in the near future, that will allow a few submissions to be cracked online.

It's pretty cool to think that brute force attacks have become computationally feasible and cheaply available for today's most commonly used cyptographic hash algorithms. It's 2^96 times harder to brute-force SHA-256, but who knows what tomorrow's defective consumer electronics will be packing.

NSA@home - Link

August 4, 2007

Cryptographic key recovery from Linux memory dumps

I stumbled across this paper from the 2007 Chaos Communication Camp which describes a method for extracting the cryptographic keys used by either dm-crypt or cryptoloop.

Technically, the cryptographic keys need to reside in memory while your encrypted disk is in use, so, obviously, if an attacker has access to your physical RAM, they will be able to obtain these keys and decrypt the volume at any future point in time. There were a couple of less-than-obvious takeaways, however.

The first is that there are a multitude of avenues for accessing a machine's memory. Anyone able to obtain root access could access /dev/mem remotely, but many systems (especially laptops) will actually write the memory's contents to disk during extended hibernation. Virtualization software, such as VMWare, will do exactly the same when the virtual machine is suspended. Finally (and this was news to me), the Firewire standard provides devices DMA access. You could imagine a device specifically designed for the purpose of connecting to a running machine. It would copy the machine's ram to a small hard disk, a "finished" LED would light up, and the attacker would pocket it and exit the building. The operating system wouldn't even know that anything had happened.

The second big takeaway is that it's relatively simple to search for these keys in a full memory dump. The method is slightly different for dm-crypt than it is for cryptoloop, but it basically involves a pattern search for certain characteristics in the C data scructure that holds the key. There are a couple of scripts included in the appendix for those of you who'd like to try this out.

If you use disk encryption on a laptop to protect your data from theft while you are traveling, take note. Disable hibernation mode to prevent RAM from being written to disk and do not leave your machine running while unattended, even if logged out.

Cryptographic key recovery from Linux memory dumps - Link (pdf)

June 22, 2007

HOWTO: disk encryption in Linux

It's pretty easy to make encrypted disk images and partitions in Linux using the loop-aes-utils (cryptoloop kernel module). This can really come in handy for backing up or storing sensitive content such as your email archive or tax records.

Read full story

June 12, 2007

Surf privately and anonymously with JanusVM

JanusVM is an open source VMware image that combines Ubuntu, Tor, dns-proxy-tor, Squid, Privoxy, and openvpn all into a convenient little package. Just load up the appliance in VMware and make a VPN connection to the virtual machine's IP. Once you've connected, all of your traffic (including DNS) will be localy encrypted and anonymized over Tor. This is incredibly useful for you road warriors and coffee shop surfers who don't trust the security of a public wifi network.

For windows machines, setup is incredibly easy. The JanusVM server has a network share with a .bat file on it that will automatically configure your VPN for you. Linux users have to set up the VPN connection manually but it's a fairly simple process. I've been trying to get this to work under the new VMware OS X client, but for some reason the network completely conks out as soon as I activate the VPN. If you get this working, let me know. I'll keep monkeying with it myself and let you know what I come up with.

JanusVM network security appliance for VMware - [via] Link

June 5, 2007

Use GPG encryption with Firefox and GMail

FireGPG is an awesome little plugin that adds GPG support to Firefox. You need the GPG package installed on your machine to start, and after activating the plugin, you'll have a new right-click menu that will let you sign, encrypt, decrypt and verify any selected text.

You can use this to add strong crypto functionaliy to any webmail system or forum that you use! Special support for GMail is already built-in, which provides encryption and signature buttons right alongside the normal send button.

Currently, there isn't a lot of documentation, but the author has set up a Wiki. If you want to help out, try the software for a while and pitch in with a page or two on the maual.

FireGPG: Use GPG Easily in Firefox - [via] Link

GPG (GNU Privacy Guard) for Linux, Mac, and Windows - Link

May 24, 2007

reCAPTCHA: distributed book digitization while fighting spam

Thanks to spammers, we now are forced waste a substantial portion of time every day, typing in obfuscated wiggly letters to prove we are human. reCATPCHA is a slick idea for using the CAPTCHA system for doing something productive (...besides distinguising between homo sapien and homo computatralis).

With reCAPTCHA, the user is given two words, one known by the system and one from a book that previously failed character recognition. When the user enters both words, the sytem verifies the known word, proving human-ness, and submits the second word to a central database, which helps digitze books from the Internet Archive. With 60 million CAPTCHAs being solved every day, this could be a huge assist for portions of text that can't be handled by optical character regognition techniques. [via] Link

Related:
Negative CAPTCHA

May 2, 2007

HOW TO: Remote desktop to a Windows server through a firewall with Putty

Here's a common scenario: you need to make an emergency remote desktop connection to an XP server at work, but you're at home and the server is behind a firewall that blocks RDC connections.

In a nutshell, ssh tunneling allows you to connect to a port on another machine by forwarding traffic through an intermediary ssh server. Using an ssh tunnel, if you have access to an ssh server behind the firewall, you can connect to services on other machines behind the firewall, including remote desktop services.

Using Putty (a rockstar ssh client for Windows), you can easily set up a tunnel for accessing RDC on your firewalled server:

Configure a new ssh session for the ssh server that you have access to (66.35.250.203 in this example).
In the connection/ssh/tunnels menu, add a new forwarded port. You'll need to set up a port on your own machine (this will be the virtual, forwarded connection to the remote RDC server), so use something unused, like 3390.
In the destination field, enter the ip address and RDC port for the firewalled machine, Ie. 192.168.0.5:3389 (3389 is what RDC listens on)
Now save your session and connect to the SSH server

At this point, you can connect to the remote server's RDC port via your own machine's port 3390. Everything that comes in and out of localhost:3390 will be transparently whisked away over the ssh connection, through the intermediary machine, to your destination server's port 3389. So instead of entering 192.168.0.5:3389 for your destination server in the remote desktop client, enter localhost:3390. It will go right through the firewall.

Breaking Firewalls with OpenSSH and PuTTY (read this)- Link.
Putty SSH Client for Windows - Link.

April 27, 2007

Zfone: Zimmermann's VoIP encryption software

Zfone is a VoIP encryption package developed by Phil Zimmermann, the author of PGP. There's a software utility for Linux, Mac and Windows that automatically detects VoIP calls, negotiates a secure connection, and then filters all call traffic. So now you can have a secure iChat A/V call and protect against packet snoopers and man-in-the-middle attacks!

There's also a library and source available for the ZRTP protocol so that people can audit the code and embed the technology in VoIP hardware devices. Currently Zimmermann hasn't released things under a free software license, but once it comes out of beta he's planning of dual licensing everything, similar to MySQLs GPL/commercial licensing scheme. Who wants to bet that there will be an open-source, open-hardware device platform for this before there's a commercial product on the shelves? Too cool.

The Zfone Project -Link.
Zfone download and install instructions -Link.

March 18, 2007

HOW TO Create an Encrypted Disk Image in OS X

There's a feature built into OS X that will allow you to create AES-128 encrypted disk images. You can use this to create mountable, encrypted virtual drives, or even burn password protected CDs. Here's how:

Open Disk Utility in the Applications/Utilties folder.
Click "New Image".
In the "Encryption" pull-down menu, select AES-128
If you want to make a CD, make sure the size is small enough to fit on a CD, typically 610MB.
Enter the name and location of the image file and click Create to finish.
You will be asked to enter a password for the new image. Pick a good one.

Disk Utility will create a .dmg file in the location you specified and it will automatically be mounted and appear as a new drive with the size you specified earlier. You can drag files to this drive and they will be added to the encrypted image. When you are finished, just eject the drive by clicking the eject icon next to the drive in the Finder. Once the drive is unmounted/ejected, anyone attempting to mount the image will be required to enter the password you specified.

If you want to make a password protected CD, just insert a blank, recordable CD (or DVD) and drag the .dmg file to it in the Finder. Just like the dmg image, the CD will require a password to be entered before it will mount.

March 3, 2007

Howto: Recover Text From Blurred Images

Every once in a while, you'll come across an image or video where sensitive information has been redacted using a blur or mosaic filter. Just take a look at license plates on COPS or do a search for "google check" and you'll see a few common examples.

Putting an image through a blur filter is the visual analogue of a one way hash. While it's difficult to read, it's still subject to a dictionary attack, and when the subject consists of a 10 digit routing number or a 6 digit license plate, well, the dictionary is very small. Simply identify the filter mechanism used, filter/hash all of the possibile values, and find the resulting hash that measures closest to the source image.

The solution is simple: Don't blur your images! Instead, just color over them. Remember, you want to leave your visitors with NO information, not blurred information.

Why blurring sensitive information is a bad idea - [via] Link.

Page 2 of 2 << 1 2