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.

ScienceLogic: How long have you been involved in InteropNet?

Katsev: I started at Coyote Point 3 years ago and InteropNet 2006 was my first “big” assignment.  This was the first time Coyote Point had put in a proposal to participate, so we were very excited when we were selected.

ScienceLogic: How long has Coyote Point been involved in Interop overall?

Katsev: We’ve been exhibiting at Interop for a number of years, and after seeing the InteropNet in action, we decided to submit a proposal in ‘06.  We were actually one of the first companies in the load balancing/traffic management space (we’ve been doing this for almost 10 years), so we have a lot of experience to share with InteropNet.

ScienceLogic: What is your role at Coyote Point?

My official title is “Engineering Project Manager”.  Basically, that means that I’m in charge of product releases and maintenance.  It sounds like a weird title for someone participating in InteropNet, but I’ve actually found it extremely useful since my position means that I don’t get to see our systems out in the field a lot.  We’ve added several features and have ideas for others just from my experiences at InteropNet.

ScienceLogic: What do the Coyote Point products do?

Katsev: Coyote Point makes a Traffic Management appliance called Equalizer.  What this means is that any traffic destined for a datacenter’s servers goes through our appliances and we make sure that the server which is best equipped to handle it, does.  Our systems sit between the clients and the servers and monitor the client traffic and the state of the servers.  If the clients start sending more traffic, we’ll balance it out so that no server is overloaded.  If one of the servers stops responding or starts responding very slowly, we’ll steer traffic away from that server.

ScienceLogic: In what way are your products being used as part of InteropNet?

Katsev: In the InteropNet, we’re utilizing a lot of our expertise:  We’re making sure that traffic is balanced and servers are redundant for show services such as DNS and SMTP.  We’re also using our geographic load balancing technology to ensure that the ScienceLogic EM7 appliances and some other internal NOC services are available from anywhere, with the lowest latency, with our SSL acceleration and GZIP compression technology.  Finally, we’re helping logistics in the NOC by allowing a physical separation between systems located in the NOC and those in an emergency rack outside of the NOC.  If either of these two locations were to fail, the network will continue operating without a glitch.

ScienceLogic: Are there any special considerations for Interop that cause you to deploy your systems there differently that any other place?

Katsev: Interop is definitely different than most of our customer installations.   One difference from a standard environment is that the network (at least this year) is one large flat network, with pieces carved out where extra security is needed.  Because of this, we can actually run our failover pairs of Equalizer systems in a non-standard configuration where the two peers are in different racks, or even on different floors.  That’s one of the things that I really like about InteropNet — it definitely brings new ideas to mind, which end up becoming ’special configuration’ white papers after the show.

ScienceLogic: Has InteropNet taught you anything that caused you to actually change your product?

Katsev: In addition to the failover configuration differences I mentioned above, participating in InteropNet has actually caused us to add several new features and allowed configurations.  One example is the “no-spoof” option for Layer 4 clusters.  Prior to the 2006 shows, we always ’spoofed’ the client’s IP address when talking to a server so that the server would see the client’s IP address instead of our own.  At Interop, we ran into a special configuration which would’ve been very difficult to set up in this manner, so our engineers added this feature, and it’s been very a very popular configuration with our customers ever since.

We have also had a couple of business relationships that extended outside of the show.  In 2006, we had a good experience using Spirent Communications gear to benchmark the network, so we ended up purchasing a couple of these systems to test our products.  More recently, we have found a way to bundle our Equalizer e350si load balancers with the ScienceLogic EM7 collector appliances to help ScienceLogic get the best performance in load balancing large quantities of syslog messages to be processed.  If it wasn’t for our participation in InteropNet, neither of these relationships would’ve happened.

ScienceLogic: What’s the best part of being involved with InteropNet?  What do you most look forward to?

Katsev: InteropNet is an amazing networking opportunity (no pun intended).  The group of engineers that put the network together every year is, well, amazing.  There is so much combined experience that any question instantly has several possible answers, and the best answer is chosen very quickly.  One of the ’sayings’ at Interop is “if you run into a problem, ask someone… we’ve probably seen that problem before… five times.”  One would think that being part of InteropNet is the same thing, year after year.  However, in the two years that I’ve been part of this (for four shows), there have been huge differences in the way that the network is designed and put together.  These are both because the vendors selected every year are different, and because the engineers who design the network change from year to year.  Somehow, though, when all is said and done, we have a network that works.

ScienceLogic: You don’t have to answer this one if you’re not comfortable… What would you like to see changed with the way things are done at InteropNet?

Katsev: This isn’t a cop-out… I really can’t think of anything I would do differently.  Sure, there are small problems that pop up sometimes, but every project has those, and the people at InteropNet are more than capable of figuring them all out.  In fact, I know that Interop started out as a show to test the interoperability of devices… but I’m still amazed that all of these devices actually talk to each other and “play nice” together.

