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.

Yes, the New York Police Department provided an escort, but during more than eight hours on Saturday, one of the great hoards of coins and currency on the planet, worth hundreds of millions of dollars, was utterly unalarmed as it was bumped through potholes, squeezed by double-parked cars and slowed by tunnel-bound traffic during the trip to its fortresslike new vault a mile to the north.

In the end, the move did not become a caper movie.

“The idea was to make this as inconspicuous as possible,” said Ute Wartenberg Kagan, executive director of the American Numismatic Society. “It had to resemble a totally ordinary office move.”

[...]

Society staff members were pledged to secrecy about the timing of the move, and “we didn’t tell our movers what the cargo was until the morning of,” said James McVeigh, operations manager of Time Moving and Storage Inc. of Manhattan, referring to the crew of 20 workers.

From my book Beyond Fear, pp. 211-12:

At 3,106 carats, a little under a pound and a half, the Cullinan Diamond was the largest uncut diamond ever discovered. It was extracted from the earth at the Premier Mine, near Pretoria, South Africa, in 1905. Appreciating the literal enormity of the find, the Transvaal government bought the diamond as a gift for King Edward VII. Transporting the stone to England was a huge security problem, of course, and there was much debate on how best to do it. Detectives were sent from London to guard it on its journey. News leaked that a certain steamer was carrying it, and the presence of the detectives confirmed this. But the diamond on that steamer was a fake. Only a few people knew of the real plan; they packed the Cullinan in a small box, stuck a three-shilling stamp on it, and sent it to England anonymously by unregistered parcel post.

This is a favorite story of mine. Not only can we analyze the complex security system intended to transport the diamond from continent to continent­the huge number of trusted people involved, making secrecy impossible; the involved series of steps with their associated seams, giving almost any organized gang numerous opportunities to pull off a theft­but we can contrast it with the sheer beautiful simplicity of the actual transportation plan. Whoever came up with it was really thinking­and thinking originally, boldly, and audaciously.

This kind of counterintuitive security is common in the world of gemstones. On 47th Street in New York, in Antwerp, in London: People walk around all the time with millions of dollars’ worth of gems in their pockets. The gemstone industry has formal guidelines: If the value of the package is under a specific amount, use the U.S. Mail. If it is over that amount but under another amount, use Federal Express. The Cullinan was again transported incognito; the British Royal Navy escorted an empty box across the North Sea to Amsterdam -- ­where the diamond would be cut­ -- while famed diamond cutter Abraham Asscher actually carried it in his pocket from London via train and night ferry to Amsterdam.

Think for a moment about the very simple, used-to-death castle analogy with its walls, gates, guns, guards, etc. and how these parts related to early network security. The analogy certainly had its shortcomings already back then – but it nevertheless got popular because of its inherent simplicity.

In today’s complex data and identity driven world of security and risk management, the old castle simply doesn’t cut it any longer. Just think of examples like the skyrocketing amount of data “crown jewels” all over the place (not just in the tower), the almost constant transport of these assets to places in and mostly outside of the castle, and the fact that insiders/peasants pose a much bigger risk than external attackers. Also, there is not just one king today, everybody has something protect-worthy (data, identities, etc.) and the same person can in fact have multiple identities. Sure, you can add bits and pieces into the old castle metaphor, but it quickly becomes too complex and therefore useless as an analogy.

So, while most members of the security academia have given up on the castle some time ago, the question is: Can we provide a simple, yet somewhat holistic concept of modern security and risk management?

Fact is, that we as security professionals struggle to explain to non-security folks what it is we are doing and why we are doing what we are doing. A bit of insurance talk, a sprinkle of metrics, lots of tech explanations, and certainly a huge portion of scare tactics are still our most often applied tools. But we all know – and experience on a daily basis – that we are not making ourselves clear to LOB managers, executives, and other non-technical people.

So, is there a single, all encompassing metaphor any longer? Or will we inevitably end up comparing the complexity of today’s security and risk landscape to, well the “real” world? But then again, wouldn’t that ‘metaphor’ fall short of the main reason for why we use analogies – namely simplification? Hence, wouldn’t that be utterly useless?

Or, instead of trying to construct a next-gen analogy, do we simply have to become better at articulating ourselves? Are a non-tech language, simple words, and context going to be enough to get our message across? Or should partial analogies be thrown into our new communication mix? Or does everything ultimately boil down to K.I.S.S.?

Blogger: Dan Blum

There are two groups actively working to create a common event standard that allows event logs and audit records to be shared and understood across many products, and the good news is that they’re talking to each other:

