NIST is holding a competition to replace the SHA family of hash functions, which have been increasingly under attack. (I wrote about an early NIST hash workshop here.)

Skein is our submission (myself and seven others: Niels Ferguson, Stefan Lucks, Doug Whiting, Mihir Bellare, Tadayoshi Kohno, Jon Callas, and Jesse Walker).

...

The selection process will take around four years. I've previously called this sort of thing a cryptographic demolition derby -- last one left standing wins -- but that's only half true. Certainly all the groups will spend the next couple of years trying to cryptanalyze each other, but in the end there will be a bunch of unbroken algorithms; NIST will select one based on performance and features.

The Skein hash function is based on a the Threefish block cipher, which is also released as part of the submission. Source has been released to the public domain, which you can download from the Skein website.

Schneier on Security: The Skein Hash Function
Skein Submission Paper - Design, Usage, and Preliminary Cryptanalysis (PDF)
The Skein Hash Function Family Website

Hobos have a code system for communicating warnings and identifying good places to camp. Warchalkers have their own code for marking open access points.

Now kids can have a secret ideogram language for finding the best loot:

Growing up in the Bowling Green neighborhood of Sacramento, I was taught how to read and mark houses with the Halloween Candy Code. For kids with an early curfew these codes were invaluable. Once we tagged a house, our peers could use our marks to reap the best full-size chocolate bars while avoiding Chex mix and dried apricots.

Most marks were left in bright chalk at the bottom of the driveway.

Shown above are the symbols for king size candy bars, fun size bars, open porch bowl, and Reese's Pieces. Though I'm pretty sure it's a joke—and I dare drop my first public ROFL in the middle of this blog entry, as that's what I've been doing for a few minutes—it also strikes me that this is a sound idea and should immediately be taught to kids everywhere.

Halloween Candy Code
Cabel Sasser's inspired tweet on the topic of a kids' hobo code

Thomas Robinson was experimenting with a way to recover censored text from documents that use the Photoshop "mosaic" filter to redact text. One way to brute force a solution to a redacted message is to run the mosaic filter with a number of input letters, looking for visual matches that progressively uncover the censored text.

Manually performing this trial and error approach would take quite a bit of time, but Thomas was able to automate this by writing a Javascript program that interfaces directly with Photoshop CS3 and performs the necessary filters and test operations to uncover the secret message. This is cool on a number of levels, not only for the particulars of the example, but also for the fact that you can now script Photoshop in plain old Javascript.

There are so many cool things you could do with an easy scripting interface to Photoshop. Check the video above to see this particular application in action, or follow the links below for the full discussion and example code for writing the Javascript code to make something like this work.

Recovering Censored Text Using Photoshop and JavaScript
Photoshop Redaction Recovery Sample Code

When I read the article on Slashdot, the "all name servers should be patched as soon as possible" quote dropped a bit of scare on me too. What about my sad little DNS server? I envisioned spending an evening working through a time consuming process of patching and reconfiguring things that I haven't had to touch in years. Much to my pleasant surprise, djbdns, D. J. Bernstein's DNS server, was not vulnerable. My decision to use djbdns a number of years ago was primarily due to his vocal philosophy of engineering security by design instead of by response.

Bruce Schneier's analysis of things is spot on as usual. It's a solid case study for hygienic software engineering practices and the design of secure systems.

The real lesson is that the patch treadmill doesn't work, and it hasn't for years. This cycle of finding security holes and rushing to patch them before the bad guys exploit those vulnerabilities is expensive, inefficient and incomplete. We need to design security into our systems right from the beginning. We need assurance. We need security engineers involved in system design. This process won't prevent every vulnerability, but it's much more secure -- and cheaper -- than the patch treadmill we're all on now.

What a security engineer brings to the problem is a particular mindset. He thinks about systems from a security perspective. It's not that he discovers all possible attacks before the bad guys do; it's more that he anticipates potential types of attacks, and defends against them even if he doesn't know their details. I see this all the time in good cryptographic designs. It's over-engineering based on intuition, but if the security engineer has good intuition, it generally works.