ShareThis

The new compression technique, called variable bitrate compression produces different size packets of data for different sounds.

That happens because the sampling rate is kept high for long complex sounds like "ow", but cut down for simple consonants like "c". This variable method saves on bandwidth, while maintaining sound quality.

VoIP streams are encrypted to prevent eavesdropping. However, a team from John Hopkins University in Baltimore, Maryland, US, has shown that simply measuring the size of packets without decoding them can identify whole words and phrases with a high rate of accuracy.

The technique isn't good enough to decode entire conversations, but it's pretty impressive.

Fear, in other words, is a tax, and al-Qaeda and its ilk have done better at extracting it from Americans than the Internal Revenue Service. Think about the extra half-hour millions of airline passengers waste standing in security lines; the annual cost in lost work hours runs into the billions. Add to that the freight delays at borders, ports and airports, the cost of checking money transfers as well as goods in transit, the wages for beefed-up security forces around the world. And that doesn't even attempt to put a price tag on the compression of civil liberties or the loss of human dignity from being groped in full public view by Transportation Security Administration personnel at the airport or from having to walk barefoot through the metal detector, holding up your beltless pants. This global transaction tax represents the most significant victory of Terror International to date.

The new fear tax falls most heavily on the United States. Last November, the Commerce Department reported a 17 percent decline in overseas travel to the United States between Sept. 11, 2001, and 2006. (There are no firm figures for 2007 yet, but there seems to have been an uptick.) That slump has cost the country $94 billion in lost tourist spending, nearly 200,000 jobs and $16 billion in forgone tax revenue -- and all while the dollar has kept dropping.

Why? The journal Tourism Economics gives the predictable answer: "The perception that U.S. visa and entry policies do not welcome international visitors is the largest factor in the decline of overseas travelers." Two-thirds of survey respondents worried about being detained for hours because of a misstatement to immigration officials. And here is the ultimate irony: "More respondents were worried about U.S. immigration officials (70 percent) than about crime or terrorism (54 percent) when considering a trip to the country."

In Beyond Fear I wrote:

Security is a tax on the honest.

If it weren’t for attackers, our lives would be a whole lot easier. In a world where everyone was completely honorable and law-abiding all of the time, everything we bought and did would be cheaper. We wouldn’t have to pay for door locks, police departments, or militaries. There would be no security countermeasures, because people would never consider going where they were not allowed to go or doing what they were not allowed to do. Fraud would not be a problem, because no one would commit fraud. Nor would anyone commit burglary, murder, or terrorism. We wouldn’t have to modify our behavior based on security risks, because there would be none.

But that’s not the world we live in. Security permeates everything we do and supports our society in innumerable ways. It’s there when we wake up in the morning, when we eat our meals, when we’re at work, and when we’re with our families. It’s embedded in our wallets and the global financial network, in the doors of our homes and the border crossings of our countries, in our conversations and the publications we read. We constantly make security trade-offs, whether we’re conscious of them or not: large and small, personal and social. Many more security trade-offs are imposed on us from outside: by governments, by the marketplace, by technology, and by social norms. Security is a part of our world, just as it is part of the world of every other living thing. It has always been a part, and it always will be.

Q1: For those companies that have successfully implemented enterprise-wide logging, what were the big nasty surprises that they encountered?

A1: Here are a few:

• political boundaries within the organization: "these are our logs, and you are not getting them"
• privacy laws: some logs cannot be collected in some countries; some cannot cross the border, some cannot be seen by some people, etc. This is true mostly in EU, less in US.
• legal blocks: work with legal before deploying any org-wide log management; legal might try to prevent certain data from ever being created (for fear of being legally discovered later)
• log volume: underestimating log volume is common and pretty nasty
• related to the last one: vendors being "optimistic" about their tool scalability
• time synchronization (of course!), specifically, lack thereof.

Q2: For those companies that have successfully implemented enterprise-wide logging, what was their implementation approach?

A2: Typically, 2-3 vendor PoC or pilot first. Then with the chosen vendor: phased approach based on location + type of log source (e.g. firewalls, then routers, then OS, then proxies, etc) + network topology (e.g. DMZ, then internal) + log source criticality (e.g. critical servers first; the rest next). This might be handy to look at.

Q3: What kind of storage requirements have been experienced by those organizations who have successfully implemented enterprise-wide logging?

A3: Massive? :-)

