This reality of the information age might be particularly stark for the president, but it's no less true for all of us. Conversation used to be ephemeral. Whether face-to-face or by phone, we could be reasonably sure that what we said disappeared as soon as we said it. Organized crime bosses worried about phone taps and room bugs, but that was the exception. Privacy was just assumed.

This has changed. We chat in e-mail, over SMS and IM, and on social networking websites like Facebook, MySpace, and LiveJournal. We blog and we Twitter. These conversations -- with friends, lovers, colleagues, members of our cabinet -- are not ephemeral; they leave their own electronic trails.

We know this intellectually, but we haven't truly internalized it. We type on, engrossed in conversation, forgetting we're being recorded and those recordings might come back to haunt us later.

Oliver North learned this, way back in 1987, when messages he thought he had deleted were saved by the White House PROFS system, and then subpoenaed in the Iran-Contra affair. Bill Gates learned this in 1998 when his conversational e-mails were provided to opposing counsel as part of the antitrust litigation discovery process. Mark Foley learned this in 2006 when his instant messages were saved and made public by the underage men he talked to. Paris Hilton learned this in 2005 when her cell phone account was hacked, and Sarah Palin learned it earlier this year when her Yahoo e-mail account was hacked. Someone in George W. Bush's administration learned this, and millions of e-mails went mysteriously and conveniently missing.

Ephemeral conversation is dying.

Cardinal Richelieu famously said, :If one would give me six lines written by the hand of the most honest man, I would find something in them to have him hanged." When all our ephemeral conversations can be saved for later examination, different rules have to apply. Conversation is not the same thing as correspondence. Words uttered in haste over morning coffee, whether spoken in a coffee shop or thumbed on a Blackberry, are not official pronouncements. Discussions in a meeting, whether held in a boardroom or a chat room, are not the same as answers at a press conference. And privacy isn't just about having something to hide; it has enormous value to democracy, liberty, and our basic humanity.

We can't turn back technology; electronic communications are here to stay and even our voice conversations are threatened. But as technology makes our conversations less ephemeral, we need laws to step in and safeguard ephemeral conversation. We need a comprehensive data privacy law, protecting our data and communications regardless of where it is stored or how it is processed. We need laws forcing companies to keep it private and delete it as soon as it is no longer needed. Laws requiring ISPs to store e-mails and other personal communications are exactly what we don't need.

Rules pertaining to government need to be different, because of the power differential. Subjecting the president's communications to eventual public review increases liberty because it reduces the government's power with respect to the people. Subjecting our communications to government review decreases liberty because it reduces our power with respect to the government. The president, as well as other members of government, need some ability to converse ephemerally -- just as they're allowed to have unrecorded meetings and phone calls -- but more of their actions need to be subject to public scrutiny.

But laws can only go so far. Law or no law, when something is made public it's too late. And many of us like having complete records of all our e-mail at our fingertips; it's like our offline brains.

In the end, this is cultural.

The Internet is the greatest generation gap since rock and roll. We're now witnessing one aspect of that generation gap: the younger generation chats digitally, and the older generation treats those chats as written correspondence. Until our CEOs blog, our Congressmen Twitter, and our world leaders send each other LOLcats – until we have a Presidential election where both candidates have a complete history on social networking sites from before they were teenagers– we aren't fully an information age society.

When everyone leaves a public digital trail of their personal thoughts since birth, no one will think twice about it being there. Obama might be on the younger side of the generation gap, but the rules he's operating under were written by the older side. It will take another generation before society's tolerance for digital ephemera changes.

This essay previously appeared on The Wall Street Journal website (not the print newspaper), and is an update of something I wrote previously.

The PDF document holds a single paged scan of an internally distributed mail from German telecommunications company T-Systems (Deutsche Telekom), revealing over two dozen secret IP address ranges in use by the German intelligence service Bundesnachrichtendienst (BND). Independent evidence shows that the claim is almost certainly true and the document itself has been verified by a demand letter from T-systems to Wikileaks.

Hash functions are the most commonly used cryptographic primitive, and the most poorly understood. You can think of them as fingerprint functions: They take an arbitrary long data stream and return a fixed length, and effectively unique, string. The security comes from the fact that while it's easy to generate the fingerprint from a file, it's infeasible to go the other way and generate a file given a fingerprint.

Originally created to make digital signatures more efficient, hashes are now used to secure the very fundamentals of our information infrastructure: in password logins, secure web connections, encryption key management, virus and malware scanning, and almost every cryptographic protocol in current use. Without cryptographic hash functions, the internet would simply not work. At the same time, there isn't a good theory of hash functions. Unlike encryption algorithms, there are no secret keys involved; this makes it harder to mathematically define exactly what hash functions are.

The National Institute of Standards and Technology, NIST, is holding a competition to replace the SHA family of hash functions. "SHA" stands for "Secure Hash Algorithm." It was developed by the NSA in 1993 to replace the commercial MD4 and MD5 algorithms, and has been updated several times since then. All the SHA algorithms are very similar, and have been increasingly under attack, so NIST wants to replace them.

