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

Executive Summary

Skein is a new family of cryptographic hash functions. Its design combines speed, security, simplicity, and a great deal of flexibility in a modular package that is easy to analyze.

Skein is fast. Skein-512 -- our primary proposal -- hashes data at 6.1 clock cycles per byte on a 64-bit CPU. This means that on a 3.1 GHz x64 Core 2 Duo CPU, Skein hashes data at 500 MBytes/second per core -- almost twice as fast as SHA-512 and three times faster than SHA-256. An optional hash-tree mode speeds up parallelizable implementations even more. Skein is fast for short messages, too; Skein-512 hashes short messages in about 1000 clock cycles.

Skein is secure. Its conservative design is based on the Threefish block cipher. Our current best attack on Threefish-512 is on 25 of 72 rounds, for a safety factor of 2.9. For comparison, at a similar stage in the standardization process, the AES encryption algorithm had an attack on 6 of 10 rounds, for a safety factor of only 1.7. Additionally, Skein has a number of provably secure properties, greatly increasing confidence in the algorithm.

Skein is simple. Using only three primitive operations, the Skein compression function can be easily understood and remembered. The rest of the algorithm is a straightforward iteration of this function.

Skein is flexible. Skein is defined for three different internal state sizes -- 256 bits, 512 bits, and 1024 bits -- and any output size. This allows Skein to be a drop-in replacement for the entire SHA family of hash functions. A completely optional and extendable argument system makes Skein an efficient tool to use for a very large number of functions: a PRNG, a stream cipher, a key derivation function, authentication without the overhead of HMAC, and a personalization capability. All these features can be implemented with very low overhead. Together with the Threefish large-block cipher at Skein core, this design provides a full set of symmetric cryptographic primitives suitable for most modern applications.

Skein is efficient on a variety of platforms, both hardware and software. Skein-512 can be implemented in about 200 bytes of state. Small devices, such as 8-bit smart cards, can implement Skein-256 using about 100 bytes of memory. Larger devices can implement the larger versions of Skein to achieve faster speeds.

Skein was designed by a team of highly experienced cryptographic experts from academia and industry, with expertise in cryptography, security analysis, software, chip design, and implementation of real-world cryptographic systems. This breadth of knowledge allowed them to create a balanced design that works well in all environments.

Here's source code, text vectors, and the like for Skein. Watch the Skein website for any updates -- new code, new results, new implementations, the proofs.

NIST's deadline is Friday. It seems as if everyone -- including many amateurs -- is working on a hash function, and I predict that NIST will receive at least 80 submissions. (Compare this to the 21 submissions NIST received -- five were rejected as not being complete -- for the AES competition in 1998.) I expect people to start posting their submissions over the weekend. (Ron Rivest already presented MD6 at Crypto in August.) Probably the best place to watch for new hash functions is here; I'll try to keep a listing of the submissions myself.

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.

NIST has stated that the goal of this process is not to choose the best standard but to choose a good standard. I think that's smart of them; in this process, "best" is the enemy of "good." My advice is this: immediately sort them based on performance and features. Ask the cryptographic community to focus its attention on the top dozen, rather than spread its attention across all 80 -- although I also expect that most of the amateur submissions will be rejected by NIST for not being "complete and proper." Otherwise, people will break the easy ones and the better ones will go unanalyzed.

"consumers hate tokens."

"Everyone wants to be the single federation platform for everyone else."

"Federation will never work. It won’t work because the single most important consumer Web applications in the world are scared of it. Banks hate the concept because it becomes a weakest link in the chain problem."

"Tokens don’t actually solve most security problems, like man-in-the-middle, phishing, and keystroke-logging malware."

"Oh yes, and finally, consumers are going to have to carry around 13 of them just to make sure they can log into whatever they need to log into since no one will federate."

"Global federation is nowhere near a solid concept in the consumer space, despite what the vendors will try to sell you."

"This is a long term problem. If you work on it and make any progress against it, you'll find yourself much smarter at the far end, than you were at the near end.

When I was in Norway about 5 years ago, I was there very close to the summer solstice. I was wandering around town at 2 o'clock in the morning and there was plenty of light out. You come to a sign that says New Minsk about 60 km and it points south.

And I ask the lady "what country is this?"

She scratched her head for a bit, and said "well I think its Norway"

I said "well who plows the roads?"

"well Norway does, but he have to pay them."

There is a triple boundary in this town that I was in between Norway, Finland and Russia.

But what I did there, was, I had a card about wallet size, I stuck it into a machine, I punched in four digits, and it gave me about 2,000 krone, whatever the hell that is.