Here is a simple example: PCI DSS is a bit more aggressive than NERC since it mandates 1 year of log retention vs NERC 90 days, so: 1 year worth of logs is = 365 days x 24 hours x 3600 seconds x 1 (one!!!) busy firewall with 100 log messages each second x 200 bytes per message average (e.g. valid for PIX and ASA devices) = 588 gigabytes / year of raw log data uncompressed (assuming 10x compression you'd get about 60GB of compressed log data per year)

Store it in RDBMS? Multiple it by 2-3. Have an index? Add about 30%.

The bottom line is: terabyte is the unit to measure logs.

Q4: At the organizations that have successfully implemented enterprise-wide logging, how logging impacted network and system performance?

A4: Too broad a question, so here are a few pointers:

• logging affects performance much more on some types of systems compared to other types: most painful examples are databases where some people (can't find a link...sorry) report performance loss of up to 40% if logging all SELECT statements and other data retrieval commands (you need to log selectively on these); in other cases (e.g. web servers) there is no performance loss and logging is "always on"
• log collection: agents impact system performance (long post on this subjects): a little when they run (everybody knows this) and A LOT when they crash (few people think about it - agent software memory leaks are not uncommon); unlike agents, remote agentless log collection barely affects system performance (unless you have one of the few esoteric cases)
• log transfer and network performance: look for compressed (logs compress really well), TCP-based transfers; syslogging over UDP uncompressed has a chance of doing a pipe saturation DoS on your network. Yes, people say "use a dedicated LAN," but this is definitely wishful thinking for many. Also, raw UDP syslog in large quantities over WAN = insanity :-)

Q5: What were some successful strategies for obtaining buy-in from system owners and operators in regards to turning logging on?

A5: OK, also too broad a question, but here are some pointers:

• provide them a useful service based on their logs (e.g. performance measurement, availability monitoring, compromise detection :-), or other security metrics, etc)
• help them with their compliance mandates (e.g. create reports that they can show to the auditors that "bug" them)
• give them tools to better solve their problems (e.g. allow access to a log management tool so that can investigate issues better, search the logs, check on their users, etc)

Q6: How the organizations that have successfully implemented enterprise-wide logging dealt with unusual devices (=log sources) that have no log management vendor support?

A6: They were in massive pain - if they choose a log management vendor wrong. You need to look for vendors that have "universal log source support" with NO requirement for a custom rules or custom collector/connector/agent development. Some vendors have generic text log collectors that can grab and analyze unknown logs. Typically this is done via some form of text indexing that works across all logs, including those from unknown, vertical, esoteric or custom-developed log sources

Hope it was useful!

(FYI, for the impatient, click here.)

There are two ways to generate random numbers on computers: (1) use a software program called a Pseudorandom Number Generator (PRNG) or (2) use a hardware random number generator. A Pseudorandom Number Generator uses a seed value to generate a sequence of numbers that appear random. The problem is that the same seed generates the same random sequence. The hardware based RNG observes and samples some physical phenomenon which is random, such as cosmic rays, RF noise, etc. (aka Entropy).

RNGs are important in Information Security because they are used to generate encryption keys, salts, etc. Historically, attacking RNGs has proven effective, such as the defeat of Netscape’s HTTPS sessions.

Most operating systems utilize a hybrid approach, implementing a PseudoRandom Number Generator that has a seed that is regularly updated through the collection of random hardware events. This process is called Entropy Collection or Entropy Harvesting. For most applications, this approach should be completely sufficient. However, one of the key assumptions is that the operating system has been up and running long enough for the seed value itself to become hard to predict through the collection of Entropy. Also, many of the Entropy collecting events come from properties of hardware devices, such as the minor variations in hard drive rate of rotation. As such, there are a few circumstances where the OS RNG may not be good enough for strong cryptographic key generation:

• Live Boot CD ( The start state of the RNG may be predictable. )
• Virtualized Hosts ( OS may be dependent on simulated events for randomness. )

( Given the exploding popularity of virtualization, this is an area worthy of research. Stay tuned. )

Design of the Got Entropy Service

Many RNGs (such as the one included in Linux, as well as OpenSSL’s) allow the addition of entropy from outside sources. So I started looking to Entropy sources I could use to bolster the RNGs on my virtual hosts (and other uses…). While I was looking into this, it occurred to me that I had an unused TV tuner card, a PVR-350.

When a TV is tuned to a channel with no local station, the ’snow’ on the screen is RF noise (the same as the static between stations on AM radios). But, for reasons beyond our scope, you never use a direct physical observation as the RNG. You have to ‘de-skew and whiten’ the data prior to sampling it. Here is the process that I use:

1. Collect about 3 minutes of video ( about 130 MB data ).
2. Using a random key and IV, encrypt the data ( using openssl & AES-128-CBC ).
3. Discard the first 32k of the file.
4. Use each of the following 32k blocks as samples.
5. Compress each sample with SHA-256.
6. Discard the last block.

• Steps 2 and 3 remove any patterns, such as MPEG file formatting, from the data.
• Steps 4 and 5 generate a 32-byte random value ( 1024 to 1 compression in the hash ).

