Re: IBM's original S-Boxes for DES?
In message [EMAIL PROTECTED], Nicolai Moles -Benfell writes: Hi, A number of sources state that the NSA changed the S-Boxes (and reduced the ke y size) of IBM's original DES submission, and that these change were made to strengthen the cipher against differential/linear/?? cryptanalysis. Does anybody have a reference to, or have an electronic copy of these original S-Boxes? It was only to protect against differential cryptanalysis; they did not know about linear cryptanalysis. See Don Coppersmith, The Data Encryption Standard (DES) and its strength against attacks, IBM Journal of Research and Development, Vol. 38, n. 3, pp. 243-250, May 1994. --Steve Bellovin, http://www.research.att.com/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
QC Hype Watch: Quantum cryptography gets practical
http://www.computerworld.com/printthis/2004/0,4814,96111,00.html - Computerworld Quantum cryptography gets practical Opinion by Bob Gelfond, MagiQ Technologies Inc. SEPTEMBER 30, 2004 (COMPUTERWORLD) - In theory and in labs, quantum cryptography -- cryptography based on the laws of physics rather than traditional, computational difficulty -- has been around for years. Advancements in science and in the world's telecommunications infrastructure, however, have led to the commercialization of this technology and its practical application in industries where high-value assets must be secure. Protecting information today usually involves the use of a cryptographic protocol where sensitive information is encrypted into a form that would be unreadable by anyone without a key. For this system to work effectively, the key must be absolutely random and kept secret from everyone except the communicating parties. It must also be refreshed regularly to keep the communications channel safe. The challenge resides in the techniques used for the encryption and distribution of this key to its intended parties to avoid any interception of the key or any eavesdropping by a third party. Many organizations are advancing quantum technology and bringing it outside academia. Research labs, private companies, international alliances such as the European Union and agencies such as the Defense Advanced Research Projects Agency are investing tens of millions of dollars in quantum research, with projects specifically focused on the challenge of key distribution. The trouble with key distribution Huge investment in the late 1990s through 2001 created a vast telecommunications infrastructure resulting in millions of miles of optical fiber laid across the country and throughout buildings to enable high-speed communications. This revolution combined a heavy reliance on fiber-optic infrastructure with the use of open network protocols such as Ethernet and IP to help systems communicate. Although this investment delivers increased productivity, dependence on optical fiber compounds key distribution challenges because of the relative ease with which optical taps can be used. With thousands of photons representing each bit of data traveling over fiber, nonintrusive, low-cost optical taps placed anywhere along the fiber can siphon off enough data without degrading the signal to cause a security breach. The threat profile is particularly high where clusters of telecommunications gear are found in closets, the basements of parking garages or central offices. Data can be tapped through monitoring jacks on this equipment with inexpensive handheld devices. This enables data to be compromised without eavesdroppers disclosing themselves to the communicating parties. Another important aspect of this problem is the refresh rate of the keys. Taking large systems off-line to refresh keys can cause considerable headaches, such as halting business operations and creating other security threats. Therefore, many traditional key-distribution systems refresh keys less than once per year. Infrequent key refreshing is detrimental to the security of a system because it makes brute-force attacks much easier and can thereby provide an eavesdropper with full access to encrypted information until the compromised key is refreshed. Adding quantum physics to the key distribution equation Companies are now in a position to use advancements in quantum cryptography, such as quantum key distribution (QKD) systems, to secure their most valued information. Two factors have made this possible: the vast stretches of optical fiber (lit and dark) laid in metropolitan areas, and the decreasing cost in recent years of components necessary for producing QKD systems as a result of the over-investment in telecommunications during the early 2000s. Based on the laws of quantum mechanics, the keys generated and disseminated using QKD systems have proved to be absolutely random and secure. Keys are encoded on a photon-by-photon basis, and quantum mechanics guarantees that the act of an eavesdropper intercepting a photon will irretrievably change the information encoded on that photon. Therefore, the eavesdropper can't copy or read the photon -- or the information encoded on it -- without modifying it, which makes it possible to detect the security breach. In addition to mitigating the threat of optical taps, QKD systems are able to refresh keys at a rate of up to 10 times per second, further increasing the level of security of the encrypted data. Not for everyone Quantum key distribution systems aren't intended for everyday use: You won't find a QKD system in the home office anytime soon. One reason is that a QKD system requires a dedicated fiber-optic line. Also, because the loss of photons over longer distances, these systems have current distance limitations of approximately 120 kilometers (nearly 75 miles) which is common with optical
Re: Linux-based wireless mesh suite adds crypto engine support
- sufficient documentation and really transparent provable details so that users could trust and verify that the hardware and software were doing what they claimed to be doing and weren't doing anything evil that they didn't admit to, such as including backdoors or bad random number generators. Tinfoil hat stuff - why trust any crypto hardware then? I don't -- do you? Crypto hardware that does algorithms can be tested by periodically comparing its results to a software implementation. Production applications should probably be doing this -- maybe 1% of the time. Crypto hardware that generates random numbers can't be tested in production in many useful ways. My suggestion would be to XOR a hardware-generated and a software-generated random number stream. If one fails, whether by accident, malice, or design, the other will still randomize the resulting stream. Belt AND suspenders will keep your source of randomness from being your weakest link. John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Linux-based wireless mesh suite adds crypto engine support
Peter Gutmann wrote: Tinfoil-hat mode. Agreed, but some people want to be thorough, or pedantic, or paranoid. At 04:20 AM 9/30/2004, Jonathan Thornburg wrote: UNDOCUMENTED_EVIL_WIRETAP_MODE can be just about impossible to spot without full design oversight. Even for a 3DES chip, where supposedly you can use deterministic test vectors to verify things, the following scheme due to Henry Spencer embeds an almost-impossible-to-spot-in-practice backdoor: A somewhat simpler backdoor could be used in block chaining modes. Occasionally output the data you're leaking instead of one or a few blocks of cyphertext, and the CBC will glitch on it and then resync a few blocks later; in many environments the application layer will correct for it, e.g. IPSEC will lose a few packets, TCP will timeout and retransmit, and 3 seconds later it's as if nothing happened except that the private keypart has been leaked for the passive eavesdropper. Bill Stewart [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
CFP: Privacy Enhancing Technologies (PET 2005)
--- begin forwarded text To: sec-lists: ; Cc: [EMAIL PROTECTED] Subject: CFP: Privacy Enhancing Technologies (PET 2005) From: George Danezis [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] List-Id: Open NymIP-RG discussion list nymip-rg-interest.nymip.org List-Post: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: http://www.nymip.org/mailman/listinfo/nymip-rg-interest, mailto:[EMAIL PROTECTED] List-Archive: http://www.nymip.org/pipermail/nymip-rg-interest/ Date: Mon, 27 Sep 2004 13:11:22 +0100 5th Workshop on Privacy Enhancing Technologies Dubrovnik, CroatiaMay 30 - June 1, 2005 C A L L F O R P A P E R S http://petworkshop.org/2005/ Important Dates: Paper submission: February 7, 2005 Notification of acceptance: April 4, 2005 Camera-ready copy for preproceedings: May 6, 2005 Camera-ready copy for proceedings: July 1, 2005 Award for Outstanding Research in Privacy Enhancing Technologies Nomination period: March 4, 2004 through March 7, 2005 Nomination instructions: http://petworkshop.org/award/ --- Privacy and anonymity are increasingly important in the online world. Corporations, governments, and other organizations are realizing and exploiting their power to track users and their behavior, and restrict the ability to publish or retrieve documents. Approaches to protecting individuals, groups, but also companies and governments from such profiling and censorship include decentralization, encryption, distributed trust, and automated policy disclosure. This 5th workshop addresses the design and realization of such privacy and anti-censorship services for the Internet and other communication networks by bringing together anonymity and privacy experts from around the world to discuss recent advances and new perspectives. The workshop seeks submissions from academia and industry presenting novel research on all theoretical and practical aspects of privacy technologies, as well as experimental studies of fielded systems. We encourage submissions from other communities such as law and business that present their perspectives on technological issues. As in past years, we will publish proceedings after the workshop in the Springer Lecture Notes in Computer Science series. Suggested topics include but are not restricted to: * Anonymous communications and publishing systems * Censorship resistance * Pseudonyms, identity management, linkability, and reputation * Data protection technologies * Location privacy * Policy, law, and human rights relating to privacy * Privacy and anonymity in peer-to-peer architectures * Economics of privacy * Fielded systems and techniques for enhancing privacy in existing systems * Protocols that preserve anonymity/privacy * Privacy-enhanced access control or authentication/certification * Anonymous credentials * Election schemes * Privacy threat models * Models for anonymity and unobservability * Attacks on anonymity systems * Traffic analysis * Profiling and data mining * Privacy vulnerabilities and their impact on phishing and identity theft * Deployment models for privacy infrastructures * Novel relations of payment mechanisms and anonymity * Usability issues and user interfaces for PETs * Reliability, robustness and abuse prevention in privacy systems Stipends to attend the workshop will be made available, on the basis of need, to cover travel expenses, hotel, or conference fees. You do not need to submit a technical paper and you do not need to be a student to apply for a stipend. For more information, see http://petworkshop.org/2005/stipends.html General Chair: Damir Gojmerac ([EMAIL PROTECTED]), Fina Corporation, Croatia Program Chairs: George Danezis ([EMAIL PROTECTED]), University of Cambridge, UK David Martin ([EMAIL PROTECTED]), University of Massachusetts at Lowell, USA Program Committee: Martin Abadi, University of California at Santa Cruz, USA Alessandro Acquisti, Heinz School, Carnegie Mellon University, USA Caspar Bowden, Microsoft EMEA, UK Jean Camp, Indiana University at Bloomington, USA Richard Clayton, University of Cambridge, UK Lorrie Cranor, School of Computer Science, Carnegie Mellon University, USA Roger Dingledine, The Free Haven Project, USA Hannes Federrath, University of Regensburg, Germany Ian Goldberg, Zero Knowledge Systems, Canada Philippe Golle, Palo Alto Research Center, USA Marit Hansen, Independent Centre for Privacy Protection Schleswig-Holstein, Germany Markus Jakobsson, Indiana University at Bloomington, USA Dogan Kesdogan, Rheinisch-Westfaelische Technische Hochschule Aachen, Germany Brian Levine, University of Massachusetts at Amherst, USA Andreas Pfitzmann, Dresden University of Technology, Germany Matthias Schunter, IBM Zurich Research Lab, Switzerland Andrei Serjantov, University of Cambridge, England Paul Syverson, Naval Research Lab, USA Latanya Sweeney, Carnegie Mellon University, USA Matthew Wright,
Tor 0.0.9pre1 is out (fwd from [EMAIL PROTECTED])
--- begin forwarded text Date: Fri, 1 Oct 2004 10:46:39 +0200 From: Eugen Leitl [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Tor 0.0.9pre1 is out (fwd from [EMAIL PROTECTED]) User-Agent: Mutt/1.4i Sender: [EMAIL PROTECTED] From: Roger Dingledine [EMAIL PROTECTED] Subject: Tor 0.0.9pre1 is out To: [EMAIL PROTECTED] Date: Fri, 1 Oct 2004 03:19:44 -0400 Reply-To: [EMAIL PROTECTED] We've fixed quite a few bugs. We've also added compression for directories, and client-side directory caching on disk so you'll have a directory when Tor restarts. tarball: http://freehaven.net/tor/dist/tor-0.0.9pre1.tar.gz signature: http://freehaven.net/tor/dist/tor-0.0.9pre1.tar.gz.asc (use -dPr tor-0_0_9pre1 if you want to check out from cvs) Changes from 0.0.8: o Bugfixes: - Stop using separate defaults for no-config-file and empty-config-file. Now you have to explicitly turn off SocksPort, if you don't want it open. - Fix a bug in OutboundBindAddress so it (hopefully) works. - Improve man page to mention more of the 0.0.8 features. - Fix a rare seg fault for people running hidden services on intermittent connections. - Change our file IO stuff (especially wrt OpenSSL) so win32 is happier. - Fix more dns related bugs: send back resolve_failed and end cells more reliably when the resolve fails, rather than closing the circuit and then trying to send the cell. Also attach dummy resolve connections to a circuit *before* calling dns_resolve(), to fix a bug where cached answers would never be sent in RESOLVED cells. - When we run out of disk space, or other log writing error, don't crash. Just stop logging to that log and continue. - We were starting to daemonize before we opened our logs, so if there were any problems opening logs, we would complain to stderr, which wouldn't work, and then mysteriously exit. - Fix a rare bug where sometimes a verified OR would connect to us before he'd uploaded his descriptor, which would cause us to assign conn-nickname as though he's unverified. Now we look through the fingerprint list to see if he's there. - Fix a rare assert trigger, where routerinfos for entries in our cpath would expire while we're building the path. o Features: - Clients can ask dirservers for /dir.z to get a compressed version of the directory. Only works for servers running 0.0.9, of course. - Make clients cache directories and use them to seed their router lists at startup. This means clients have a datadir again. - Configuration infrastructure support for warning on obsolete options. - Respond to content-encoding headers by trying to uncompress as appropriate. - Reply with a deflated directory when a client asks for dir.z. We could use allow-encodings instead, but allow-encodings isn't specified in HTTP 1.0. - Raise the max dns workers from 50 to 100. - Discourage people from setting their dirfetchpostperiod more often than once per minute - Protect dirservers from overzealous descriptor uploading -- wait 10 seconds after directory gets dirty, before regenerating. -- -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature] --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
'Frustrated' U.S. Cybersecurity Chief Abruptly Resigns
http://www.local6.com/print/3776699/detail.html?use=print local6.com 'Frustrated' U.S. Cybersecurity Chief Abruptly Resigns POSTED: 11:32 AM EDT October 1, 2004 WASHINGTON -- The government's cybersecurity chief has abruptly resigned after one year with the Department of Homeland Security, confiding to industry colleagues his frustration over what he considers a lack of attention paid to computer security issues within the agency. Amit Yoran, a former software executive from Symantec Corp., informed the White House about his plans to quit as director of the National Cyber Security Division and made his resignation effective at the end of Thursday, effectively giving a single's day notice of his intentions to leave. Yoran said Friday he felt the timing was right to pursue other opportunities. It was unclear immediately who might succeed him even temporarily. Yoran's deputy is Donald Andy Purdy, a former senior adviser to the White House on cybersecurity issues. Yoran has privately described frustrations in recent months to colleagues in the technology industry, according to lobbyists who recounted these conversations on condition they not be identified because the talks were personal. As cybersecurity chief, Yoran and his division - with an $80 million budget and 60 employees - were responsible for carrying out dozens of recommendations in the Bush administration's National Strategy to Secure Cyberspace, a set of proposals to better protect computer networks. Yoran's position as a director -- at least three steps beneath Homeland Security Secretary Tom Ridge -- has irritated the technology industry and even some lawmakers. They have pressed unsuccessfully in recent months to elevate Yoran's role to that of an assistant secretary, which could mean broader authority and more money for cybersecurity issues. Amit's decision to step down is unfortunate and certainly will set back efforts until more leadership is demonstrated by the Department of Homeland Security to solve this problem, said Paul Kurtz, a former cybersecurity official on the White House National Security Council and now head of the Washington-based Cyber Security Industry Alliance, a trade group. Under Yoran, Homeland Security established an ambitious new cyber alert system, which sends urgent e-mails to subscribers about major virus outbreaks and other Internet attacks as they occur, along with detailed instructions to help computer users protect themselves. It also mapped the government's universe of connected electronic devices, the first step toward scanning them systematically for weaknesses that could be exploited by hackers or foreign governments. And it began routinely identifying U.S. computers and networks that were victims of break-ins. Yoran effectively replaced a position once held by Richard Clarke, a special adviser to President Bush, and Howard Schmidt, who succeeded Clarke but left government during the formation of the Department of Homeland Security to work as chief security officer at eBay Inc. Yoran cofounded Riptech Inc. of Alexandria, Va., in March 1998, which monitored government and corporate computers around the world with an elaborate sensor network to protect against attacks. He sold the firm in July 2002 to Symantec for $145 million and stayed on as vice president for managed security services. -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Reverse DMCA: Copyright Holder Held Liable in Landmark Legal Ruling
http://www.linuxelectrons.com/article.php/20040930201813382 LinuxElectrons - Reverse DMCA: Copyright Holder Held Liable in Landmark Legal Ruling Thursday, September 30 2004 @ 08:18 PM Contributed by: ByteEnable In a landmark case, a California district court has determined that Diebold, Inc., a manufacturer of electronic voting machines, knowingly misrepresented that online commentators, including IndyMedia and two Swarthmore college students, had infringed the company's copyrights. This makes the company the first to be held liable for violating section 512(f) of the Digital Millennium Copyright Act (DMCA), which makes it unlawful to use DMCA takedown threats when the copyright holder knows that infringement has not actually occured. The Electronic Frontier Foundation (EFF) and the Center for Internet and Society Cyberlaw Clinic at Stanford Law School sued on behalf of nonprofit Internet Service Provider (ISP) Online Policy Group (OPG) and the two students to prevent Diebold's abusive copyright claims from silencing public debate about voting. Diebold sent dozens of cease-and-desist letters to ISPs hosting leaked internal documents revealing flaws in Diebold's e-voting machines. The company claimed copyright violations and used the DMCA to demand that the documents be taken down. One ISP, OPG, refused to remove them in the name of free speech, and thus became the first ISP to test whether it would be held liable for the actions of its users in such a situation. This decision is a victory for free speech and for transparency in discussions of electronic voting technology, said Wendy Seltzer, an EFF staff attorney who worked on the case. Judge Fogel recognized the fair use of copyrighted materials in critical discussion and gave speakers a remedy when their speech is chilled by improper claims of copyright infringement. OPG Executive Director Will Doherty said, This ruling means that we have legal recourse to protect ourselves and our clients when we are sent misleading or abusive takedown notices. In his decision, Judge Jeremy Fogel wrote, No reasonable copyright holder could have believed that the portions of the email archive discussing possible technical problems with Diebold's voting machines were proteced by copyright . . . the Court concludes as a matter of law that Diebold knowingly materially misrepresented that Plaintiffs infringed Diebold's copyright interest. -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
NIST on TLS
Found via the RSS feed for cryptome.org: http://csrc.nist.gov/publications/drafts.html#sp800-52 NIST is pleased to announce the first public draft of Special Publication 800-52, Guidelines on the Selection and Use of Transport Layer Security. This document is a guideline for implementing Transport Layer Security in the Federal Government to protect sensitive information. Care must be taken when selecting cryptographic mechanisms for authentication, confidentiality, and message integrity, as some choices are non-compliant with Government standards, or may pose security risks. The comment period for this document will be 30 days, ending on November 1st, 2004. Please direct all comments and questions to Matthew J. Fanto at [EMAIL PROTECTED] -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
A Proposed Nomenclature for the Four Horseman of The Infocalypse
I've been talking about this for the last decade, and never found a reference on the web whenever I was thinking about it. Thanks to Google, it was well within my prodigiously diminished attention span this morning. Given the events on the net over the past few years, I figure we might as well have fun with the idea. Humor is good leverage, and these days we need *lots* of leverage. In arbitrary order (in other words, *I* chose it. :-)), and with apologies to Toru Iwatani, by way of Michael Thomasson at http://www.gooddealgames.com/articles/Pac-Man%20Ghosts.html, here it is: A Proposed Nomenclature for the Four Horseman of The Infocalypse Horseman Color Character Nickname 1 TerrorismRedShadow Blinky 2 NarcoticsPink Speedy Pinky 3 Money Laundering Aqua Bashful Inky 4 Paedophilia Yellow Pokey Clyde It is acceptable to refer to a horseman by any of the above, i.e., Horseman No. 1, The Red Horseman, Shadow, or Blinky. Apparently there was a, um, pre-deceased, dark-blue ghost, used in Japanese tournament play, named Kinky, I leave that particular horseman for quibblers. Cheers, RAH -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: IBM's original S-Boxes for DES?
In a personal interview with Walt Tuchman (IBM at the time, worked for StorageTek when I met him, now retired) he described the process for creating the s-boxes. A set of mathematical requirements were created and candidate s-boxes meeting these requirements would be printed out on a regular basis. The process ran over a weekend on a 360/195 and the results were given to the ASIC developers to determine which would result in the smallest ASIC size. One was selected by them. I was told that after the requirements were set, NSA did not have a hand in selecting the final S-Boxes. jim http://www.stortek.com/hughes On Sep 30, 2004, at 12:25 PM, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Nicolai Moles -Benfell writes: Hi, A number of sources state that the NSA changed the S-Boxes (and reduced the ke y size) of IBM's original DES submission, and that these change were made to strengthen the cipher against differential/linear/?? cryptanalysis. Does anybody have a reference to, or have an electronic copy of these original S-Boxes? It was only to protect against differential cryptanalysis; they did not know about linear cryptanalysis. See Don Coppersmith, The Data Encryption Standard (DES) and its strength against attacks, IBM Journal of Research and Development, Vol. 38, n. 3, pp. 243-250, May 1994. --Steve Bellovin, http://www.research.att.com/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
