Carview!

CARVIEW

MOTORHOMES

Select Language

HTTP/2 302 server: nginx date: Mon, 04 Aug 2025 01:13:01 GMT content-type: text/plain; charset=utf-8 content-length: 0 x-archive-redirect-reason: found capture at 20081216002944 location: https://web.archive.org/web/20081216002944/https://www.hackszine.com/blog/archive/cryptography/ server-timing: captures_list;dur=0.479084, exclusion.robots;dur=0.018375, exclusion.robots.policy;dur=0.009339, esindex;dur=0.010226, cdx.remote;dur=64.995503, LoadShardBlock;dur=269.774841, PetaboxLoader3.datanode;dur=51.963177, PetaboxLoader3.resolve;dur=134.995056 x-app-server: wwwb-app217 x-ts: 302 x-tr: 362 server-timing: TR;dur=0,Tw;dur=0,Tc;dur=0 set-cookie: wb-p-SERVER=wwwb-app217; path=/ x-location: All x-rl: 0 x-na: 0 x-page-cache: MISS server-timing: MISS x-nid: DigitalOcean referrer-policy: no-referrer-when-downgrade permissions-policy: interest-cohort=() HTTP/2 200 server: nginx date: Mon, 04 Aug 2025 01:13:02 GMT content-type: text/html x-archive-orig-date: Tue, 16 Dec 2008 00:29:44 GMT x-archive-orig-server: Apache x-archive-orig-last-modified: Fri, 05 Dec 2008 05:50:19 GMT x-archive-orig-etag: "1c58006-18ac1-4938c11b" x-archive-orig-accept-ranges: bytes x-archive-orig-content-length: 101057 x-archive-orig-connection: close x-archive-guessed-content-type: text/html x-archive-guessed-charset: utf-8 memento-datetime: Tue, 16 Dec 2008 00:29:44 GMT link: ; rel="original", ; rel="timemap"; type="application/link-format", ; rel="timegate", ; rel="first memento"; datetime="Wed, 02 May 2007 03:02:05 GMT", ; rel="prev memento"; datetime="Sat, 11 Oct 2008 03:57:58 GMT", ; rel="memento"; datetime="Tue, 16 Dec 2008 00:29:44 GMT", ; rel="next memento"; datetime="Tue, 03 Feb 2009 09:19:34 GMT", ; rel="last memento"; datetime="Tue, 09 Mar 2021 16:36:37 GMT" content-security-policy: default-src 'self' 'unsafe-eval' 'unsafe-inline' data: blob: archive.org web.archive.org web-static.archive.org wayback-api.archive.org athena.archive.org analytics.archive.org pragma.archivelab.org wwwb-events.archive.org x-archive-src: 52_7_20081215162658_crawl108-c/52_7_20081216002942_crawl100.arc.gz server-timing: captures_list;dur=0.547146, exclusion.robots;dur=0.018591, exclusion.robots.policy;dur=0.010289, esindex;dur=0.010565, cdx.remote;dur=21.454895, LoadShardBlock;dur=369.481919, PetaboxLoader3.datanode;dur=300.648222, PetaboxLoader3.resolve;dur=297.871180, load_resource;dur=323.462399 x-app-server: wwwb-app217 x-ts: 200 x-tr: 860 server-timing: TR;dur=0,Tw;dur=0,Tc;dur=0 x-location: All x-rl: 0 x-na: 0 x-page-cache: MISS server-timing: MISS x-nid: DigitalOcean referrer-policy: no-referrer-when-downgrade permissions-policy: interest-cohort=() content-encoding: gzip Hackszine.com: Cryptography Archives

Archive: Cryptography

Page 1 of 2 1 2 >>

October 31, 2008

The Skein hash function and Threefish block cipher

The National Institute of Standards and Technology is holding a competition to design a new hash function to replace the current SHA family of functions and become SHA-3. The deadline for submissions was today, and the submissions will be evaluated over the coming years until a final proposed standard is made in 2012. Bruce Schneier posted some information about his team's entry, Skein, and the whole selection process:

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

October 30, 2008

Halloween candy code

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

October 21, 2008

Scripting Photoshop with Javascript - anti-redaction example

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

July 29, 2008

DJBDNS, DNS exploits, Bernstein, Schneier, and security by design

If you haven't been living under a rock, you've probably heard of the DNS vulnerability that Dan Kaminsky announced about a half year ago. The plan was that Kaminsky would be working with DNS server vendors to provide a patch, giving ample time for administrators to upgrade before the details of the exploit were released later this year. Unfortunately the exploit was leaked prematurely, causing a general freak-out mode amongst people that administer DNS systems.

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

July 27, 2008

Cyber Security Awareness Week

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

July 23, 2008

NTFS Alternate Data Streams - hide files inside other files

The NTFS file system has support for additional data, called Alternate Data Streams (ADS), to be attached to any file. Normally this is used by the operating system and file explorer to bind extra data to a file, such as the file's access control information, searchable file meta-data like keywords, comments and revision history, and even information that can mark a file as having been downloaded from the internet. Because this extra information is bound to the file at the filesystem level, you can move the file from one folder to another and all of the various meta-information and permission data stays with the file.

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

June 24, 2008

Videos from past Shmoocons

You may have dug the videos of past DEFCON conferences that we posted back in May, but there's a whole other infosec conference, Shmoocon, which is held in D.C. every February.

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

Debian/Ubuntu users: update your SSL keys and certs

It was announced yesterday that sometime back in September 2006 a line of code was removed from the Debian distributed OpenSSL package. That one line of code was responsible for causing an uninitialized data warning in Valgrind. It also seeded the random number generator used by OpenSSL. Without it, the error went away, but the keyspace used by affected systems went from 2^1024 to about 2^15. Oh noes!

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)

May 4, 2008

Videos from past DEFCONs

I wasn't able to make it to last years DEFCON hacker/security conference, and DEFCON 16 isn't until later this summer. As you can imagine, I've been a little impatient for a good ol' info-security paranoia fix. Thankfully, it looks like a ton of videos from past conferences have been posted to the DEFCON site. This might be pretty interesting to even the die-hards in the crowd who religiously attend. Having been to a couple of these, it's pretty hard (read: impossible) to get into all the sessions you would like to hit.

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

April 4, 2008

Add keystroke user verification to Gnome

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]

March 4, 2008

Ram dump over Firewire

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

February 28, 2008

Detecting forged photos algorithmically

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

February 22, 2008

Extracting encryption keys after a cold boot

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

February 6, 2008

TrueCrypt for OS X

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

January 15, 2008

Unlimited ripping of Netflix "Watch Now" movies

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