Re: Flaws in OpenSSL FIPS Object Module
On Mon, 10 Dec 2007 11:27:10 -0500 Vin McLellan [EMAIL PROTECTED] wrote: What does it say about the integrity of the FIPS program, and its CMTL evaluation process, when it is left to competitors to point out non-compliance of evaluated products -- proprietary or open source -- to basic architectural requirements of the standard? Integrity or ability? We all know that finding problems in code or architecture is *very* hard. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Flaws in OpenSSL FIPS Object Module
Vin McLellan wrote: What does it say about the integrity of the FIPS program, and its CMTL evaluation process, when it is left to competitors to point out non-compliance of evaluated products -- proprietary or open source -- to basic architectural requirements of the standard? Enter Reality 2.0. Yesterday, security was based on authority -- on some particular agency or expert. Today, security is /also/ based on anyone else that can point out non-compliance, and solutions. The integrity of the FIPS program, and any other evaluation process, can only increase when [x] are also able (entirely on their own and not by a mandate) to point out non-compliance of evaluated products -- proprietary or open source -- to basic architectural requirements of the standard. Here [x] = competitors, attackers, outside experts, anyone in general. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Intercepting Microsoft wireless keyboard communications
| 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. | | It's moderately complex if you're trying to conserve bandwidth (which | translates to power) and preserve a datagram model. The latter | constraint generally rules out stream ciphers; the former rules out | things like encrypting the keystroke plus seven random bytes with a | 64-bit block cipher. Power is also an issue if your cipher uses very | much CPU time or custom hardware. | | Im sure most readers of this list can propose *some* solution. It's | instructive, though, to consider everything that needs to go into a | full system solution, including the ability to resynchronize cipher | states and the need to avoid confusing naive users if the cat happened | to fall asleep on the space bar while the CPU was turned off. Somewhere - perhaps in the Computerworld article - someone mentions that some devices use Bluetooth, and are therefore much more secure. In practice, most Bluetooth devices don't even agree on a non-zero key when pairing, so just using Bluetooth is no promise of anything. Does anyone know how good Bluetooth security can potentially be - and is it practically attainable in the low power/lost message context that would be needed here? How are some of the emerging low-power protocols (e.g., ZigBee) dealing with this? -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 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. | | Then, s/memset(?,0,?)/(memset)(?,0,?)/ to get rid of compiler | in-lining. | | Ref: ANSI X3.159-1989, section 4.1.6 (Use of C standard library | functions) I don't have te C89 spec handy (just the C99 spec, which is laid out differently), but from what I recall, this construct guarantees nothing of the sort. Most standard library functions can be implemented as macros. Using the construct (f)(args) guarantees that you get the actual function f, rather than the macro f. However, that doesn't say anything about whether f is actually invoked at run time. That comes under the acts as if rule: If the compiler can prove that the state of the C (notional) virtual machine is the same whether f is actually invoked or not, it can elide the call. Nothing says that memset() can't actually be defined in the appropriate header, as a static (or, in C99, inline) function. Then the compiler can look at the implementation and prove that a memset() to a dead variable can be elided -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Flaws in OpenSSL FIPS Object Module
| What does it say about the integrity of the FIPS program, and its CMTL | evaluation process, when it is left to competitors to point out | non-compliance of evaluated products -- proprietary or open source -- | to basic architectural requirements of the standard? I was going to ask the same question. My answer: This proves yet again how far we are from a servicable ability to produce secure software. Software that's been through the FIPS process has been vetted to the limits of our current abilities under the constraints of being even vaguely commercially viable. OpenSSL is open source software that's been around for a long time, examined by many, many people. It had a very rough journey through the FIPS process, so was presumably checked even more than software that just breezes through. Even so ... it had a security bug. It's hard to suggest something that could have been done differently to guarantee that this couldn't happen. Anyone who might argue - as I'm sure they will - that this proves you should use commercial software rather than OSS if you need security is speaking nonsense - that's not at all what this incident is about. It is, of course, the height of irony that the bug was introduced in the very process, and for the very purpose, of attaining FIPS compliance! -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PlayStation 3 predicts next US president
William Allen Simpson wrote: [snip] The whole point of a notary is to bind a document to a person. That the person submitted two or more different documents at different times is readily observable. After all, the notary has the document(s)! No, the notary does not have the documents *after* they are notarized, nor do they keep copies. Having been a notary I know this personally. When I stopped being a notary all I had to submit to the state was my seal and my record books. If I had to testify about a document I would only be attesting that the person who presented themselves adequately proved, under the prudent businessman's standard, that they were the person that they said they were and that I saw them sign the document in question. That's it. No copies at all. What would anyone have to testify about if a legal battle arose after the notary either died or stopped being a notary? Think for a minute about the burden on a notary if they had to have a copy of every document they notarized. What a juicy target they would make for thieves and industrial spies. No patent paperwork would be safe, no sales contract, no will, or other document. Just think how the safe and burglar alarm companies would thrive. Now ask yourself how much it costs to notarize a document. Would that pay for the copying and storage. I don't know what the current fees are in California but 20 years ago they were limited to $6.00 per person per document and an extra buck for each additional copy done at the same time. My average was about $14.00 per session. My insurance was $50/year. Nowhere near enough to cover my liability if I was to retain a copy of the document. Best, Allen - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PlayStation 3 predicts next US president
On Dec 11, 2007 5:06 AM, Allen [EMAIL PROTECTED] wrote: What puzzles me in all this long and rather arcane discussion is why isn't the solution of using a double hash - MD5 *and* SHA whatever. The odds of find a double collision go way up. Some open source software people are already doing this. I've played around with the sample files that are out there and find an easy way to do this but I don't have either the horsepower or skill to be at all definitive. My gut tells me that using two processes that use different algorithms, even though compromised, will raise the bar so high that it would be secure for a long time. At my skill level and horsepower I can't find even a single way to do this with CRC32 and MD5. Granted, that certainly doesn't mean a whole lot. Work has actually been done on this exact topic. One link is here: http://cryptography.hyperlink.cz/2004/otherformats.html I think there may be more; I'm not sure. But to take a real world example, a safety deposit box, the two keys have to work together to open the box. It really does not matter is one is a Yale and the other a combination, either one of which are easily compromised by themselves, but together you would have to find both at the same time to open the box, a lot tougher problem. Best, Allen Francois Grieu wrote: [EMAIL PROTECTED] wrote: 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) ). In this context, the only thing that guards agains an attack by some person is the faint hope that she can't predict the Tn that the notary will use for a Dp that she submits. That's because if Tn is known (including chosen) to some person, then (due to the weakness in MD5 we are talking about), she can generate Dp and Dp' such that S( MD5(Tn || Dp || Cp || Cn) ) = S( MD5(Tn || Dp' || Cp || Cn) ) whatever Cp, Cn and S() are. If Tn was hashed after Dp rather than before, poof goes security. Francois Grieu - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- mike http://lets.coozi.com.au/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Intercepting Microsoft wireless keyboard communications
Steven M. Bellovin wrote: It's moderately complex if you're trying to conserve bandwidth (which translates to power) and preserve a datagram model. The latter constraint generally rules out stream ciphers; the former rules out things like encrypting the keystroke plus seven random bytes with a 64-bit block cipher. Power is also an issue if your cipher uses very much CPU time or custom hardware. Im sure most readers of this list can propose *some* solution. It's instructive, though, to consider everything that needs to go into a full system solution, including the ability to resynchronize cipher states and the need to avoid confusing naive users if the cat happened to fall asleep on the space bar while the CPU was turned off. Use CFB mode. That takes care of all the above problems. You can transmit any small bunch of bits, don't need to transmit a complete block, and if the keyboard and the receiver get out sync, the keyboard's signal will be decrypted as garbage for the first 128 bits. If one has the keyboard regularly transmit no key's pressed from time to time, and if valid key press representations have a couple of check bits redundancy, with several keypresses being ignored after any invalid key signal, keyboard and receiver will synchronize with no fuss. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Intercepting Microsoft wireless keyboard communications
On Tue, 11 Dec 2007 13:49:19 +1000 James A. Donald [EMAIL PROTECTED] wrote: Steven M. Bellovin wrote: It's moderately complex if you're trying to conserve bandwidth (which translates to power) and preserve a datagram model. The latter constraint generally rules out stream ciphers; the former rules out things like encrypting the keystroke plus seven random bytes with a 64-bit block cipher. Power is also an issue if your cipher uses very much CPU time or custom hardware. Im sure most readers of this list can propose *some* solution. It's instructive, though, to consider everything that needs to go into a full system solution, including the ability to resynchronize cipher states and the need to avoid confusing naive users if the cat happened to fall asleep on the space bar while the CPU was turned off. Use CFB mode. That takes care of all the above problems. You can transmit any small bunch of bits, don't need to transmit a complete block, and if the keyboard and the receiver get out sync, the keyboard's signal will be decrypted as garbage for the first 128 bits. If one has the keyboard regularly transmit no key's pressed from time to time, and if valid key press representations have a couple of check bits redundancy, with several keypresses being ignored after any invalid key signal, keyboard and receiver will synchronize with no fuss. Believe it or not, I thought of CFB... Sending keep-alives will do nasties to battery lifetime, I suspect; most of the time, you're not typing. As for CFB -- with a 64-bit block cipher (you want them to use DES? they're not going to think of anything different), it will take 9 keypresses to flush the buffer. With AES (apparently your assumption), it will take 17 keypresses. This isn't exactly muggle-friendly. Just think of the text in the instructions... Redundancy? I wonder how much is needed to avoid problems. It has to be a divisor of the cipher block size, which more or less means 8 extra bits. How much will that cost in battery life? --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