• Common Event Expression (CEE) language, by Mitre 
• X/Open Distributed Audit Standard (XDAS), by Open Group 

The business benefits of creating a common event standard would be considerable:

• Reduced log management and security information event management (SIEM) system integration costs 
  • Reduced volume of event data and simplification of SIEM architecture 
  • Reduced need for (and increased effectiveness of) normalization 
• Reduced cost of integrating new solutions with security management infrastructures and frameworks 
• Lower cost of integrating event management and audit into cross-enterprise applications (such as federated identity management)
• Faster and simpler data exchange between organizations, vendors and incident response services supporting real time response to threats and attacks 
• Better forensics for a common defense 

Late last year, our Burton Group Security and Risk Management Strategies (SRMS) group decided to push the question of event standards with vendors, trade press, and standards groups. But we felt that we needed evidence of end user enterprise interest and involvement to start doing so. Happily, as we began researching the space, we found that Mitre’s CEE was being driven by the EU, NATO and DoD as well as log management and platform vendors. Burton Group held a conference call discussing common event standards and SIEM with members of the International Information Integrity Institute (I-4), and key stakeholders showed up. The Open Group reports that enterprises as well as vendors are getting involved with XDAS. Clearly, enterprises seem ready to focus on this topic.

Of course, there are challenges ahead. Not only is there no complete common event standard out in the field today, there are many partial standards or solutions, including Syslog; the IETF’s Intrusion Detection Message Exchange Format (IDMEF) and Incident Object Description and Exchange Format (IODEF); the Java Specification Request (JSR) 47 Logging API, WS-Management subscribe/publish APIs and so on. Any comprehensive standard released in the future should work with existing technologies like these as much as possible. Also, there are a number of complexities, including mapping event semantics between different systems, synchronizing time while managing clock drift, and maintaining dynamic event handling policies.

Fortunately, the Mitre and Open Group efforts are gaining traction. Mitre has put up a CEE web site and one can ask to subscribe to the CEE mailing list. Mitre has described its scope as covering standard event taxonomy/terminology, log syntax, log transport and recommendations on what types of events and data elements systems should log. Mitre’s specifications are in the draft stage, and publication for comment is “expected 2008” according to the website. That’s pretty indefinite. But we are told that while not complete, these draft documents will reflect a considerable amount for work that has already been done and can be built upon. It is positive that a CEE community representative says Mitre plans to begin by seeking comments on the underlying goals and requirements for event standards. But to establish a broadly accepted industry standard anytime soon, Mitre and the government/defense community it servers will have to accelerate overly lengthy document review cycles and possibly streamline handling procedures designed for classified information rather than open standards deliberation.

As my colleague Bob Blakley wrote in “An Auditing Standard: Has this rough beast's hour come round at last?” last July, Open Group revived prior work on a specification called “X/Open Distributed Audit Standard” (XDAS).  XDAS addresses the concerns necessary to build a robust distributed security auditing system in a mature and complete way, but its 1990s era C and UNIX interfaces need to be updated. Novell, whose Bandit Project incorporates XDAS, has contributed source code to a new open-source project called OpenXDAS (http://openxdas.sourceforge.net/) which makes an XDAS implementation widely available.

As these two standards efforts proceed, we hear mixed signals. There have been some indications of contention; for example, CEE representatives purport to have a strong emphasis on “simplicity,” while some observers have expressed concern that XDAS may be “too complex.” Of course, the other side of the argument could be that CEE will over-simplify issues, but it’s hard to have that discussion when specifications for CEE aren’t publicly available yet.

Fortunately, olive branches have been extended as well. During the Open Group meetings in January, 2008 Burton Group observed the XDAS and CEE leadership discuss ways they could coordinate and avoid overlaps. For example, CEE and XDAS could make sure that XDAS APIs become a CEE-compatible logging transport and, if both organizations produce data dictionaries for events, they could be perhaps formulated to use a common taxonomy and to avoid schema conflicts and overlaps. We’re also hoping that vendors such as Arcsight, Oracle and CA – who have been proactive about proposing specifications or encouraging the industry to create a common event standard – will be become part of the convergence on a common solution.

In the coming weeks and months, Burton Group will keep watching the event standards space and post more information on how matters develop. Please let us know by commenting on this blog if there are other standards efforts we should be watching, compatibility concerns to address, or other issues and questions you’re concerned about. We hope to continue being a voice for convergence and standardization that helps put the industry on the road to a common event standard by 2009.

Blogger: Dan Blum