Now there are a lot of participants in that transaction. When I put a card into that machine, punch in a pin, and it gurgles for awhile, and finally gives me, a fairly large amount of money. There are a lot of participants in that transaction. The bank that owned the machine that gave me the money, it gave some money away -- that bank wants it back. The pin is necessary to convince my own bank that I'm me. But I don't want my pin to be broadcast all over the world. My bank in the us, it hasn't really given out or taken in any money, really. But there is a lot of credits involved here. Somebody needs to charge somebody else for having more money available. Even though there was actually no cash transfer.

And the problem that I have in mind is
- who are all the participants in an ATM transaction?
- what do those participants need to satisfy their problems?
- how is that in fact done?

In a general way, does the atm system actually work in some reasonable sense? To which the answer is by the way: yes. The atm system damn well works. With extremely high reliability and accuracy. It surprises me. Its quite a bit different than voting machines.

LAS VEGAS -- Last weekend, more than 9,000 hackers, freaks, feds and geeks gathered for the 16th annual DefCon, the world's largest computer security convention.

Wired.com brought you live coverage of the most newsworthy events at DefCon 16. Here are some photos from the lighter side of the conference.

Left: South Korean hackers compete in the Capture the Flag competition. The goal is to hack into and keep control of targeted servers.

Mr. Sinister and Dragon Cracker battle it out in a round of Guitar Hero -- one of DefCon's newest competitions.

Bringing-your-own-booze supply ensures optimal buzz at DefCon. Shortly after this picture was taken, hotel security escorted this backpack-hacker to his room.

Computer geeks from the National Institute of Standards and Technology set up a network secured with quantum encryption in a conference room at DefCon. The quantum-entangled photons are being used to encrypt a video stream across a line-of-site network.

A compact optical bench and an atomic clock (left) are used to secure a network with quantum encryption.

In the Lock Pick Pavilion, DefCon attendees Dustin, Jennalynn and Kunfoozball practice their lock-picking skills.

DefCon founder and organizer Jeff Moss, aka Dark Tangent, at the conference's closing ceremony Sunday.

A collection of black badges awaits the winners of the various competitions. These badges give their holders lifetime entry to DefCon.

One of DefCon's logos, the smiley-faced skull and crossbones, is welded inside a yellow sphere. The sphere is the primary stage of one of the most difficult competitions at DefCon: The Mystery Challenge.

Unbeknownst to attendees, this laptop is sniffing RFID tags and taking photos of their owners when they pass in front of the detectors. RFID tags are used in everything from building access to some credit cards.

At the closing ceremony, DefCon organizers turn off the lights while the attendees wave their high-tech badges back and forth.

From the Last Hope:

For Immediate Release

THE LAST HOPE TO FEATURE HACKER RADIO

At The Last HOPE conference, hackers will broadcast their minds and their iPods.

In the center of the summer’s top hacker event will be a small isolation booth. “Radio Statler!” as the station is called, will send out a three day broadcast of all-original material. From the center of Manhattan, around the clock, discussions of the past, present, and future of technology, creativity, and humanity itself will be transmitted.

The first night of the conference, July 18th, the station will carry a program called Digital Music Night, hosted by Peter Kirn, editor of createdigitalmusic.com. The three hour live concert will feature a convergence of artists and musicians using custom, original tools for performing live in new and bizarre ways, including:

* Houseplants hooked up to live computer visuals and music
* A mutant trumpet, halfway between the digital and acoustic worlds
* Packets of data visualized as three-dimensional eye candy
* An animated digital art sketchpad controlled by Wii remote
* A set of digital gloves for gestural DJing
* A robotic drummer
* Computer-generated vocals that sing your spam folder to you
* Live digital art made from vintage game consoles and computers

The station will give additional talk and interview time to the conference’s speakers, broadcast the keynotes and other popular seminars, and offer attendees who don’t speak at the podium a chance to share their ideas. Many hackers who already do their own podcasts are being asked to contribute and do special programs for the conference.

Program and content submissions are still being taken, volunteers are being sought, and the organizers are looking for promotional sponsors to help cover the cost of broadcasting. More information can be found at http://radio.hope.net/ or by emailing projects@hope.net.

Damn, I’ll have to break out Garageband or maybe I’ll have to submit one of these tracks? HA!

As Debian revealed in their disclosure, the bug was created because they removed a line of code based on a warning from the Purify tool that the code, part of the random number generator, was using uninitialized data.

Of course, this was part of the seed for the generator, and the fact that the data was uninitialized was part of its randomness. In fact, OpenSSL developers had dealt with this issue years before and decided that uninitialized data in this case was a virtue, not a vice. So when they removed the line of code they left the process ID as the only random factor, and it was limited to a 32K range.

Alun Jones, the blogger, them asks the obvious question that I should have asked before, namely why they would leave two weak factors as the random number seed? Actually, it seems that this is how the code works in the absence of an outside randomness source. I thought all you needed for that was a system clock and you mod off the fractions of a second and use that as the seed. Could it be that's not always available?

