IEEE 1667 approved
Forwarded message: From: Jack Cole [EMAIL PROTECTED] Subject: IEEE 1667 Approved December 5, 2006 Date: Wed, 24 Jan 2007 13:57:15 -0500 Reply-To: Jack Cole [EMAIL PROTECTED] IEEE Press Release at http://standards.ieee.org/announcements/pr_IEEE1667_new.html IEEE 1667, Standard Protocol for Authentication in Host Attachments of Transient Storage Devices, was approved December 5, 2006. Transiently-connected storage devices include devices in wide use such as USB flash drives, mobile phones, PDAs, and mp3 players. This standard impacts secure uses of such devices in, for example, important economic areas employing mobile phones for ordinary commercial transactions, now common in Asian and European countries. IEEE 1667 is sponsored by the Computer Society with the Information Assurance Standards Committee (IASC) leading a joint project with the Storage Systems Standards Committee (SSSC) and supported by the Task Force on Information Assurance (TFIA) and the Mass Storage Systems Technical Committee (MSSTC). This is the first Information Assurance standard to be published by the IEEE, and is one of several projects being developed through the combined efforts and support of IEEE Computer Society standards and technical committees with expertise in complementary information technology areas. Jack Cole Chair, Information Assurance Standards Committee Please forgive receipt of duplicates. Multiple lists with overlapping subscriptions were used. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: more on NIST hash competition
At 8:22 PM -0500 1/23/07, Ivan Krstiç wrote: Perry E. Metzger wrote: http://www.csrc.nist.gov/pki/HashWorkshop/index.html I'm completely unfamiliar with the way NIST operates, but I've been wondering for years why they haven't organized this competition already. Do we have a list veteran who can shed some light on why it took them this long? My curiosity demands to know. At the Second Hash Workshop this summer, NIST explained this a bit. (There were a bunch of regulars from this list there who can correct me if I'm wrong.) First, there is SHA-2 (SHA-256, -384, and -512). Nearly everyone thinks they are good enough unless there is an unexpected attack. So NIST was not hot to create something that competes with this. More important, however, is the lack of sureness in the community that we know what will make a good hash function, much less one that is better than SHA-2. See http://www.proper.com/lookit/hash-futures-panel-notes.html for much more on that. Also, remember that we don't know much about the design of SHA-2. In fact, unless the NSA tells the world a whole lot more, it will not be able to compete in the NIST competition due to requirement B1 in the proposal. At the end of the workshop, there were at least two camps: those who wanted a competition in case Wang-esque attacks degrade SHA-2, and those who didn't want a competition until we knew more about how to judge it because we don't know enough now. Some of the Big Names In Crypto are in the second group. It looks like NIST sided with the first group, but it will be interesting if the folks in the second group are vocal during the coming few years. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Free WiFi man-in-the-middle scam seen in the wild.
-- Perry E. Metzger wrote: It used to be that Verizon (my local phone company, sadly) had this general problem but you could click on log in and it would direct you to a secure page with a little error message and you could then enter your username and password. They've since fixed that so it is no longer possible to log in safely to their web site at all. The reason we cannot sell, nor profitably implement, usable and effective security is, as Ian Grigg says in the market for silver bullets, that neither buyers nor sellers can tell the difference between security that works, and security that does not work, even though you and I can tell the difference. The most recent illustration of this is the reaction to the recent AACS content protection hack. http://msmvps.com/blogs/chrisl/archive/2007/01/02/46398 0.aspx Cyberlink says its DRM code is working fine, because it does what it designed to do - but unfortunately the design prevents legitimate purchasers from playing legitimately purchased content on legitimately purchased machines, and fails to prevent people from ripping the content and sharing it through bittorrent. Cyberlink's statement echoes the statement made by earlier by many on this list and related lists that PKI fulfills its specification just fine. The DRM people wanted something that could not be done, so unsurprisingly they winded up buying something that does not do it. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG LjC3cY1UO0v0xXean2TJqxn0Dh1vSubg/F00KDsX 48fF+ZilNMNu1rtIcc2XhJ0zksmqpjzsHEJz9pGDj - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OT: SSL certificate chain problems
Am Dienstag, den 23.01.2007, 20:47 -0600 schrieb Travis H.: Verify return code: 21 (unable to verify the first certificate) --- DONE I can't seem to get that certificate chain to have any contents other than what you see above, no matter what I do, and hence can't get rid of the Verify return code: 21... does anyone have any advice on what to do next? URLs or references to other mailing lists welcome. Did you try -CAfile, with this command you can give s_client a file with CAs you trust. If the Thawte Consulting certificate is in this file, you should have no problems with verifying. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: OT: SSL certificate chain problems
Hi, you should provide the whole chain starting from the CA that issued the server cert. Be careful, though, because you should *NOT* provide the root cert in the chain as well. Moreover you should use the: SSLCertificateChainFile not the SSLCACertificateFile (which is for client auth). Cheers, Max. Travis H. wrote: Hi, This is not really typical of the traffic on this list, hence the OT. I send it because I think this is one of the few places where I'll find some people with deep understanding of SSL certs. Recently I had an issue where Google checkout would not accept an SSL certificate because Apache didn't present the entire hierarchy, just the site certificate itself. The CA was Thawte. What Google said was that many browsers supply missing certs as needed, but apparently their software did not. The fix would seem to be easy; just put the right CA root cert in the SSLCACertFile directive. or point to the directory with SSLCACertPath. However, I've tried over and over with various root CA certs downloaded from Thawte, and with one intermediate CA cert, and various combinations thereof, but with no sucess. -- Best Regards, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager][EMAIL PROTECTED] [EMAIL PROTECTED] Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883 PKI/Trust - Office 063Work Phone: +1 (603) 646-9179 --o smime.p7s Description: S/MIME Cryptographic Signature
Re: analysis and implementation of LRW
David Wagner wrote: [snip] Another possible interpretation of (2) is that if you use LRW to encrypt close to 2^64 blocks of plaintext, and if you are using a 128-bit block cipher, then you have a significant chance of a birthday collision, Am I doing the math correctly that 2^64 blocks of 128 bits is 2^32 bytes or about 4 gigs of data? Or am I looking at this the wrong way? If 4 gigs is right, would it then be records to look for to break the code via birthday attacks would be things like seismic data, which tend to be very large. Feed a known file in and look at the output and use that to find the key for the unknown files? As you can tell, my interests are often the vectors, not the exact details of how to achieve the crack. Currently I'm dealing with very large - though not as large as 4 gig - x-ray, MRI, and similar files that have to be protected for the lifespan of the person, which could be 70+ years after the medical record is created. Think of the MRI of a kid to scan for some condition that may be genetic in origin and has to be monitored and compared with more recent results their whole life. Thanks, Allen - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
block cipher modes and collisions
The wikipedia page on the IEEE SISWG debate about LRW says: [A] general security requirement for any block cipher, regardless of mode of operation, is that no block cipher should be used to encrypt any more data, without changing the key, when the probability of a collision becomes not negligible (see also birthday paradox). They must mean output collisions, rather than multiple preimages, but I think some modes will have collisions at a rate which depends on the plaintext (LRW being the obvious example)... but I've never heard of this security requirement before. Excepting the Handbook of Applied Cryptography, which I need to read, does anyone have another reference for this requirement, or others like it? I suppose that NIST might have published something like that in the various publications about block cipher modes, but don't know where to look exactly... -- ``Unthinking respect for authority is the greatest enemy of truth.'' -- Albert Einstein -- URL:http://www.subspacefield.org/~travis/ pgp39knc2U9V2.pgp Description: PGP signature
Re: analysis and implementation of LRW
On Wed, Jan 24, 2007 at 03:28:50PM -0800, Allen wrote: David Wagner wrote: [snip] Another possible interpretation of (2) is that if you use LRW to encrypt close to 2^64 blocks of plaintext, and if you are using a 128-bit block cipher, then you have a significant chance of a birthday collision, Am I doing the math correctly that 2^64 blocks of 128 bits is 2^32 bytes or about 4 gigs of data? Or am I looking at this the wrong way? This is quite wrong. 2^64 * 2^4 = 2^68 not 2^32, I don't know where you lost the factor 2^36, but it sure makes a big difference. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: analysis and implementation of LRW
To clarify a couple of points with regard to IEEE P1619 and LRW. The original proposal which P1619 called LRW was actually a particular concrete instantiation of a general construction from the LRW paper (Liskov, Rivest and Wagner, Tweakable Block Ciphers, Crypto 02, http://www.cs.berkeley.edu/~daw/papers/tweak-crypto02.pdf ). The LRW construction was C = E_k(P xor h(T)) xor h(T) where E_k is a block cipher with key k, T is the tweak and h(T) is a keyed almost-xor-universal function. P1619 instantiated E as AES and h as galois field multiplication by a secret constant value: h(T) = k2*T where T is the block number. This is what they called LRW and it has the weakness described, that if you have two consecutive blocks containing k2 and zero, P xor h(T) can be the same for both of them. This is what the group called a collision, meaning two blocks whose input to the AES is the same. For this simple definition of h(T) as k2*T a collision can reveal k2. However this is not a general flaw in LRW, it is merely a problem with this very simple instantiation of the construction. In fact the replacement, which the group calls XTS, is also an instance of LRW. Based on work by Rogaway, the construction is the same as above but the universal hash h(T) = E_k2(T1) * alpha^T2, where T1 are the leftmost bits of the block number T and T2 are the rightmost bits (alpha is a primitive root, and the math is finite field). Rogaway proved that this hash is universal and hence this is an instance of LRW and is secure. So it is an over-simplification to say that P1619 found LRW insecure and replaced it. P1619 found that a particularly simple instantiation of LRW had this problem when encrypting part of its key, and substituted a more complicated version of LRW which appears to be largely immune to the problem. P1619 is still using LRW and it should still be considered a very seminal and useful cryptographic construction. It should be noted that almost no cryptographic proofs of security work when arbitrary functions of the key are allowed as inputs to other parts of the cipher, and at this point we must largely rely on heuristic and informal arguments to see whether any weaknesses are real or merely theoretical. Hal Finney PGP Corporation P1619 Member - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