Kaminsky's vulnerability is a perfect example of this. Years ago, cryptographer Daniel J. Bernstein looked at DNS security and decided that Source Port Randomization was a smart design choice. That's exactly the work-around being rolled out now following Kaminsky's discovery. Bernstein didn't discover Kaminsky's attack; instead, he saw a general class of attacks and realized that this enhancement could protect against them. Consequently, the DNS program he wrote in 2000, djbdns, doesn't need to be patched; it's already immune to Kaminsky's attack.

The djbdns server wasn't pre-installed on the Linux distro I based my poor old server on. DJB's deamontools package, which manages the startup and shutdown of the service, was annoying to deal with when every other application just uses a normal init rc script. The dns server configuration and setup was also unfamiliar to me, having previously only worked with BIND zone files.

There's one other thing that has really been different with djbdns than any other DNS server I've ever administered: I've never had to patch it. I've only had one other software experience like this, with the qmail mail transfer system. Qmail is also designed by Bernstein. Hmm.

If you're upgrading your DNS server anyway, maybe now is the time to start thinking about your alternatives.

Daniel J. Bernstein's djbdns server
Schneier - The DNS Vulnerability
DJB on DNS forgery
Slashdot - Kaminsky's DNS Attack Disclosed, Then Pulled

Dan Guido from the Information Systems and Internet Security Lab at the Polytechnic Institute of NYU wrote in about the Institute's 5th annual Cyber Security Awareness Week. If you're in high-school or a college undergraduate program, this is a great opportunity to test your infosec skills against your peers, and hopefully earn a little prize money in the process.

ISIS Lab is organizing NYU-Poly's 5th annual Cyber Security Awareness Week (CSAW) where students can compete and win prizes in a variety of information security challenges. There will be door prizes, raffles for participating, and bonus prizes for undergrad and high school participants. Qualified finalists will receive a travel scholarship to attend the awards ceremony in New York City.

There are a number of events, including an application security "capture the flag" challenge, a security quiz which covers everything from cryptography to risk management, and a 5-day forensics puzzle. There's even an embedded systems challenge where teams are tasked with trying to find hardware and software bugs in a mock control system.

This looks like a lot of fun. Some of the contest materials become available at the beginning of September, so sign up soon if you're interested in participating.

Cyber Security Awareness Week 2008

The interesting thing is that a file can have 0 to many ADS forks attached to any file or directory. While some of the ADS identifiers are use by the OS, there's nothing stopping you from adding other ADS forks to a file. You can do this directly from the command line, using a simple colon ":" notation.

Let's say you have a file called test.txt. You can store a secret message in the file like this:
echo "This is a secret" > test.txt:secretdata

If you view the contents of the file, you won't see anything peculiar. If you know about the existence of the secretdata ADS entry, however, you can easily extract the hidden information with the following command:
more < test.txt:secretdata > output.txt

When you now open output.txt, you'll find your secret data inside.

Because it's a lower level OS feature, you can even trick most programs into loading the data. In the scenario above, you could actually load and edit the secretdata stream inside of notepad by running "notepad test.txt:secretdata".You can even store and execute binary data of any particular size in an ADS fork. For instance, maybe you want to shove solitaire inside one of your text file's ADS entries:

type c:\winnt\system32\sol.exe > test.txt:timewaster.exe

Running the file is as simple as "start .\test.txt:timewaster.exe". Wild, no?

So the odd thing is that all these hidden streams are floating about your filesystem and until Vista's /R flag on the DIR command, there hasn't really been a very good built-in way of detecting them. To solve this, Frank Heyne created an application called LADS which is an excellent command line utility that will scan a directory and print out stream names and sizes for files within it.