Jones concludes by saying that these are some of the reasons why he likes the Microsoft Crypto API, and he's got some good points. When a problem is found and Microsoft updates it through Windows Update everyone gets the fix, or at least it's easily available. It's a well-implemented API and pretty well documented as opposed, he says, to OpenSSL.

The SQL [structured query language] inserts that came earlier were just pablum intended to lull the Army cadets into a false sense of security. But then the bad guys unleashed a stealthy kernel-level rootkit that burrowed into one workstation, started scraping data and "calling home."

It was a highly sophisticated attack, but this time the bad guys were really good guys in wolves' clothing.

For four days in late April, the National Security Agency -- the nation's most secretive repository of spooks, snoops and electronic eavesdroppers -- directed coordinated assaults on custom-built networks at seven of the nation's military academies, including West Point, the Army university 50 miles north of New York City.

It was all part of the seventh annual Cyber Defense Exercise, a training event for future military IT specialists. The exercise offered a rare window into the NSA's toolkit for infiltrating, corrupting or destroying computer networks.

The 34 Army cadets comprising the West Point IT team operated in a different kind of battlefield, but their combat skills and instincts need to be every bit as sharp. Like George Washington said: "There is nothing so likely to produce peace as to be well prepared to meet the enemy."

The SQL injections, targeting their Fedora Core 8 Web server, were a piece of cake for these IT combatants. Each injection tried to smuggle malicious code inside the seemingly harmless language used by the network’s MySQL software. The cadets handily defended with open source Apache web server modules, plus some manual tweaking of the SQL database to "avoid any surprises," in the words of Lt Col. Joe Adams, a West Point instructor who helped coach the team.

But the kernel-level rootkit was much more dangerous. This stealthy operating-system hijacker can open unseen "back doors" into even highly protected networks. When they detected the rootkit's "calls home" the cadets launched Sysinternal's security software to find the hijacker, then they manually scoured the workstation to find the unwelcome executable file.

Then they terminated it. With extreme prejudice.

"This was probably the most challenging part of the exercise, since it required them to use some advanced techniques to find the rootkit," Adams says. And rooting it out helped boost the West Point team to the top of the pile when, in the aftermath of the exercise, the referees rated all the universities' network defenses.

For the second year in a row, the Army placed first over the Navy, Air Force, Coast Guard and others, winning geek bragging rights and the privilege of holding onto a gaudy, 60-pound brass trophy festooned with bald eagles and American flags. Adams credits the team’s thorough preparation and their excellent teamwork despite the round-the-clock schedule.

At the network control room on the second floor of West Point’s 200-year-old engineering building (which once was an indoor horse corral and still smells like it in some remote corners, according to one instructor), the IT team set up cots and, just for the hell of it, camouflaged netting. They worked in shifts, with one team member always monitoring incoming and outgoing traffic. He or she would alert other cadets -- "router guys" -- to block any suspicious addresses. Meanwhile, off-shift cadets would make food and coffee runs to keep everyone fueled up and alert. Together, the team was "faster than anyone else," Adams says.

But the way the cadets designed their network was a big factor in their victory, too. The NSA dictated some terms: All networks had to be capable of e-mail, chat and other services and had to be up and running at all times despite any attacks or defensive measures. Beyond that, the teams were free to come up with their own designs.

West Point's took three weeks to build. The cadets settled on a fairly standard Linux and FreeBSD-based network with advanced routing techniques for steering incoming traffic in directions of the IT team's choosing.

The choices in software tools for responding to any attack really boiled down to "automatic" versus "custom," says Eric Dean, a civilian programmer and instructor. He adds that while automatic tools that do most of their own work are certainly easier, custom tools that allow more manual tweaking are more effective. "I expect one of the 'lessons learned' will be the use of custom tools instead of automatics."

Even with a solid network design and passable software choices, there was an element of intuitiveness required to defend against the NSA, especially once it became clear the agency was using minor, and perhaps somewhat obvious, attacks to screen for sneakier, more serious ones.

"One of the challenges was when they see a scan, deciding if this is it, or if it’s a cover," says Dean. Spotting "cover" attacks meant thinking like the NSA -- something Dean says the cadets did quite well. "I was surprised at their creativity."

Legal limitations were a surprising obstacle to a realistic exercise. Ideally, the teams would be allowed to attack other schools' networks while also defending their own. But only the NSA, with its arsenal of waivers, loopholes, special authorizations (and heaven knows what else) is allowed to take down a U.S. network.

And despite the relative sophistication of the NSA's assaults, the agency told Wired.com that it had tailored its attacks to be just "a little too hard for the strongest undergraduate team to deal with, so that we could distinguish the strongest teams from the weaker ones."