Check it out at http://gotentropy.artofinfosec.com

Can an Attacker Broadcast a Signal to Undermine This?

Such an attacker could not remove RF noise from the received signal. Our eyes and brains are good at filtering out the noise in the TV video, but there is a lot of it. Part of the noise comes from the atmospheric background RF, but there are also flaws (noise) in the tuner’s radio and analog-to-digital capture circuitry.

I think this is a pretty strong RNG, and I have provided an interface for pulling just the values.

Also, I have written a script ( getEntropy.sh ) that will pull Entropy from the service and seed it into /dev/random on Linux.

Results from ENT

Here are results, from a sample run of the Got Entropy, analyzed by ENT ( A Pseudorandom Number Sequence Test Program provided by John Walker of www.fourmilab.ch - Thanks, John! ).

• Entropy = 7.999987 bits per byte
• Optimum compression would reduce the size of this 13366112 byte file by 0 percent.
• Chi square distribution for 13366112 samples is 233.85, and randomly would exceed this value 82.48 percent of the time.
• Arithmetic mean value of data bytes is 127.4767 (127.5 = random).
• Monte Carlo value for Pi is 3.143054786 (error = 0.05 percent).
• Serial correlation coefficient is -0.000078 (totally uncorrelated = 0.0).

Resources for the Curious…

• Wikipedia - Pseudo-random Number Generator
• Wikipedia - Hardware Random Number Generator
• NIST - Random Numbers Page
• Netscape RNG Attack
• van Heusden Video Rand

Cheers, Erik

Art of Information Security would love your feedback !

Got Entropy ?

However, as some of you may realize from my previous postings (Vista Media Center Part 1, Part 2 and Part 3), I have been a fan of Media Center as a potential alternative to the recently-downgraded (don't get me started, even my wife lost what she considered *basic* features with the "standard" Comcast DVR downgrade) Comcast DVR.

The event that kicks this story of begins with a Poker game.  Just after Microsoft announced the new Zune line-up in October, I won a charity poker event where the prize was a custom Zune 30.  It was basically a "pearl" Zune with a special logo on the back and pre-loaded with some poker theme music that we heard during the event.  I played with it a few days, loading it with some songs and even buying a couple of recent ones from the Zune marketplace.

Then ... I discovered the killer feature ... integration with my Windows Vista Media Center.   Now, technically, this feature was not actually enabled when I discovered it.  However, it took me all of 5 minutes to find the registry mod on the Internet and enable it.  That became moot a week or so ago when the recent Zune upgrade rectified that issue, so now everyone can enjoy this feature by default.  Here is the very simple set-up instructions:

1. Install the Zune software on your media center
2. Make sure you add your "Recorded TV" folder, if it is in an odd place (mine is on an external half-TByte drive).
3. Plug in your Zune device as a guest
4. Sync recorded TV shows to your heart's content

Now, let's see why this rocks...

iPod vs Zune TV Comparison

The Apple Way...

There was much ado when the Daily Show became available on iTunes for $1 per show or $9.99 for 16 episodes (roughly 3 weeks of shows).  I browsed over to http://www.apple.com/itunes/store/tvshows.html just now and found this blurb:

Be a watercooler hero.  For as little as $1.99, you can own the latest episode of your favorite show as early as one day after it airs, or purchase past episodes that you missed (or want to watch over and over). Choose a Season Pass and get a whole season of a TV show, past or present, at a discount. Or buy Multi-Passes for shows that air every day, like The Daily Show with Jon Stewart, and enjoy a month’s worth of episodes downloaded automatically to your computer.

Well, yahoo, yipee!  Only $2 per show on your iPod, iPhone or Apple TV.

The Zune + Media Center Way ...

I record all of my favorite TV shows on my Windows Media Center.  In the evening, I plug in my Zune and choose which shows to sync for mobile watching.  For example, last night I chose the two latest episodes of Heroes which I had not gotten around to watching because of my recent Jury Duty and the holiday activities.  The Zune software automagically converts the show to 320x240 and syncs it to my Zune.

This morning on the Connector Bus to work, I watched Heroes Season 2, Episode 7, "Out of Time" and found out the surprising identity of "Adam Monroe."  I'll watch Episode 8 on the way home...

And My TV Movies Too...

And, it doesn't stop there.  As I described previously, I've been building up quite a library of TV Movies, cutting out commercials, compressing them and creating my own on-demand TV Movies library.  Since I got my Zune, I've switched to using MP4 compression with H.264 video and AAC3 audio, which gets added automatically to my Zune library and can be synced to the device... better together indeed!

With my Zune 30, this means I can load up about 50 kids movies and TV shows that I've previously recorded for those long road trips and vacations.  In fact, I can plug my Zune into the aux-video inputs in our mini-van and play directly on the integrated DVD video screen.

And it is all so easy...