There's was also a tool released in an MSDN article about file streams that will at an extra tab to the file properties in Windows Explorer. I've linked to a FAQ that Frank maintains about ADS that walks you through setting up the dll and registry entries to make this work. When it's activated, the Streams tab in the properties panel will let you create, view, edit or delete the stream data that's attached to any file, right in Explorer.

I can see how this file system feature could be useful, but it's a little odd that it's so hidden from the user and there seem to be a few problems with the concept. Obviously, because of ADS's hidden nature, there are a number of malicious uses that can be employed by jerk-o's who write virii and that sort of thing. Even ignoring that, there are also data interchange issues—moving a file between NTFS and another file system causes the loss of all this attached information. Call me old fashioned, but I like my files the way they used to be, with a start, an end, and some bytes in between.

Frank Heyne - Alternate Data Streams in NTFS FAQ
LADS - NTFS alternate data stream list utility
The Dark Side of NTFS
MSDN: A Programmer's Perspective on NTFS Streams and Hard Links

ShmooCon is an annual East coast hacker convention hell-bent on offering three days of an interesting atmosphere for demonstrating technology exploitation, inventive software & hardware solutions, and open discussions of critical infosec issues.

It's a while until the next conference comes up, but there have been some great presentations at past conferences, most of which are available online. Peteris Krumins recently assembled links to all of the videos and presentation files that are available at the Shmoocon site (including the 2008 conference), posting them to his blog as a single big index.

A quick search on YouTube also turned up a series of videos by Scott Moulton from Shmoocon 2007 and 2008 on the topic of data recovery for both traditional hard disks and flash drives. It's pretty fascinating stuff, whether you're interested in this from a forensics or security perspective, or if you've ever just wondered what exactly goes into recovering important data from a crashed disk when you send it out to a data recovery shop.

Hacking Videos from Shmoocon
Scott Moulton's videos on data recovery for SSD flash drives and hard disks
Shmoocon Infosec Conference

See also: Videos from past DEFCONs

A large majority of Debian and Ubuntu systems are affected. To correct the problem, you'll need to not only update OpenSSL, but also revoke and replace any cryptographic keys and certificates that were generated on the affected systems. From the Debian security advisory:

Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key material for use in X.509 certificates and session keys used in SSL/TLS connections. Keys generated with GnuPG or GNUTLS are not affected, though.

For most people, this boils down to your ssh server's host key and any public key pairs used for remote ssh authentication. Any keys or certificates generated on the affected machines for SSL/https use also need to be revoked and regenerated. It's pretty ugly, really.

As far as teachable moments go, there's probably a lot to think about here. Software developers have this weird natural tendency to want to fix and reengineer things that aren't even broken. I'd go so far as to say that the desire to reengineer is inversely proportional to a programmer's familiarity and understanding of the code. I think it comes from our intense desire to make sense of things. It's the guru who's able to channel that hacker urge into solving new problems instead of creating new bugs out of old solutions.

DSA-1571-1 openssl -- predictable random number generator
OpenSSL PRNG Debian Toys (more discussion of the problem here)

The more recent content is encoded as mp4's. Unfortunately, you'll need Real Player to view much of the older content. It's better than nothing, though.

It also looks like there have been a number of sessions from DEFCON 15 encoded and uploaded to Google Video. I've included a link to a list of these below as well.

Defcon Media Archives: 1993 - Present
Links to DefCon 15 Session and Panel Videos on Google Video

Nathan Harrington amended the GNOME Desktop Manager to include keystroke dynamics in the user verification process. When the user enters their username, the timings between key press events are measured and compared against a stored pattern. The theory is that there is a significant difference in timings for words typed by different individuals, so the way a username is entered provides a bit of extra "fingerprint" information that can be used to help authenticate a user.

I'm not sure how immediately useful this will be, since this particular example won't affect other login methods, such as an ssh session. Nevertheless, the idea is pretty cool and the code is all there for you to monkey around with.

Identify and verify users based on how they type [via slashdot]

