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
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
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
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() a
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 a
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 cipher
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
6
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 do
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*
| 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 quest
| > 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/mem
| > 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
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
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 basi
14 matches
Mail list logo