The competition is important because, unlike other technological standards, committee design — balancing the interests of diverse constituents — isn't conducive to good security. Security is best when it's designed by expert teams and then subjected to public review. And cryptography is best when it's chosen by competition.

In 1997, NIST held a competition for a block cipher to replace DES. Fifteen candidates and three-and-a-half years later, Rijndael became the new Advanced Encryption Standard — AES. NIST is doing the same thing for what it's calling SHA-3 (not, for some unexplained reason, the Advanced Hash Standard or AHS).

The deadline was October 31, and NIST received 64 submissions. This isn't surprising — I predicted 80 — as most of the 15 AES submitters were professors, whose students at the time have become professors themselves, with their own students. (If NIST does a stream cipher competition in another ten years, they should expect about 256 submissions.) These submissions came from academia, from industry, and from hobbyists. CIO magazine recently interviewed one of the submitters, who is 15. Twenty-eight submissions have been made public by the submitters, and six of those have been broken.

NIST is going through all the submissions right now, making sure they are complete and proper. Their goal is to publish all accepted submissions by the end of November, in advance of the First Hash Function Candidate Conference, to be held in Belgium right after the Fast Software Encryption workshop in February.

The group expects to quickly make a first cut of algorithms — hopefully to about a dozen — and give the community a year of cryptanalysis before making a second cut in 2010. After another year of cryptanalysis, NIST will choose a winner in 2011. Expect a final standard by 2012.

My advice for software developers is to let the process run its course. While it's tempting to use the new cool algorithms in your designs, it's far too soon to trust any of them. This process is likely to result in all sorts of new research results in hash function security, and some real cryptanalytic surprises. Give the community a few years to figure out which ones are good and which aren't.

I've previously called this sort of thing a cryptographic demolition derby: The last one left standing wins. But that's only partially true. Certainly all the groups will spend the next few 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; in this process, the best is the enemy of the good. While there's no rush to choose a new standard — the SHA-2 algorithms will remain secure for the foreseeable future — we don't want to analyze the candidates forever.

Personally, I was part of a group of eight cryptographers that submitted Skein to the competition. A decade ago, writing Twofish and participating in the AES process was the most fun I had ever had in cryptography. These next few years promise to be even more fun.

---

Bruce Schneier is chief security technology officer of BT. His new book is Schneier on Security.

Jeff Clark of Neoformist is one such artist blurring the boundaries between programming, verbal, and visual art. Using a scripted algorithm he generates portraits of famous people and animals using an algorithm that creates words in the colors and patterns needed to create the portrait. Some examples feature a shot of Barack Obama created with the words “Yes We Can” and Albert Einstein with the word “Genius.” Very cool– go take a look.

So, here is my next monthly "Security Warrior" blog round-up of top 5 popular posts and topics.

1. OF COURSE, the news of my “transition” is the item #1, by far. “Change!!!” and “Qualys” posts rule the list.
2. Last month I posted a bunch of my presentations on logs, security, etc on the blog.  “Presentation from GOVCERT.NL 2008: Log Forensics” takes one of the tops spots; and so do “Presentation on Application Logging, Done Wrong or Very Wrong” and “Presentation on Optimizing Your Logging for Insider Attack Tracking.”  BTW, all the presentations are here.
3. Shockingly, AGAIN this month, the "Top 11 Reasons to Secure and Protect Your Logs" came up as #1 most popular post (maybe driven by my poll).  BTW, see my other logging polls and my other “top 11” lists.
4. SIEM bashing reached a new high (eh…“low”? :-)), now that Richard is helping too;  my “11 Signs That Your SIEM Is A Dog or "Raffy, You Killed SIM!" is on the top list. It is both humorous and sadly true (and backed up by other sources and here.)
5. Somewhat predictably, PCI compliance is obviously still all the rage: MUST-DO Logging for PCI? post was again propelled to a place in my monthly Top5 list.

See you in November.

Possibly related posts / past monthly popular blog round-ups:

• Monthly Blog Round-Up - September 2008
• Monthly Blog Round-Up - August 2008
• Monthly Blog Round-Up - July 2008
• Monthly Blog Round-Up - June 2008
• Monthly Blog Round-Up - May 2008  
• Monthly Blog Round-Up - April 2008  
• Monthly Blog Round-Up - March 2008  
• Monthly Blog Round-Up - February 2008  
• Monthly Blog Round-Up - January 2008  
• Monthly Blog Round-Up - December 2007  
• Monthly Blog Round-Up - November 2007  
• Monthly Blog Round-Up - October 2007  
• Monthly Blog Round-Up - September 2007
• Monthly Blog Round-Up - August 2007

