RE: Elcomsoft trying to patent faster GPU-based password cracker
I was the person who originated the DES Challenges at RSA, and also helped set up and run them. I knew that there was a stealth effort underway at SGI, but didn't know any of the details. A good deal of cool stuff came out of the contests. Other prior art against this patent would include using the DSP chip in the Amiga graphics set for non-graphics purposes, which was often done back in the 80s. Peter Trei -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Farquhar (ifarquha) Sent: Wednesday, October 24, 2007 7:35 PM To: 'Cryptography' Subject: RE: Elcomsoft trying to patent faster GPU-based password cracker ROTFL. When SGI's stealth DES Challenge project was underway in 1997, it's main client ran on the host's (MIPS) CPU(s), implemented with a variant of Eli Biham's bit-slice DES implementation. The 64-bit 195MHz R1 could do 2.5M keys/sec. I was peripherally involved in the project. One of the things I was looking into was offloading the client into the VICE ASIC on the O2. The VICE ASIC was a compression offload engine, and combined with the MACE ASIC (which had the 3D rendering pipeline), provided graphics support on the O2. At the time, SGI put a workstation on everyone's desk in the company, so there were thousands of O2's around the company. The VICE itself had two CPU's in it, the MSP which was a R4000-derived core with a 128bit vector unit, and the BSP which was a custom little RISC core designed for efficiently slicing non-word-aligned multimedia bit streams. Biham's algorithm would have run beautifully on the VICE. I'd just gotten the devkit when the project came to an end with DESCHALL's successful keyfind. So I'm feeling a little bit of déjà vu about Elcomsoft's patent here. Offloading keyfinding algorithms to a programmable graphics accelerator. Wow, sounds *very* familiar. But alas, probably not sufficient for a prior art claim. Gotta also wonder if the mailing list traffic would still exist in SGI too. Mind you, if the patent system wasn't totally broken, this application would fail the obviousness test anyway. The GPU's mentioned below are basically just optimized little co-processors anyway. How much innovation is there in offloading crypto to a coprocessor? Ian. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, 25 October 2007 3:25 AM To: Cryptography Subject: Elcomsoft trying to patent faster GPU-based password cracker From: http://www.elcomsoft.com/EDPR/gpu_en.pdf Moscow, Russia - October 22, 2007 - ElcomSoft Co. Ltd. has discovered and filed for a US patent...Using the brute force technique of recovering passwords, it was possible, though time-consuming, to recover passwords from popular applications. For example...Windows Vista uses NTLM hashing by default, so using a modern dual-core PC you could test up to 10,000,000 passwords per second, and perform a complete analysis in about two months. With ElcomSoft's new technology, the process would take only three to five days..Today's [GPU] chips can process fixed-point calculations. And with as much as 1.5 Gb of onboard video memory and up to 128 processing units, these powerful GPU chips are much more effective than CPUs in performing many of these calculations...Preliminary tests using Elcomsoft Distributed Password Recovery product to recover Windows NTLM logon passwords show that the recovery speed has increased by a factor of twenty, simply by hooking up with a $150 video card's onboard GPU. -Michael Heyman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: question re practical use of secret sharing
RSA's BSAFE 6.2.1.0 supports Bloom-Shamir secret sharing. Peter Trei Principal Engineer RSA: the Security Division of EMC. Disclaimer: I am not a spokesperson for RSA or EMC. -Original Message- Charles Jackson asks: A quick question. Is anyone aware of a commercial product that implements secret sharing? If so, can I get a pointer to some product literature? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Russian cyberwar against Estonia?
Bill Stewart wrote: At 01:04 PM 5/18/2007, Trei, Peter wrote: If the Russians aren't behind this, who else should be suspected? It isn't like Estonia has a wide selection of enemies. :-) There are three likely suspects - the actual Russian government (or some faction thereof) - Russian Mafia for whatever reasons (might not be distinct from a faction of the government, and usually if the Mafia's involved they're polite enough to send a note demanding money or something.) - Some teenage hacker who got annoyed at some other teenage hacker because they got into an argument on WoW or Myspace and decided to DDOS him (usually attacks like that don't take down much more than a small ISP or a university, but like D00d, you're so 0wn3d, I can take down ur whole *country* :-) The latter isn't as far-fetched as it sounds (well, ok a bit...) This threatens to get off-topic. To drag it back, I'll note that NATO has sent electronic warfare experts to observe and advise, and there is much speculation as to how countries should respond to such cyber attacks - at what point do they become an act of war, and how much certainty of the source must there be to merit a response? I guess its possible this was a random hacker, but the timing seems implausible. Aside from the DDOS attacks, many Estonian websites have been vandalized, and the vandals made it clear the moving of the monument was their motivation. Check out: http://www.economist.com/world/europe/displaystory.cfm?story_id=9163598 In addition, Estonia's embassy in Moscow has been blockaded, Russia has cut off oil and coal shipments, and closed some road and rail links. Putin has described the move as a 'desecration'. This is a major diplomatic feud. In fairness, its worth noting that the issue is also mixed up in Estonian electoral politics: http://news.bbc.co.uk/1/hi/world/europe/6645789.stm The timing of the electronic attacks, and the messages left by vandals, leave little doubt that the 'Bronze Soldier' affair is the motivating factor. Whether Russian Government agents were involved in the attacks is not proven, but certainly seems possible. Peter Trei Disclaimer: My own opinions; not my employers. Full disclosure: My ancestry is half Estonian. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Russian cyberwar against Estonia?
Dave Korn wrote: On 18 May 2007 05:44, Alex Alten wrote: This may be a bit off the crypto topic, You betcha! but it is interesting nonetheless. Russia accused of unleashing cyberwar to disable Estonia http://www.guardian.co.uk/print/0,,329864981-103610,00.html Estonia accuses Russia of 'cyberattack' http://www.csmonitor.com/2007/0517/p99s01-duts.html shrugs Any IP address you find in a packet of a DDoS coming towards you is pretty likely not to be the source of the attack. So far there's no evidence to show anything other than that the russian .gov is just as liable to have virused and botted machines on its internal nets as the US .gov. 1. Do you have any particular evidence that any significant number of US .gov machines are bots? They may well be, just I haven't heard this. 2. If you read the articles, you'll find that there is a lot of circumstancial evidence to support the notion that the attacks are from Russia or Russia-sympathizers. The government recently moved a Soviet war memorial from the center of town out to a military cemetary in the suburbs, an action that Putin condemned as 'desecration', and which led to a fatal riot by ethnic Russians in Tallinn, as well as attacks on the Estonian embassy in Moscow. If the Russians aren't behind this, who else should be suspected? It isn't like Estonia has a wide selection of enemies. :-) Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: padlocks with backdoors - TSA approved
Taral wrote: I'm just waiting for someone with access to photograph said keys and post it all over the internet. Let us hope that happnes - it won't make passenger security worse, and would demonstrate that The Emperor Has No Clothes. Even if that doesn't happen, it is presumabley feasible to reverse-engineer the keys by dismantling the locks. Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
FW: Entropy of other languages
Steven M. Bellovin wrote: On Sun, 04 Feb 2007 15:46:41 -0800 Allen [EMAIL PROTECTED] wrote: Hi gang, An idle question. English has a relatively low entropy as a language. Don't recall the exact figure, but if you look at words that start with q it is very low indeed. What about other languages? Does anyone know the relative entropy of other alphabetic languages? What about the entropy of ideographic languages? Pictographic? Hieroglyphic? It should be pretty easy to do at least some experiments today -- there's a lot of online text in many different languages. Have a look at http://www.gutenberg.org/catalog/ for freely-available books that one could mine for statistics. As a very rough proxy, look at the length of the same text in different translations. My father was in advertising in Europe. When they laid out a print ad, they always did so using the German text. If the German fit, any other language they were interested in would do so as well. Now that I work (among other things) on cellphone applications, I'm running into similar issues in internationalizing text on tiny screens. Peter Trei Disclaimer: This is a personal opinion. It may or may not jibe with my employer's opinion. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Entropy of other languages
Travis H. wrote: On Sun, Feb 04, 2007 at 03:46:41PM -0800, Allen wrote: [...] What about other languages? Does anyone know the relative entropy of other alphabetic languages? What about the entropy of ideographic languages? Pictographic? Hieroglyphic? IIRC, it turned out that Egyptian heiroglyphs were actually syllabic, like Mesopotamian, so no fun there. Mayan, on the other hand, remains an enigma. I read not long ago that they also had a way of recording stories on bundles of knotted string, like the end of a mop. The string-encoding system was Incan, not Mayan. They're called 'quipus', and while they contain a lot of numeric data, its highly debated whether they were a generalized writing system (most experts seem to doubt it). The Maya used an logosyllabic writing system which has been deciphered, most of the progress having been made in the last 25 years or so. Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: SSL Cert Prices Notes
It is with some irony I note that this message from Peter Saint-Andre failed a signature check - startcom isn't among the trusted roots in my copy of Outlook. Peter Trei -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Saint-Andre Sent: Wednesday, August 09, 2006 1:05 AM To: John Gilmore Cc: cryptography@metzdowd.com Subject: Re: SSL Cert Prices Notes [...] Have you looked at StartCom? https://cert.startcom.org/ Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: thoughts on one time pads
You missed the old standby - the microwave oven. The disk remains physically intact (at least after the 5 seconds or so I've tried), but a great deal of pretty arcing occurs in the conductive data layer. Where the arcs travel, the data layer is vapourized. The end result is an otherwise intact disk in which the data layer is broken up into small intact islands surrounded by clear channels. It might be interesting to try a longer burn, in which case you might also want to put a glass of water in with the disk(s) to preserve the microwave's electronics. This is probably less effective than the other methods you've described, but its very fast and leaves no noxious residues. It also uses a very commonly available tool. Peter Trei -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Gutmann Sent: Saturday, January 28, 2006 2:25 AM To: cryptography@metzdowd.com; [EMAIL PROTECTED] Subject: Re: thoughts on one time pads Jonathan Thornburg [EMAIL PROTECTED] writes: Melting the CD should work... but in practice that takes a specialized oven (I seriously doubt my home oven gets hot enough), and is likely to produce toxic fumes, and leave behind a sticky mess (stuck to the surface of the specialized oven). For no adequately explored reason I've tried various ways of physically destroying CDs: - Hammer on hard surface: Leaves lots of little fragments, generally still stuck together by the protective coating. - Roasting over an open fire: Produces a Salvador Dali effect until they catch fire, then huge amounts of toxic smoke (fulfilling our carbon tax quota was one comment) and equally toxic-looking residue. - Propane torch: Melts them without producing combustion products. - Skilsaw: Melts them together at the cutting point, rest undamaged. - Axe: Like skilsaw but without the melting effect. - Using the propane torch and hammer to try and drop-forge a crude double- density CD: Messy. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: long-term GPG signing key
Alexander Klimov wrote:
On Wed, 11 Jan 2006, Ian G wrote:
Even though triple-DES is still considered to have avoided that trap,
its relatively small block size means you can now put the entire
decrypt table on a dvd (or somesuch, I forget the maths).
This would need 8 x 2^{64} bytes of storage which is approximately
2,000,000,000 DVD's (~ 4 x 2^{32} bytes on each).
Probably, you are referring to the fact that during encryption of
a whole DVD, say, in CBC mode two blocks are likely to be the
same since there are an order of 2^{32} x 2^{32} pairs.
I've actually seen something like this happen in real life.
As you know, RSA has been running a series of 'Secret Key
Challenges', wherein we ask people to try to brute-force
messages encrypted with RC5 at various keystrengths. There is
a cash prize for the person turning in the correct response.
The messages are encrypted in CBC mode with 32 bit blocks.
The start of the message has a known plaintext
Most of the recent challenges have been won by distributed.net.
While they were working on the 64 bit challenge, I received an
email saying that a proposed solution had been found, and was asked
to check it. (We set up the challenges in such a way that the
correct keys are unknown, even to us).
The supplied key correctly decrypted the first block, but the
rest were gibberish. After scratching our heads, we realized
that d.net had found a collision.
It was almost a year later they found the correct key, for the
$10,000 prize. They immediately started on the 72 bit challenge.
(I'm not holding my breath).
Peter Trei
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Another entry in the internet security hall of shame....
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Peter Saint-Andre Sent: Wednesday, August 24, 2005 4:56 PM To: cryptography@metzdowd.com Subject: Re: Another entry in the internet security hall of shame Tim Dierks wrote: [resending due to e-mail address / cryptography list membership issue] On 8/24/05, Ian G [EMAIL PROTECTED] wrote: Once you've configured iChat to connect to the Google Talk service, you may receive a warning message that states your username and password will be transferred insecurely. This error message is incorrect; your username and password will be safely transferred. iChat pops up the warning dialog whenever the password is sent to the server, rather than used in a hash-based authentication protocol. However, it warns even if the password is transmitted over an authenticated SSL connection. I'll leave it to you to decide if this is: - an iChat bug - a Google security problem - in need of better documentation - all of the above - none of the above It seems Google is assuming that SASL PLAIN is acceptable once you've completed STARTTLS on port 5222 (or if you've connected via SSL on the old-style port 5223). Decide for yourself if that's secure and whether the iChat warning is justified. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml Ironically, Peter's message above kicked off warning dialogs from MS Outlook, since it was signed using a keypair signed with Peter's own self-signed root, which was not in MSO's list of trusted roots. Self-signed certs are only useful for showing that a given set of messages are from the same source - they don't provide any trustworthy information as to the binding of that source to anything. Peter Trei (not digitally signed, and not pretending to be) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
From [IP] i secure cell phone via software
Interesting encrypted VoIP application for Symbian GSM phones. Peter Trei -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Farber Sent: Monday, April 25, 2005 9:58 AM To: Ip Subject: [IP] i secure cell phone via software http://www.silentel.sk/default.php?lang=2 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
FW: [IP] One cryptographer's perspective on the SHA-1 result
Full disclosure: Burt Kaliski and I share an employer. Peter Trei -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Farber Sent: Wednesday, February 23, 2005 7:48 PM To: Ip Subject: [IP] One cryptographer's perspective on the SHA-1 result From: Kaliski, Burt [EMAIL PROTECTED] Subject: One cryptographer's perspective on the SHA-1 result To: [EMAIL PROTECTED] Date: Wed, 23 Feb 2005 19:43:43 -0500 Hi Dave -- As you might expect, the recent breakthrough on SHA-1 hash was a topic of widespread discussion at the annual RSA Conference last week in San Francisco. Commercial cryptography is one of few fields in IT which has totally absorbed the open review process. We know from experience that an ongoing and aggressive analysis of our current technology, searching out potential weaknesses, is a critical part of the process by which we strengthen it for the future. RSA Laboratories has just posted a brief note on the recent SHA-1 result, to supplement our earlier notes about MD5 and other hashes, at http://www.rsasecurity.com/rsalabs. In my opinion, the latest result on SHA-1 -- once confirmed -- will be one of the most significant results in cryptanalysis in the last decade. Hard work indeed brings a profit, as the proverb says, and the perseverance of Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu appears to have paid off with this unexpected special attack on SHA-1 that can find collisions in less than the promised 2^80 threshold. It is a delight to congratulate the Shandong University team on their achievement, and especially Dr. Yiqun Lisa Yin, for many years my colleague at RSA Laboratories, and one of the co-inventors of RSA Security's RC6 block cipher. This attack seems to have uncovered an unexpected weakness in one of the essential properties of SHA-1, a one-way hash function with a 160-bit output. Essentially, this new research suggests that it is considerably less difficult than expected to create two somewhat different data files that can be reduced and compressed to an identical hash value. Cryptographers call these collisions in hash outputs. A hash function takes a variable-length digital input and coverts it into a fixed-length pseudo-random hash value that can serve as a useful fingerprint for the input file. A one-way hash function like SHA-1 is easy to compute in one direction, but it's very difficult to reconstitute the initial file from the hash value. A good hash function is also expected to be collision-free. That is, it should be hard to generate two input files which, put through the hash function, generate the same hash value. (Hash functions collisions must exist, of course, since the hash inputs can be longer than the outputs -- but the design goal is to make them hard to find in practice.) These attributes have made the one-way hash one of the most useful primitives in modern cryptography. Hash functions are, for example, essential in deriving message authentication codes (MACs) and message digests, the small file that is actually cryptographically signed to create a digital signature for larger files, in a typical public key crypto application. MIT Professor Ron Rivest, one of the founders of RSA Security, created three one-way hashes that were widely used by cryptographers over the past 20 years (MD2, MD4, and MD5), but each of those was eventually deprecated as subtle weaknesses were discovered that suggested that the internal design was less robust than desired against potential future attacks. Any successful attack on SHA-1 based on the new result would still involve a huge amount of computer processing, so this latest research is unlikely (as many have said) to have any significant impact on past or current applications. It is, however, a wake-up call for cryptographers and the industry leaders concerned with the long-term vitality of our technology. The SHA (aka SHA-0) hash function was developed for the US government in 1995 for use within the Digital Signature Standard. Its design was based on MD4. SHA was upgraded to SHA-1 early in its life cycle, apparently to address undisclosed weaknesses discovered by the NSA, and today SHA-1 is the industry standard. It is widely used and has been trusted by both developers and applied crypto engineers, although routine efforts to enhance SHA-1 with longer output values have led to the quiet development of SHA-256, SHA-385, and SHA-512 as design options for long-term applications. Although RSA Security, and most standards organizations, have recommended the use of SHA-1 for several years, Rivest's MD5 is still widely used in many applications despite research in the 1990s that discovered pseudo collisions within the internal operations of MD5. Then, last summer, there were additional results on MD5 that led many cryptographers to urge the abandonment of MD5 for SHA-1, which had withstood a great deal of analysis and was widely believed to be still secure. It is easy to
RSA Conference, and BA Cypherpunks
Once again, the RSA Conference is upon us, and many of the corrospondents on these lists will be in San Francisco. I'd like to see if anyone is interested in getting together. We've done this before. At past conferences, we've had various levels of participation, from 50 down to 3. Since the BAC Physical Meetings seem to have pretty well died out, I'd like to propose that those of us who are interested get together for lunch or dinner at some point. I'll be arriving on site Monday afternoon, and leaving Friday morning. Thursday night, at least, is already spoken for. At the moment, it looks like Monday or Tuesday night may be the best, though a lunch is also possible. Any takers? Peter Trei [EMAIL PROTECTED] RSA Data Security Conference Dates: Feb 14-18 2005 Place: Moscone Center, San Francisco http://www.rsaconference.com While the full conference is rather expensive, note that you can get a free Expo pass if you register online by 5pm Feb 14th. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Dell to Add Security Chip to PCs
Seeing as it comes out of the TCG, this is almost certainly the enabling hardware for Palladium/NGSCB. Its a part of your computer which you may not have full control over. Peter Trei Tyler Durden ANyone familiar with computer architectures and chips able to answer this question: That chip...is it likely to be an ASIC or is there already such a thing as a security network processor? (ie, a cheaper network processor that only handles security apps, etc...) -TD From: R.A. Hettinga [EMAIL PROTECTED] HOUSTON -- Dell Inc. today is expected to add its support to an industry effort to beef up desktop and notebook PC security by installing a dedicated chip that adds security and privacy-specific features, according to people familiar with its plans. Dell will disclose plans to add the security features known as the Trusted Computing Module on all its personal computers. Its support comes in the wake of similar endorsements by PC industry giants Advanced Micro Devices Inc., Hewlett-Packard Co., Intel Corp. and International Business Machines Corp. The technology has been promoted by an industry organization called the Trusted Computing Group. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Banks Test ID Device for Online Security
R.A. Hettinga wrote: Okay. So AOL and Banks are *selling* RSA keys??? Could someone explain this to me? No. Really. I'm serious... Cheers, RAH The slashdot article title is really, really misleading. In both cases, this is SecurID. Peter - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: RSA Implementation in C language
Admittedly somewhat old and creaky, but try Googling RSAREF. I don't know where that stands for IP rights (presumably we still have copyright), bout for research it's a startin point. Peter -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Sandeep N Sent: Monday, November 29, 2004 3:17 AM To: [EMAIL PROTECTED] Subject: RSA Implementation in C language Hi, Can anybody tell me where I can get an implementation of RSA algorithm in C language? I searched for it, but could not locate one. I would be grateful to you if you could give me the location of the source code. Thanks and Regards, Sandeep - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Financial identity is *dangerous*? (was re: Fake companies, real money)
James A. Donald wrote: R.A. Hettinga wrote: [The mobile phone is] certainly getting to be like Chaum's ideal crypto device. You own it, it has its own I/O, and it never leaves your sight. Is there a phone that is programmable enough to store secrets on and sign and decrypt stuff? I've been programming phones and PDAs for several years. They are certainly powerful enough for symmetric operations. Some at the higher end can to public key operations at a reasonable speed. The lower end ones can't. Try taking a look at the new Treos, the newer PocketPC devices, and phones such as the Motorola A760. The ideal crypto device would be programmed by burning new proms, thus enabling easy reprogramming, while making it resistant to trojans and viruses. Some of the devices partition their storage, with portions that are easily modified, and portions which are more secure. The carriers generally want to prevent users from modifying the SW in ways which could enable fraud or damage the network, yet allow downloads of games, apps, etc. Peter - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Financial identity is *dangerous*? (was re: Fake companies, real money)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Aaron Whitehouse Sent: Saturday, October 23, 2004 1:58 AM To: Ian Grigg Cc: [EMAIL PROTECTED] Subject: Re: Financial identity is *dangerous*? (was re: Fake companies, real money) Ian Grigg wrote: James A. Donald wrote: we already have the answer, and have had it for a decade: store it on a trusted machine. Just say no to Windows XP. It's easy, especially when he's storing a bearer bond worth a car. What machine, attached to a network, using a web browser, and sending and receiving mail, would you trust? None. But a machine that had one purpose in life: to manage the bearer bond, that could be trusted to a reasonable degree. The trick is to stop thinking of the machine as a general purpose computer and think of it as a platform for one single application. Then secure that machine/OS/ stack/application combination. Oh, and make it small enough to fit in the pocket, put a display *and* a keypad on it, and tell the user not to lose it. iang How much difference is there, practically, between this and using a smartcard credit card in an external reader with a keypad? Aside from the weight of the 'computer' in your pocket... That would seem to me a more realistic expectation on consumers who are going to have, before too long, credit cards that fit that description and quite possibly the readers to go with them. Aaron If we're going to insist on dedicated, trusted, physical devices for these bearer bonds, then how is this different than what Chaum proposed over 15 years ago? If you just add a requirment for face to face transactions, then I already have one of these - its called a wallet containing cash. Peter - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
DES: Now 'really most sincerely dead'
Back in late 1996, I wrote to Jim Bidzos, proposing an RSA Challenge to break single DES by brute force computation. Later in 1997, the first DES Challenge was successfully completed. Its taken another 7 years, but NIST has finally pulled single DES as a supported mode. Favorite line: DES is now vulnerable to key exhaustion using massive, parallel computations. Triple DES is still a supported mode, as it should be. So, if a product claims to use DES for protection, you can now officially diss them for it. Peter Trei -- http://edocket.access.gpo.gov/2004/04-16894.htm [Federal Register: July 26, 2004 (Volume 69, Number 142)] [Notices] [Page 44509-44510] From the Federal Register Online via GPO Access [wais.access.gpo.gov] [DOCID:fr26jy04-31] --- DEPARTMENT OF COMMERCE National Institute of Standards and Technology [Docket No. 040602169-4169-01] Announcing Proposed Withdrawal of Federal Information Processing Standard (FIPS) for the Data Encryption Standard (DES) and Request for Comments AGENCY: National Institute of Standards and Technology (NIST), Commerce. ACTION: Notice; request for comments. --- SUMMARY: The Data Encryption Standard (DES), currently specified in Federal Information Processing Standard (FIPS) 46-3, was evaluated pursuant to its scheduled review. At the conclusion of this review, NIST determined that the strength of the DES algorithm is no longer sufficient to adequately protect Federal government information. As a result, NIST proposes to withdraw FIPS 46-3, and the associated FIPS 74 and FIPS 81. Future use of DES by Federal agencies is to be permitted only as a component function of the Triple Data Encryption Algorithm (TDEA). TDEA may be used for the protection of Federal information; however, NIST encourages agencies to implement the faster and stronger algorithm specified by FIPS 197, Advanced Encryption Standard (AES) instead. NIST proposes issuing TDEA implementation guidance as a NIST Recommendation via its ``Special Publication'' series (rather than as a FIPS) as Special Publication 800-67, Recommendation for Implementation of the Triple Data Encryption Algorithm (TDEA). DATES: Comments on the proposed withdrawal of DES must be received on or before September 9, 2004. ADDRESSES: Official comments on the proposed withdrawal of DES may either be sent electronically to [EMAIL PROTECTED] or by regular mail to: Chief, Computer Security Division, Information Technology Laboratory, ATTN: Comments on Proposed Withdrawal of DES, 100 Bureau Drive, Stop 8930, National Institute of Standards and Technology, Gaithersburg, MD 20899-8930. FOR FURTHER INFORMATION CONTACT: Mr. William Barker (301) 975-8443, [EMAIL PROTECTED], National Institute of Standards and Technology, 100 Bureau Drive, STOP 8930, Gaithersburg, MD 20899-8930. SUPPLEMENTARY INFORMATION: In 1977, the Federal government determined that, while the DES algorithm was adequate to protect against any practical attack for the anticipated 15-year life of the standard, DES would be reviewed for adequacy every five years. DES is now vulnerable to key exhaustion using massive, parallel computations. The current Data Encryption Standard (FIPS 46-3) still permits the use of DES to protect Federal government information. Since the strength of the original DES algorithm is no longer sufficient to adequately protect Federal government information, it is necessary to withdraw the standard. In addition, NIST proposes the simultaneous withdrawal of FIPS 74, Guidelines for Implementing and Using the NBS Data Encryption Standard and FIPS 81, DES Modes of Operation. FIPS 74 is an implementation guideline specific to the DES. An updated NIST Special Publication 800- 21, Guideline for Implementing Cryptography in the Federal Government, will provide generic implementation and use guidance for NIST-approved block cipher algorithms (e.g., TDEA and AES). Because it is DES- specific, and DES is being withdrawn, the simultaneous withdrawal of FIPS 74 is proposed. FIPS 81 defines four modes of operation for the DES that have been used in a wide variety of applications. The modes specify how data is to be encrypted (cryptographically protected) [[Page 44510]] and decrypted (returned to original form) using DES. The modes included in FIPS 81 are the Electronic Codebook (ECB) mode, the Cipher Block Chaining (CBC) mode, the Cipher Feedback (CFB) mode, and the Output Feedback (OFB) mode. NIST Special Publication 800-38A, Recommendation for Block Cipher Modes of Operation, specifies modes of operation for generic block ciphers. Together with an upcoming message authentication code recommendation, SP 800-38B, SP 800-38A is a functional replacement for FIPS
RE: Satellite eavesdropping of 802.11b traffic
R. A. Hettinga At 12:35 PM -0400 5/27/04, John Kelsey wrote: Does anyone know whether the low-power nature of wireless LANs protects them from eavesdropping by satellite? It seems to me that you'd need a pretty big dish in orbit to get that kind of resolution. The Keyholes(?) are for microwaves, right? Cheers, RAH I don't claim great expertise, but 802.11b/g operates in the microwave range - My home net falls over every time my kid heats up a burrito (It comes right back, though). GSM phones run at a MAX of 0.25 watts (GSM900) or 0.125 watts (GSM1800), but it is normal for the power used to be one hundredth of this maximum or less. However, the base stations are much more powerful - 50 watts. I suspect the spy-from-orbit stuff looks at this, not the phone transmitter. 802.11b/g typically runs around 0.1 watt, and there is no high-power base station. If this is the case, then the power in an 802.11b/g net is 1/500th of that for GSM phones - which seems to fit in with the difference in range. Phones operate with kilometers to the base station, while 802.11b/g is lucky to cover a whole house. A big antenna would obviously be a lot of help, but a smaller one a lot closer would be better. If you insist on listening from orbit, geosync is probably not the way to go - you'd want something like the Iridium constellation of low-orbit sats (600 miles up). Clarke orbit (geosync) is about 35800 km up. You'd get a 10,000 fold advantage by putting your spysats at only 358km. I suspect that eavesdropping on 802.11b/g from orbit is pretty hard. The power levels are very low, and there may be several nets running on the same channel within a satellites' antenna footprint. My summary: Very tough. Probably not impossible. Peter - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: EU seeks quantum cryptography response to Echelon
Tom Shaddack wrote: On Tue, 18 May 2004, Tyler Durden wrote: Monyk believes there will be a global market of several million users once a workable solution has been developed. A political decision will have to be taken as to who those users will be in order to prevent terrorists and criminals from taking advantage of the completely secure communication network, he said. Hope the technology hits the streets fast enough after getting on the market. Monyk apparently doesn't believe that people who don't have the money to buy the Official Approval have no right to access to this technology. Actually, I read this as the sort of puffery we more often see from the snake-oil vendors; Our proprietary Auto Generated One Time Pad (TM) crypto is s strong that the government may ban it - get it while you can! Peter - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: voting
Ed Gerck[SMTP:[EMAIL PROTECTED] John Kelsey wrote: At 11:05 AM 4/9/04 -0400, Trei, Peter wrote: 1. The use of receipts which a voter takes from the voting place to 'verify' that their vote was correctly included in the total opens the way for voter coercion. I think the VoteHere scheme and David Chaum's scheme both claim to solve this problem. The voting machine gives you a receipt that convinces you (based on other information you get) that your vote was counted as cast, but which doesn't leak any information at all about who you voted for to anyone else. Anyone can take that receipt, and prove to themselves that your vote was counted (if it was) or was not counted (if it wasn't). The flaw in *both* cases is that it reduces the level of privacy protection currently provided by paper ballots. Currently, voter privacy is absolute in the US and does not depend even on the will of the courts. For example, there is no way for a judge to assure that a voter under oath is telling the truth about how they voted, or not. This effectively protects the secrecy of the ballot and prevents coercion and intimidation in all cases. I'd pretty much dropped this topic after it became clear that Mr. Leichter's only response to the problems that people pointed out in VoteHere's scheme (in particular, its vulnerability to vote coercion, and lack of recountability) was to attempt to redefine them as non-problems. However, since the topic has arisen again. Ed's got a very good point. I always prefer security which relies for its integrity on the laws of nature, rather than on people behaving with integrity. Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: voting
privacy wrote: [good points about weaknesses in adversarial system deleted] It's baffling that security experts today are clinging to the outmoded and insecure paper voting systems of the past, where evidence of fraud, error and incompetence is overwhelming. Cryptographic voting protocols have been in development for 20 years, and there are dozens of proposals in the literature with various characteristics in terms of scalability, security and privacy. The votehere.net scheme uses advanced cryptographic techniques including zero knowledge proofs and verifiable remixing, the same method that might be used in next generation anonymous remailers. Our anonymous corrospondent has not addressed the issues I raised in my initial post on the 7th: 1. The use of receipts which a voter takes from the voting place to 'verify' that their vote was correctly included in the total opens the way for voter coercion. 2. The proposed fix - a blizzard of decoy receipts - makes recounts based on the receipts impossible. Given that so many jurisdictions are moving towards electronic voting machines, this is a perfect opportunity to introduce mathematical protections instead of relying so heavily on human beings. I would encourage observers on these lists to familiarize themselves with the cryptographic literature and the heavily technical protocol details at http://www.votehere.com/documents.html before passing judgement on these technologies. Asking the readers of this list to 'familiarize themselves with the cryptographic literature', is, in many cases, a little like telling Tiger Woods that he needs to familiarize himself with the rules of golf. We know the 'advanced cryptographic techniques' you refer to. We also know what their limitations - what they can and cannot do. This is not the appropriate forum to try to say trust me. Answer this: 1. How does this system prevent voter coercion, while still allowing receipt based recounts? Or do you have some mechanism by which I can personally verify every vote which went into the total, to make sure they are correct? 2. On what basis do you think the average voter should trust this system, seeing as it's based on mechanisms he or she cant personally verify? 3. What chain of events do I have to beleive to trust that the code which is running in the machine is actually and correctly derived from the source code I've audited? I refer you to Ken Thompsons classic paper Reflections on trusting trust, as well as the recent Diebold debacle with uncertified patches being loaded into the machine at the last moment. This last is an important point - there is no way you can eliminate the requirement of election officials to behave legitimately. Since that requirement can't be done away with by technology, adding technology only adds more places the system can be compromised. Based on the tone of this letter, I'd hazard a guess that 'privacy' has a vested interest in VoteHere. If this true, it's a little odd that they are willing to expose their source code, but not their name. We don't bite, unless the victim deserves it :-) Opening your source is an admirable first step - why not step out of the shadows so we can help you make your system better? I fear a system which does not have a backup mechanism that the average voter can understand. While it's true that non-electronic systems are subject to compromise, so are electronic ones, regardless of their use of ZK proofs, or 'advanced cryptographic techniques. I do think electronic voting machines are coming, and a good thing. But they should be promoted on the basis that they are easier to use, and fairer in presentation, then are manual methods. Promoting them on the basis that they are more secure, and less subject to vote tampering is simply false. Peter Trei Cryptoengineer RSA Security Disclaimer: The above represents my personal opinions only. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Firm invites experts to punch holes in ballot software
Firm invites experts to punch holes in ballot software The company's software is designed to let voters verify that their ballots were properly handled. It assigns random identification numbers to ballots and candidates. After people vote, they get a receipt that shows which candidates they chose--listed as numbers, not names. Voters can then use the Internet and their ballot identification number to check that their votes were correctly counted. This is kind of broken. Allowing the voter to get a receipt which they take away with them for verification may allow the voter to verify that their vote was recorded as cast, but also allows coercion and vote buying. To their credit, the creators thought of this, and suggest a partial procedural fix in the threat analysis document: P4. Let voters discard verification receipts in poll site trash can and let any voter take them Result: Buyer/coercer can't be sure voter generated verification receipt P5. Have stacks of random printed codebooks freely available in poll site Result: Vote buyer/coercer can't be sure captured codebook was used P6. Have photos of on-screen codebooks freely available on-line Result: Vote buyer/coercer can't be sure captured codebook was used The first problem, or course, is that a person under threat of coercion will need to present the coercer with a receipt showing exactly the mix of votes the coercer required. This is leads to a combinatorial explosion of fake receipts that need to be available. Having only one vote on each receipt might mitigate this, but it still gets really messy. Second, it's not clear how this protects against the coercer checking the ballot online - will every fake also be recorded in the system, so it passes the online check? Having both real and fake ballots in the verification server makes me very nervous. Its possible I've missed something - this is based on a quick glance through the online documents, but I don't see any advantage this system has over the much more discussed one where the reciept is printed in a human readable way, shown to the voter, but retained inside the machine as a backup for recounts. Just my private, personal opinion. Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Firm invites experts to punch holes in ballot software
Ian Grigg[SMTP:[EMAIL PROTECTED] wrote: Trei, Peter wrote: Frankly, the whole online-verification step seems like an unneccesary complication. It seems to me that the requirement for after-the-vote verification (to prove your vote was counted) clashes rather directly with the requirement to protect voters from coercion (I can't prove I voted in a particular way.) or other incentives-based attacks. You can have one, or the other, but not both, right? It would seem that the former must give way to the latter, at least in political voting. I.e., no verification after the vote. iang Yes, that seems to be the case. Note that in the current (non computer) systems, we have no way to assure that our votes actually contributed to the total, but the procedural stuff of having mutually hostile observers to the counting process makes deliberate discarding of one side's votes less likely. (Non-deliberate losses - such as the recent failure to record cards marked with the wrong kind of pen - can still happen). VoteHere, while they seem to be well-meaning, have not solved the problem. Mercuri Rivest have described how to do it right; we just need someone to buld or retrofit the machines appropriately. Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Code breakers crack GSM cellphone encryption
David Honig[SMTP:[EMAIL PROTECTED] wrote: At 02:37 AM 9/9/03 +1000, Greg Rose wrote: At 05:18 PM 9/7/2003 -0700, David Honig wrote: Laughing my ass off. Since when do governments care about patents? How would this help/harm them from exploiting it? Not that high-end LEOs haven't already had this capacity ---Biham et al are only the first *open* researchers to reveal this. Actually, patenting the method isn't nearly as silly as it sounds. Produced in quantity, a device to break GSM using this attack is not going to cost much more than a cellphone (without subsidies). Patenting the attack prevents the production of the radio shack (tm) gsm scanner, so that it at least requires serious attackers, not idle retirees or jealous teenagers. Why the heck would a government agency have to break the GSM encryption at all? The encryption is only on the airlink, and all GSM calls travel through the POTS land line system in the clear, where they are subject to warranted wiretaps. Breaking GSM is only of useful if you have no access to the landline portion of the system. Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
