Re: PlayStation 3 predicts next US president
William Allen Simpson wrote: The notary would never sign a hash generated by somebody else. Instead, the notary generates its own document (from its own tuples), and signs its own document, documenting that some other document was submitted by some person before some particular time. And how does it identify this other document? The notary is only safe from this flaw in MD5 if you assume he is not using MD5 for its intended purpose. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
More on in-memory zeroisation
There was a discussion on this list a year or two back about problems in using memset() to zeroise in-memory data, specifically the fact that optimising compilers would remove a memset() on (apparently) dead data in the belief that it wasn't serving any purpose. Reading through Secure Programming with Static Analysis, I noticed an observation in the text that newer versions of gcc such as 3.4.4 and 4.1.2 treat the pattern: memset(?, 0, ?) differently from any other memset in that it's not optimised out. I couldn't find any reference to this behaviour anywhere and asked the authors about this. They replied: We did experiments with a number of different compilers and optimization levels in order to determine the conditions under which calls to memset would be optimized out. We stumbled on the fact that zero is treated differently pretty much by accident, and we don't have any particular insight into why it behaves the way it does. I've done a bit of poking around in gcc discussion threads and there's a lot of muttering about support for bcopy() and bzero(), and in particular its use in places where it can't be replaced by memcpy()/memset() (e.g. assorted OS kernels). Speculating wildly, my guess is that the peculiar behaviour with (?, 0, ?) parameters is a compatibility hack for bzero() support, so it may be purely an implementation artefact. For example if you look at http://kerneltrap.org/man/linux/man3p/bzero.3p it recommends: #define bzero(b,len) (memset((b), '\0', (len)), (void) 0) so it's possible the gcc folks added the special memset() semantics because of this. So it seems that at least with recent versions of gcc you *can* zeroise memory provided you use the memset(?, 0, ?) pattern. Unfortunately since it's undocumented behaviour it's not certain whether this will be persistent in future compiler versions. Doing it this way does seem a nice compromise between I want maximum optimisation and I want maximum security. Can anyone who knows more about gcc development provide more insight on this? Could it be made an official, supported feature of the compiler? Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Intercepting Microsoft wireless keyboard communications
When I looked at this circa 2001-2002, for another company, other 27MHz keyboards didn't even bother to encrypt. Most of the data was sent in the clear, with neither encryption nor robust authentication. Exactly what makes this problem so difficult eludes me, although one suspects that the savage profit margins on consumables like keyboards and mice might have something to do with it. Ian. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leichter, Jerry Sent: Friday, 7 December 2007 10:13 AM To: cryptography@metzdowd.com Subject: Intercepting Microsoft wireless keyboard communications http://www.dreamlab.net/download/articles/Press%20Release%20Dreamlab%20T echnologies%20Wireless%20Keyboard.pdf Computerworld coverage at http://www.computerworld.com/action/article.do?command=viewArticleBasic; articleId=9051480 The main protection against interception is the proprietary protocol, which these guys were able to reverse engineer. The exchange is encrypted using a Caeser cipher (XOR with a single byte that is the common key, which is the only secret in the system); they say they can determine the right key within 30 characters or so. Their current hardware can read the data from 33 feet away; with a better antenna, well over a hundred feet should be possible. These things operate at 27 MHz, which will penetrate walls easily. Reading multiple keyboards at once is possible and they already do it. They are looking at injecting data into the stream - presumably not very hard. Many other brands of wireless keyboard may well be equally vulnerable. -- Jerry - 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: PlayStation 3 predicts next US president
Personally, I thought this horse was well drubbed, but the moderator let this message through, so he must think it important to continue James A. Donald wrote: William Allen Simpson wrote: The notary would never sign a hash generated by somebody else. Instead, the notary generates its own document (from its own tuples), and signs its own document, documenting that some other document was submitted by some person before some particular time. And how does it identify this other document? Sorry, obviously I incorrectly assumed that we're talking to somebody skilled in the art Reminding you that several of us have told you that a notary has the document in her possession; and binds the document to a person; and that we have rather a lot of experience in identifying documents (even for simple things like email), such as the PGP digital timestamping service. Assuming, Dp := any electronic document submitted by some person, converted to its canonical form Cp := a electronic certificate irrefutably identifying the other person submitting the document Cn := certificate of the notary Tn := timestamp of the notary S() := signature of the notary S( MD5(Tn || Dp || Cp || Cn) ). Of course, I'm sure the formula could be improved, and there are traditionally fields identifying the algorithms used, etc. -- or something else I've forgotten off the top of my head -- but please argue about the actual topic of this thread, instead of incessant strawmen. The notary is only safe from this flaw in MD5 if you Another statement with no proof. As the original poster admitted, there is not a practical preimage or second preimage attack on MD5 (yet). assume he is not using MD5 for its intended purpose. As to its intended purpose, rather than making one up, I've always relied upon the statement of the designer: ... The MD5 algorithm is intended for digital signature applications, where a large file must be compressed in a secure manner before being encrypted with a private (secret) key under a public-key cryptosystem such as RSA. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