No longer are OS vendors and other large infrastructure technology providers the main source of vulnerabilities. It’s the thousands of applications, produced by thousands of software vendors, that make up this huge 3rd wave. ISS reported that in 2007 that the top five sources of vulnerabilities: Microsoft, Apple, Oracle, IBM, and Cisco, had dropped to supplying us with only 13.6% of our vulnerabilities. 86.4% came from the other thousands of software vendors that supply our computers with a seemingly unending supply of vulnerabilities for attackers to exploit.

In a recent report Microsoft has congratulated itself on doing a good job securing Windows. And by all accounts they have done a good job. But then they state this:

“Unless software development practices change throughout the industry, any improvements in the security of Windows would be meaningless.”

Whoa. Millions of dollars spent on securing the most prevalent piece of software and it could be meaningless? Yes, it’s true. Since attackers typically only need one vulnerability, if it isn’t in the network, and it isn’t in the host configuration, and it isn’t in the OS, they will happily exploit a vulnerability in an application.

At every shift of exploit target the problem has gotten more difficult to solve. Networks had choke points and could be centrally managed. It took a while but eventually host configurations became centrally managed and automated tools could scan configurations. Although OSes were huge and complex beasts with 10’s of millions of lines of code, with enough effort, their vulnerabilities have been largely tamed as Microsoft’s Windows and the Linux kernel track record shows. This was a very substantial, over five year effort, which used some of the most talented security people anywhere.
But now what to do? Instead of a few OSes we now have thousands of applications with vulnerabilities. As Microsoft found out, the attackers don’t go away, they just move on to the next incrementally less juicy vulnerability. In the world of exploits that typically means the vulnerability with the next smallest target population.

Attackers have started with the common client applications that can be found on almost every machine: Acrobat, Flash, RealPlayer, Quicktime, popular antivirus software. And they will continue down the popularity slope until they get to application populations down in the thousands which is getting to fairly small software vendors. Attackers can do this because they can bundle many vulnerabilities together, exploiting the statistical fact that you must have some vulnerable software installed. Compromised web sites have been found attacking visitors with over ten client side exploits preying on multiple versions of vulnerable client software.

The solution to this problem is all software must be written securely, not just the software from the big guys. Small vendors think they aren’t a target just like home users used to think they weren’t a target. People thought, “Why would someone want to attack my home computer?” Then they realized they did home banking, or had a fast internet connection that could be used for DDoS attacks or sending spam. All software vendors need to get the same wakeup call. Attackers don’t want to find a vulnerability in your software to make you look bad. They want any vulnerability. If the population of your software is small they will just bundle your vulnerability together with others in an exploit pack. The days of the average software vendor not having to worry about application security are officially over.

The best security program is at the business with the happiest customers.

There's a fine line between happy customers and playing piano in a bordello.

Sees a lot
Can tell the king he has no clothes
Can tell the king he really is ugly
Does not get killed by the king
Nice to have around but…how much security improvement comes from this ?

Changes happened faster that he was able to move
Did not read the signs
Good intentions went unfulfilled
A brutal way to ending a promising career
Sad to have around but…how much security improvement comes from this ?

Obviously these models of CISOs are not solving our information security problems. Instead Dr. Garigue points us to Charlemagne as a better model

King of the Franks and Holy Roman Emperor; conqueror of the Lombards and Saxons (742-814) - reunited much of Europe after the Dark Ages.

He set up other schools, opening them to peasant boys as well as nobles. Charlemagne never stopped studying. He brought an English monk, Alcuin, and other scholars to his court - encouraging the development of a standard script.

He set up money standards to encourage commerce, tried to build a Rhine-Danube canal, and urged better farming methods. He especially worked to spread education and Christianity in every class of people.

He relied on Counts, Margraves and Missi Domini to help him.

Margraves - Guard the frontier districts of the empire. Margraves retained, within their own jurisdictions, the authority of dukes in the feudal arm of the empire.

Missi Domini - Messengers of the King.

This is the way forward! Find software security champions in the architecture and development groups,help them understand the real security issues. They will find solutions you have not thought of. Same for DBAs, same for business analysts even. Its all about beating the bushes, education, and decentralizing security services. Specifically, he points out this important mandate for IT security

Knowledge of risky things is of strategic value

How to know today tomorrow’s unknown ?
How to structure information security processes in an organization so as to identify and address the NEXT categories of risks ?

To me this is our mandate and measure of effectiveness. Empower our customers, educate, and create business value. If I am a CISO  I don't want 20 people reporting to me who do firewall ruleset changes. I want one champion in 20 different groups - development teams, architects, DBAs, business analysts.

A concrete example, infosec can continue to go along with the herd and follow the "what everyone else is doing architecture" meanwhile developers are connecting every single thing in your business to the Web. I have been doing integration and new technology projects for a long time, and let me tell you - Change does not always create happy customers in the short run. But the chart below shows that information security is maybe more concerned with not causing waves rather than adapting.

The best security program is at the business with sustainable competitive advantage.

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.