There are two groups actively working to create a common event standard that allows event logs and audit records to be shared and understood across many products, and the good news is that they???re talking to each other:

• Common Event Expression (CEE) language, by Mitre 
• X/Open Distributed Audit Standard (XDAS), by Open Group 

The business benefits of creating a common event standard would be considerable:

• Reduced log management and security information event management (SIEM) system integration costs 
  • Reduced volume of event data and simplification of SIEM architecture 
  • Reduced need for (and increased effectiveness of) normalization 
• Reduced cost of integrating new solutions with security management infrastructures and frameworks 
• Lower cost of integrating event management and audit into cross-enterprise applications (such as federated identity management)
• Faster and simpler data exchange between organizations, vendors and incident response services supporting real time response to threats and attacks 
• Better forensics for a common defense 

Late last year, our Burton Group Security and Risk Management Strategies (SRMS) group decided to push the question of event standards with vendors, trade press, and standards groups. But we felt that we needed evidence of end user enterprise interest and involvement to start doing so. Happily, as we began researching the space, we found that Mitre???s CEE was being driven by the EU, NATO and DoD as well as log management and platform vendors. Burton Group held a conference call discussing common event standards and SIEM with members of the International Information Integrity Institute (I-4), and key stakeholders showed up. The Open Group reports that enterprises as well as vendors are getting involved with XDAS. Clearly, enterprises seem ready to focus on this topic.

Of course, there are challenges ahead. Not only is there no complete common event standard out in the field today, there are many partial standards or solutions, including Syslog; the IETF???s Intrusion Detection Message Exchange Format (IDMEF) and Incident Object Description and Exchange Format (IODEF); the Java Specification Request (JSR) 47 Logging API, WS-Management subscribe/publish APIs and so on. Any comprehensive standard released in the future should work with existing technologies like these as much as possible. Also, there are a number of complexities, including mapping event semantics between different systems, synchronizing time while managing clock drift, and maintaining dynamic event handling policies.

Fortunately, the Mitre and Open Group efforts are gaining traction. Mitre has put up a CEE web site and one can ask to subscribe to the CEE mailing list. Mitre has described its scope as covering standard event taxonomy/terminology, log syntax, log transport and recommendations on what types of events and data elements systems should log. Mitre???s specifications are in the draft stage, and publication for comment is ???expected 2008??? according to the website. That???s pretty indefinite. But we are told that while not complete, these draft documents will reflect a considerable amount for work that has already been done and can be built upon. It is positive that a CEE community representative says Mitre plans to begin by seeking comments on the underlying goals and requirements for event standards. But to establish a broadly accepted industry standard anytime soon, Mitre and the government/defense community it servers will have to accelerate overly lengthy document review cycles and possibly streamline handling procedures designed for classified information rather than open standards deliberation.

As my colleague Bob Blakley wrote in ???An Auditing Standard: Has this rough beast's hour come round at last???? last July, Open Group revived prior work on a specification called ???X/Open Distributed Audit Standard??? (XDAS).  XDAS addresses the concerns necessary to build a robust distributed security auditing system in a mature and complete way, but its 1990s era C and UNIX interfaces need to be updated. Novell, whose Bandit Project incorporates XDAS, has contributed source code to a new open-source project called OpenXDAS (http://openxdas.sourceforge.net/) which makes an XDAS implementation widely available.

As these two standards efforts proceed, we hear mixed signals. There have been some indications of contention; for example, CEE representatives purport to have a strong emphasis on ???simplicity,??? while some observers have expressed concern that XDAS may be ???too complex.??? Of course, the other side of the argument could be that CEE will over-simplify issues, but it???s hard to have that discussion when specifications for CEE aren???t publicly available yet.

Fortunately, olive branches have been extended as well. During the Open Group meetings in January, 2008 Burton Group observed the XDAS and CEE leadership discuss ways they could coordinate and avoid overlaps. For example, CEE and XDAS could make sure that XDAS APIs become a CEE-compatible logging transport and, if both organizations produce data dictionaries for events, they could be perhaps formulated to use a common taxonomy and to avoid schema conflicts and overlaps. We???re also hoping that vendors such as Arcsight, Oracle and CA ??? who have been proactive about proposing specifications or encouraging the industry to create a common event standard ??? will be become part of the convergence on a common solution.

In the coming weeks and months, Burton Group will keep watching the event standards space and post more information on how matters develop. Please let us know by commenting on this blog if there are other standards efforts we should be watching, compatibility concerns to address, or other issues and questions you???re concerned about. We hope to continue being a voice for convergence and standardization that helps put the industry on the road to a common event standard by 2009.