In other words, grasshopper, nice work -- but the NSA is capable of much craftier network take-downs.

You’ve read the headlines.  You’ve heard the buzzwords.  

Cloud Computing just seems like hype, right?  

“But it’s just another technology getting hyped to the max”.

The best case scenario is that your analysis is correct and you can go back to reading Slashdot and Daily Dave (you are reading Daily Dave aren’t you?).  You can pride yourself on your ability to recognise web hysteria and laugh at the losers that invested, wrote blog posts (!) and dared to take it seriously.

OK.  Now lets flip that around and just say for a moment you’re wrong - that Cloud Computing turns out to be a huge deal and takes off.  What could that mean for your day job?  No in-house servers to secure?  No in-house security operations to deal with? No in-house penetration tests to run?  No vulnerability assessment tools to run? No incident response where you actually ‘do something’?  

One scenario is you find yourself on a constant round of conference calls with 3rd parties trying to ‘pin down’ security in the cloud…  If you thought handling security issues associated with outsourcing was painful and slow, the Cloud will bring a multitude of competing providers that decision makers can switch from ‘digitally’ when the numbers ($$) make sense.

As the person responsible for your employer’s security arrangements, you may want to consider these 5 reasons for not dismissing Cloud Computing out of hand:

• Unless you work for an IT company, your employer did not go into business to ‘do IT’.  They are in business to sell a product or a service - in-house IT may have enabled that up to now but it was out of need rather than desire.  Cloud Computing has hit the cover of popular business magazines - its starting to get on the radar of CEO’s that ask questions like ‘how can I cut my costs?’, ‘how can I make my business more agile?’.  They may not switch overnight, but once the first goes in a given vertical, the clock is ticking.
• The temptation to contractually outsource security responsibility.  ”Our customer data got stolen from a cloud storage provider - not us - we don’t run IT!”.  Sure the buck stops with the org from a regulatory perspective but media coverage around recent data leakages involving 3rd party providers illicits a mixed reaction and thus diffuses the “reputation issues” to some extent.
• The skills you need to deal with Cloud Security may be different from the skills you have today.  Your “window” on Cloud security will be what the Cloud Provider gives you.  Beyond that you may be able to do an on-site audit from time to time but its a shared facility so no monkey in a cage pen-testing, scanning or filesystem forensic analysis.
• There’s a large cloud forming over the horizon.  The level of investment by providers doesn’t bear ignoring.  IBM, Google, Amazon, Microsoft and others are ploughing hundreds of millions of dollars building out data centers specifically for Cloud Computing.
• You may just end up working for the Cloud Provider!  This is something I believe will start happening in the next 2-3 years.  If you need a second opinion, go see Richard Bejtlich’s blog when he shared his own perspective.

What say you?  Hype or pending reality?

It started when I had to change my flight home for the trip this week.  The Expedia Corporate folks messed up the pricing and canceling of my first flight because their site was down, so it wound up costing 800 dollars more than it should have!  But I cannot miss the show, so had to eat it. I got to Ft Lauderdale airport this afternoon to find out my flight out was 45 minutes late.  That put my connection in Atlanta in jeopardy.  The agent checking me in (who took 45 minutes for the two people in front of me) put a big priority tag on my luggage because I am Platinum Medallion on Delta.  As he was doing that, I said to myself that is a kiss of death if I ever saw one.  I got to Atlanta to find out my connection was an hour late anyway and everything was fine, if you don't count landing in San Fran at 1am pacific time (4am east coast time) to late.  So I got on the plane and we are off to San Fran.  On the way there a woman on the plane had some medical problem, so when we landed there were paramedics waiting for the plane.  Though the woman appeared alright now, we had to wait for them to come on, exam her and take her off the plane.  About 20 minutes later, they let us off the plane.  Ok, now it is 1:30 in the morning pacific, 4:30am on my body clock.

I head down to baggage claim. I wait another 30 minutes for all of the luggage to come off the plane and don't you know it, my luggage with the big priority tag they put on it is not on the plane.  I stand on another line to make another claim.  They tell me that the first flight in tomorrow is due in at 10:58 am, I might have my luggage by noon if I am very lucky.  That is great, I am scheduled to be at the Americas Growth Capital Conference at 8:30am.  I am sure I will look great in my Levi jeans and denim shirt with sneakers! Not to mention using the cheap toiletries that the hotel gives the dredges who don't have their own deodorant.   Also what is the idea with hotels charging $12.95 a night for Internet access.  Shame on you San Francisco Hilton!

So far this is one hell of a conference and trip.  Can't tell you how happy I am to have come out here already.  The good news is that it can only get better, not sure how it can get worse.  More tomorrow.