Essays: 1998 Archives
1998 was an exciting year to be a cryptographer, considering all the developments in algorithms, attacks and politics. At first glance, the important events of the year seem completely unrelated: done by different people, at different times and for different reasons. But when we step back and reflect on the year-that-was, some common threads emerge -- as do important lessons about the evolution and direction of cryptography.New Algorithms
In June, the NSA declassified KEA and Skipjack.
Key recovery is like trying to fit a square peg into a round hole. No matter how much you finagle it, it's simply not going to work.
In the September issue of Information Security, Commerce Undersecretary William Reinsch suggests that U.S. crypto export policy hinges on the concept of "balance" (Q&A: "Crypto's Key Man").
For key recovery policy to be successful, he argues, it must achieve a balance between privacy and access, between the needs of consumers and the requirements of the law-enforcement community.
For those who have followed the key recovery debate, Reinsch's comments will have a familiar ring.
Today's faster, less expensive computers can crack current encryption algorithms easier than ever before. So what's next?
Cryptographic algorithms have a way of degrading over time. It's a situation that most techies aren't used to: Compression algorithms don't compress less as the years go by, and sorting algorithms don't sort slower.
GCHQ, the British equivalent of the U.S. NSA, released a document on December 1 1997, claiming to have invented publickey cryptography several years before it was discovered by the research community (http://www.cesg.gov.uk/ellisint.htm). According to the paper, GCHQ discovered both RSA and Diffie-Hellman, then kept their discoveries secret.
James Ellis the author of the paper (who died a few days before the paper's release), wrote that he was inspired by an unknown Bell Telephone labs researcher during World War II.
Unlike site-to-site VPNs, where remote offices are hard-wired to a central facility firewall, remote access VPNs are fraught with security problems. Much of the security consists of trusted passwords that traveling workers use on their notebook computers.
To be effective, a VPN's security implementation must be user-friendly while not penalizing your enterprise in other ways, such as by degrading network performance or compromising corporate control of the remote access network.
Think of the lock on the front door of your home.
original en anglais
Des articles de périodiques aiment à décrire les produits de cryptologie en termes d'algorithmes et de longueur de clés. Les algorithmes font de bons titres: ils peuvent être expliqués en quelques mots et ils sont faciles à comparer les uns aux autres. "Le triple-DES gage de bonne sécurité". "Des clés de 40 bits sont une sécurité faible." " Le RSA à 2048 bits est meilleur que le RSA à 1024 bits."
Mais la réalité n'est pas aussi simple.
Magazine articles like to describe cryptography products in terms of algorithms and key length. Algorithms make good sound bites: they can be explained in a few words and they're easy to compare with one another. "128-bit keys mean good security." "Triple-DES means good security." "40-bit keys mean weak security." "2048-bit RSA is better than 1024-bit RSA."
But reality isn't that simple. Longer keys don't always mean more security.
Photo of Bruce Schneier by Per Ervland.
Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Resilient.