Re: Intercepting Microsoft wireless keyboard communications
How many bits (not just data, also preamble/postamble, sync bits, etc.) is the keyboard sending for each keystroke anyway? Cheers, /ji - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Flaws in OpenSSL FIPS Object Module
On Mon, Dec 10, 2007 at 04:17:38PM -0500, Leichter, Jerry wrote: > 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! But also to be expected, because the feature in question is "unnatural": the software needs a testable PRNG to pass the compliance tests, and this means adding code to the PRNG to make it more predictable under test conditions. As the tests only test the predictable PRNG, it is easy to not notice failure to properly re-seed the non-test PRNG. One can't easily test failure to operate correctly under non-test conditions. And the additional complexity of the test harness makes such failure more likely. The interaction of the test harness with the software under study needs close scrutiny (thorough and likely multiple independent code reviews). Similar bugs are just as likely in closed-source software and are less likely to be discovered. -- /"\ 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: Intercepting Microsoft wireless keyboard communications
On Tue, 11 Dec 2007, Steven M. Bellovin wrote: | On Tue, 11 Dec 2007 13:49:19 +1000 | "James A. Donald" <[EMAIL PROTECTED]> wrote: | > Use CFB mode. That takes care of all the above problems... | 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? Keep-alives are a bad idea. It's interesting how they keep hitting limitations of various tecshnologies. Back in the '70's, I worked on the design of some protocols to be used by terminals. In Europe, the only remote access mechanism you could use was X.25, provided by the local PTT. If you had two buildings across the street from each other, you were legally forbidden from running a wire between them - the PTT had a monopoly. An X.25 charges were per packet - a keep-alive would cost you a fortune. In fact, sending ACK's could double your costs! I don't know enough about low-power design to guess where the power costs actually go. If there is a significant cost in just starting the transmitter, then sending two bytes might not use up anything like twice the energy of sending just one (though it will certainly use *some* more). Realistically, some key codes are much, much more frequent than others. A simple Huffman encoding of the keycodes should let you get an average message length well below the two bytes that I think are the standard. (Yes, there are variations due to keyboard usage, but even a fairly generic encoding should give you reasonable compression.) No Huffman code is a prefix of another, so you can tell when you've reached the end of a code. Then you can use the remaining bits of a 2-byte block for redundancy. (Of course, some rare keys will require sending an extra block.) Just sending as many bits as you can of a count of messages the keyboard thinks it sent would probably be a pretty effective check. These days, you can probably cost-effectively put enough memory in a keyboard to make this possible. -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: PlayStation 3 predicts next US president
Francois Grieu wrote: >> 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. William Allen Simpson wrote: > First of all, the weakness in MD5 (computational > feasibility over time) that "we are talking about" is > not (yet) a preimage or second preimage attack. > Please don't extrapolate your argument. I don't think you know what a preimage or second preimage attack is. A preimage attack is a method of finding a document that hashes to an arbitrary given hash. A second preimage attack is a method of finding a document that hashes to the same hash as arbitrary given document. Your proposed workaround protocol fails because the adversary can construct multiple documents containing some arbitrary text and some chosen text that hash to the same hash - the fact that some of the arbitrary text comes from the good guys is irrelevant. The fact that the bad guys get to choose some of the text in all of the documents makes it fail. > Second of all, you need to read my messages more > carefully. No good canonical format allows random > hidden fields or images. There is no canonical format that suppresses human ignorable data, other than plain ascii or suchlike which is unlikely to be acceptable. Any format capable of displaying arbitrary well formatted documents is capable of containing data that humans are likely to ignore. What is ignorable is necessarily a human judgment. A canonical format is in practice going to be PDF or RTF, which does allow hidden fields and images. Further, even a visible image can be made to work. Further, it is quite subtle to decide what constitutes "hidden" - for example a gently irregular low intensity background on HTML pages is quite pleasing to the eye, so surely our format should allow such backgrounds. Further, what you propose is strengthening the protocol to work around known weaknesses in MD5. Whenever we strengthen a protocol to get around known weaknesses in an algorithm, we rarely do it right - consider the long succession of debacles surrounding RC4. SSH uses RC4 correctly, but consider all the protocols that used it incorrectly, and then issued incompatible updates to fix the flaws, updates that were even more flawed than the protocol they supposedly fixed. Further, if you want your protocol to work around the known weaknesses of MD5, "canonicalizing" the document is not the way to go. Instead, allow arbitrary documents, but precede them by salt which is randomly determined after the document is submitted. That will work a lot better than canonicalization, but it is still a workaround for a known weakness. Far better to avoid the weakness. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: PlayStation 3 predicts next US president
silky wrote: 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. Thanks for the pointer. Very interesting and it proves that I don't have the horsepower at this point. (Just wait until I build that Microwulf! With the new quad core chips I should hit about 50 GigaFLOPS. And cheeep - less than 4K) But my real point is that CRC32 while has only 2^16 possibilities, even SHA 1 with its degraded state has (IIRC) 2^55 and if we go to SHA 256 it has 2^256 possibilities. Since MD5 and SHA 256 use two different algorithms the odds of creating a double collision are tiny at this point. So take your enhanced Tripwire like program and have it compute two different hashes. Yes, you can create a collision in the MD5, but can you also create a simultaneous collision in the SHA 256? This is my point. Best, Allen - 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. > > > I"m 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]
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. I"m 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: 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: 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: 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: 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: 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. | | I"m 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: 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: 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]