Unlike USB2, the Firewire spec allows devices to have full DMA access. By impersonating the appropriate device, a PC can essentially obtain full read/write access to another machine's RAM, just by connecting the two machines with a Firewire cable. Adding to the recent discussion about the insecurities of physical access and Princeton's cold-boot RAM dump demonstration, Adam Boileau released a Linux Firewire utility that will give you immediate Administrator to an XP machine:

It's two years later, and I think anyone who was going to get the message about Firewire has already got it, and anyone who was going to be upset about it has got over it. Besides, according to Microsoft's definition, it never was a Security Vulnerability anyway - screensavers and login prompts are - as Bruce says - about the Feeling of Security. Anyway, today's release day for Winlockpwn, the tool I demoed at Ruxcon for bypassing windows auth, or popping an admin shell at the login window.

...

• Yes, you can read and write main memory over firewire on windows.
• Yes, this means you can completely own any box who's firewire port you can plug into in seconds.
• Yes, it requires physical access. People with physical access win in lots of ways. Sure, this is fast and easy, but it's just one of many.
• Yes, it's a FEATURE, not a bug. It's the Fire in Firewire. Yes, I know this, Microsoft know this. The OHCI-1394 spec knows this. People with firewire ports generally dont.

Adam's tools include a few Python apps that can copy and impersonate Firewire device signatures, dump RAM on a remote machine, bypass Windows authentication, and extract BIOS passwords. It's not exactly comforting, but I've got a new appreciation for Firewire now. This is the sort of access that used to only be possible by creating hardware that physically connects to the PCI bus. Now all you need is a cable and a laptop.

Firewire, DMA & Windows - direct memory access over Firewire - [via] Link

John Graham-Cumming posted an automated tool for detecting "Clone Tool" Photoshop forgeries. Photojournalism ethics issues (LInk, Link) aside, John had some ulterior motives:

I was motivated to work on this program by greed (or at least my never-ending love of having a little flutter on things). Best of the Best runs spot-the-ball competitions in airports to win very expensive cars. But they also run the same competition online. That meant I could get my hands on the actual image used... could I process it to discover where the ball had been removed? (In reality, this isn't the right way to win because the actual ball position is not governed by where it actually was, but where a judge thinks it was).

Would it be cheating if I could? Apparently not, the competition rules say I should use my skill and judgment in determining the ball position. Surely, skill covers my programming ability.

So, I went looking for tampering algorithms and eventually came across Detection of Copy-Move Forgery in Digital Images written by Jessica Fridrich at SUNY Binghamton. The paper describes an algorithm for detecting just the sort of changes I thought I was looking for.

Essentially the algorithm cuts the image into a bunch of 16x16 chunks and runs each chunk through a discrete cosine transform. The DCTed chunks are compressed and sorted, and the algorithm looks for multiple matching chunks that were shifted the same direction and distance, highlighting the source image if a large number of matches are found.

Another blogger, jjwiseman, released a speed optimization for John's code, which he successfully used on the infamous Adnan Hajj Reuters images. While the algorithm is able to detect this style of manipulation, it's noted that it has a habit of returning false positives in images with a blurry background.

That said, it'd be pretty interesting to run this through a big database of news photos and see what turns up.

Detection of Copy-Move Forgery in Digital Images - Link (PDF)
John Graham-Cumming's Clone Tool Detector - Link
Protecting Journalistic Integrity Algorithmically (jjwiseman's update) - Link

In this video, researchers at Princeton demonstrate the ability to lift encryption keys from RAM that has been powered off for a brief period of time. When you use a full disk encryption product, the key is stored in RAM while the machine is unlocked and operating. This data is typically considered safe as long as it's not paged out to disk since RAM is considered volatile. The truth, though, is that the volatility of the data in unpowered RAM is dependent on a few factors including temperature and the length of time it's been without power:

Contrary to popular assumption, DRAMs used in most modern computers retain their contents for seconds to minutes after power is lost, even at operating temperatures and even if removed from a motherboard. Although DRAMs become less reliable when they are not refreshed, they are not immediately erased, and their contents persist sufficiently for malicious (or forensic) acquisition of usable full-system memory images. We show that this phenomenon limits the ability of an operating system to protect cryptographic key material from an attacker with physical access. We use cold reboots to mount attacks on popular disk encryption systems -- BitLocker, FileVault, dm-crypt, and TrueCrypt -- using no special devices or materials.

By rebooting a laptop off of a USB drive with a small-footprint kernel, an attacker could pretty easily dump the full contents of RAM with little risk of loosing data. Even if the machine's BIOS is configured to disallow booting from external drives, the attacker could use an upside-down can of compressed air to cool the RAM prior to shutdown and then quickly transfer the RAM to a second machine.

Since it's not a trivial task to swap keys, there are other even more sinister attack scenarios. For instance, a key could be swiped when convenient, then used to inspect the disk contents at multiple points in time at a later date. Screw up and leave your computer recently-powered and unattended once, and the drive could be accessed at any point in the future. The machine wouldn't even need to be stolen for this opportunistic approach to be effective, so you might never know that your data's security is compromised.

If you use disk encryption as a last defense for the security of your data, it seems prudent to shut your machine down completely (no hibernating) several minutes prior to it leaving your immediate control.

Lest We Remember: Cold Boot Attacks on Encryption Keys - [via Jay] Link

TrueCrypt 5.0 was released yesterday and OS X has been added to the list of supported operating systems, making it the only open source volume encryption utility that works in Linux, Mac and Windows. It's a really slick utility for creating an AES-256 or Serpent encrypted volume that you can drop sensitive files inside.

You can use TrueCrypt to create an encrypted volume image inside a file, or you can encrypt a whole disk image or partition. The OS X version uses MacFUSE to provide user-mode mounting of the encrypted disk. The main application window, pictured above, gives you a simple interface for creating and mounting encrypted images.

Once an image is mounted, you can use it like a normal hard disk. Unmount the disk and you're left with a file full of random gibberish. FAT is the only filesystem that's available through the interface, but once the disk is mounted, you can reformat it with Disk Utility to use XFS.

There are a couple of things worth noting. In the Windows and Linux versions a special bootloader is available that lets you encrypt your entire system drive. It doesn't look like that option is available in the OS X version. Also, when I tested the latest OS X binary this evening, the "hidden volume" plausible deniability feature wasn't working. Hopefully that will be added in a future release. Until then, TrueCrypt is better suited for storing tax documents and things you wouldn't want visible to a laptop thief, rather than the details of where you've hidden the bodies.

TrueCrypt - [via] Link

A while ago we wrote about removing the DRM from Netflix "Watch Now" movies. At the time, it involved wading through a bit of HTML source to find the target video URL. Since then, a couple of important things have happened: a Greasemonkey script was written that makes it a bit easier to download and process the DRMed WVM file, and more importantly, Netflix is now allowing unlimited downloads.

What can you do with this? Well, you can download a number of videos ahead of time and then watch them at your leisure, especially if you travel a lot and are offline for extended periods of time. It also means you can convert the files to mp4 format for playing on your mac, iPod or Apple TV device. Or maybe you were hoping to finish that documentary you were making about the strange facial expressions of Sylvester Stallone and needed a few more clips to splice into your film...

How To Rip Netflix "Watch Now" Movies - Link
Netflix Downloader Greasemonkey Script - Link

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

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

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

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

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

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

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)

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

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

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

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:

1. Configure a new ssh session for the ssh server that you have access to (66.35.250.203 in this example).
2. 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.
3. 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)
4. 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.

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.

1. Open Disk Utility in the Applications/Utilties folder.
2. Click "New Image".
3. In the "Encryption" pull-down menu, select AES-128
4. If you want to make a CD, make sure the size is small enough to fit on a CD, typically 610MB.
5. Enter the name and location of the image file and click Create to finish.
6. 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.

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.