Cryptography-Digest Digest #883, Volume #10 Tue, 11 Jan 00 09:13:01 EST
Contents:
Re: How about this for a "randomly" generated bitstream? (Guy Macon)
Re: Intel 810 chipset Random Number Generator (Guy Macon)
Re: Simple Encryption ... (Johnny Bravo)
Intel 8282 firmware hub RNG internals (Guy Macon)
Re: Intel 810 chipset Random Number Generator (Bradley Yearwood)
Re: Intel 810 chipset Random Number Generator (Bradley Yearwood)
Re: Little "o" in "Big-O" notation ("Scott Fluhrer")
Re: Square root attacks against DSA? (David Hopwood)
Re: Questions about message digest functions (David Hopwood)
another newbie ("Markus Eiber")
Re: Square root attacks against DSA? (Paulo S. L. M. Barreto)
Re: The Cipher Challenge from the Code Book (Staffan Ulfberg)
Rijndael (was: Square?) (Paulo S. L. M. Barreto)
Re: Simple Encryption ... ("Derek Potter")
Re: AES & satellite example ([EMAIL PROTECTED])
Re: another newbie (Jeff Williams)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: How about this for a "randomly" generated bitstream?
Date: 11 Jan 2000 01:17:19 EST
Your post got mangled somehow. It was one long line that got truncated.
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Trevor Jackson, III) wrote:
>No, he's _adding_ 8 bit data to 24 bit data, which will occasionally overflow the low
>byte into bit 8. It's a form of probabilistic roundin
I think I get it, though, and you are right. The 16th bit (the new LSB)
will clearly have a probabalistic "error" imposed that is assosiated with
the 8 bits that don't fit.
The existance of a method of preserving something related to the lost
bits during 24 bit to 16 bit conversions does not exclude modifying
the LSB of true 16 bit material with a PRNG
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Intel 810 chipset Random Number Generator
Date: 11 Jan 2000 01:23:19 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Trevor Jackson, III) wrote:
>Because the example for a multi-threaded app works when applied at the OS level. To
>the OS the applications look like threads. The fact th
Your posts bare all exceeding 80 collumns today, and somewhere between
you and me everything after the 160th character disapears. Could you
repost? I am interested in what you have to say.
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Simple Encryption ...
Date: Tue, 11 Jan 2000 01:04:49 GMT
On Tue, 11 Jan 2000 02:03:58 -0000, "Derek Potter"
<[EMAIL PROTECTED]> wrote:
>
>"r.e.s." <[EMAIL PROTECTED]> wrote
>> Wouldn't it be easier, and just as well, to simply
>> identify yourself in the plaintext document, then
>> publish a 1-way hash of the document (say with SHA1),
>> avoiding the use of keys altogether?
>
>How big would the hash be compared with the
>original document?
Not big at all. 20 bytes gives you 2^160 possible hashes,
that should be more than enough.
Best Wishes,
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Intel 8282 firmware hub RNG internals
Date: 11 Jan 2000 01:58:15 EST
I found out what goes on under the hood today. Read this:
[ ftp://download.intel.com/design/security/rng/CRIwp.pdf ]
------------------------------
Subject: Re: Intel 810 chipset Random Number Generator
From: [EMAIL PROTECTED] (Bradley Yearwood)
Date: Tue, 11 Jan 2000 07:35:02 GMT
In article <[EMAIL PROTECTED]>,
Doug Stell <[EMAIL PROTECTED]> wrote:
>On 7 Jan 2000 14:13:16 -0800, [EMAIL PROTECTED] (Bradley Yearwood)
>wrote:
>> ... appears to indicate a worst-case rate of
>>random byte production of around 222 bytes/sec.
>
>This doesn't sound very useful. A randomizer should be able to quickly
>supply a random block the size of a symmetric key, a Diffie-Hellman
>private key or a prime 1/2 the size of an RSA modulus.
>
>By contrast, the Motorola Advanced INFOSEC Machine (AIM) supplies of
>random data up to 1024 bits in length, organized as a buffer of 32
>32-bit words. Blocks may be requested as often as every 146 usec.
>Also, this is a true, NSA-certified randomizer, not a PRNG. The AIM is
>dedicated to performing crypto, particularily high-grade crypto.
Depends upon the application. Big difference in capabilities required
and cost structure appropriate for generating session keys for a zillion
concurrent clients in hot ecommerce, vs. applying signatures to occasional
pieces of information originating at one client machine.
------------------------------
Subject: Re: Intel 810 chipset Random Number Generator
From: [EMAIL PROTECTED] (Bradley Yearwood)
Date: Tue, 11 Jan 2000 07:40:51 GMT
In article <[EMAIL PROTECTED]>,
Scott Nelson <[EMAIL PROTECTED]> wrote:
>On 7 Jan 2000 [EMAIL PROTECTED] (Bradley Yearwood) wrote:
>> ... which appears to indicate a worst-case rate of
>>random byte production of around 222 bytes/sec.
>>
>Actually, the worst case is infinite,
>but the _average_ is claimed to be 75Kbits per second.
>The odds against having to wait 4.5ms are extreme,
>thus the recommendation that if you have to wait longer
>than that, you should give up and assume there's a problem.
I suspect that you are quite correct on this. Was it Eddington who
gave the example that it was _possible_ that all of the air molecules
in the room could at once Brownianly move all to one side, leaving the
other side a vacuum and the occupant asphyxiated? I suppose that the smaller
the system gets, the more frequent massively atypical behaviors should
become, but I'd bet that we need not worry too much unless something breaks.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Little "o" in "Big-O" notation
Date: Tue, 11 Jan 2000 00:23:19 -0000
Bob Silverman <[EMAIL PROTECTED]> wrote in message
news:85d5j2$ebk$[EMAIL PROTECTED]...
> For example, I
> > know that o(1) becomes negiligible as the integer approaches infinity.
>
> Really? Then you know something noone else does!
> an integer is a constant. The expression "as the integer approaches
> infinity" is meaningless drivel.
Groan :-(. My second correction in as many days. Obviously, this is not my
week...
By negiligible (sic), I meant "arbitrarily close to zero" (yes, I know they
aren't the
same thing).. By "as the integer approaches infinity", I meant "as x
approaches
infinity".
With those corrections, the statement is accurate.
> no flame intended.
With as sloppy as I got with my terminology, a flame was deserved.
>
> f(x) is o(1) simply means (from the definition!)
>
> |f(x)/1| --> 0 as x--> oo. Note: as x--> oo. x is a variable!
>
>
>
> --
> Bob Silverman
> "You can lead a horse's ass to knowledge, but you can't make him think"
I have the knowledge, honest, I just been having a hard type stating it
accurately.
--
poncho
------------------------------
Date: Tue, 11 Jan 2000 08:25:40 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Square root attacks against DSA?
=====BEGIN PGP SIGNED MESSAGE=====
lcs Mixmaster Remailer wrote:
>
> In message <[EMAIL PROTECTED]>, David Hopwood proposes an
> algorithm for recovering the DSS private key from a small number of
> signatures (without the public key) assuming that q is small enough that
> square root attacks work:
[...]
> The problem is that "mod p mod q" does not define a group structure.
You're right, the attack doesn't work.
Specifically, it doesn't work because we only have beta mod q, and
(beta mod q) * g^-im != beta * g^-im (mod p).
Oh well, thanks for pointing out the error.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOHrozTkCAxeYt5gVAQEEOQgAhJItm5qb7kSXwPZ0WgISmg1Qwsr60djs
znWU9AJF+dA8lHrU+qcwNave653dp54hY6XTPj/Bo3EDaDr6AshQPIfguTJ2t0Vo
YRic2cVcup/NTQ8wamjEUmSzznfMm/kpM6aN94ZpM+j6cOkcnQABf/e4kcZJNRV/
LNF6ncj5nqEOOT+CPb4/8jjk30Ub4LdOUi7sv8Li7t5mCJBRwyQFwR23KVzhOxU6
+cjD2opIV5aAxA9VFpSU2ieYeWSMFg6K9UwGDAHCvSVCGokQ7W1Srvj4BYORz4Wv
mi+g0SFH7SwKQm0ZCSDXjWDhU8LcifiBbDXc7toKrTtZF+/CxISnvw==
=clEn
=====END PGP SIGNATURE=====
------------------------------
Date: Tue, 11 Jan 2000 08:26:37 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Questions about message digest functions
=====BEGIN PGP SIGNED MESSAGE=====
Tim Tyler wrote:
>
> Matt Timmermans <[EMAIL PROTECTED]> wrote:
>
> : I missed the start of this thread, but as far as I know, there are no
> : known one-way permutations that can be shown to be permutations -- do
> : you actually know of one, Tim?
>
> What about the one I propsed in a post on this thread in which I quoted
> from section 18.12 of Schneier's "Applied Cryptography"?
>
> : For instance: If I publish an RSA modulus and public exponent as a PRP,
> : how do I show that it _is_ a permutation without revealing private
> : information, at which point it would cease to be one-way?
>
> As I understand it, RSA-based block cyphers can losslessly encode
> information from a message in the same number of bits as are present in
> the message.
>
> I don't see how can this fail to be a bijection when used as a hash (i.e.
> by destroying the private key) - when hash size, message size and block
> size are all equal?
You're missing Matt Timmerman's point. The person who generated the
RSA modulus and exponent may know that this is a PRP, but no-one else is
able to verify that a valid RSA public key is being used (specifically,
they cannot check that gcd(e, phi(n)) = 1 because they don't know phi(n)).
In general, a trapdoor function with the trapdoor information discarded
is *not* necessarily usable in the same contexts as a public function.
> When you use RSA to encrypt, you can decrypt again and recover the
> original message. If you can do this for all possible files of a given
> length, and the size of the domain is equal to the size of the range,
> what other possible maps could there be, besides a bijection?
Think about what happens if e and phi(n) are not relatively prime.
> Also, (to answer your question another way) hashes of individual messages
> could be computed with the public key.
>
> In principle this would allow a demonstration that the map was a
> permutation by exhaustively going through all the possible messages
> of the given length, and seeing if there are any hash collisions.
Cough, splutter! That's rather a lot of messages.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOHq8RDkCAxeYt5gVAQE8KQgAko2GXlTRFXNiz48Y+Jo+AXDwiE96mmi+
33Xf1AwOAEDfqJMgZvDZsdDRtUi1+DgmxAGXUJdZuwK8cNn1EMvHryMWfP92XehK
Ej6sn4FND1pf39BlIMXgYKCafB1NC2lE53d8BQf6b75e3ODAoDbdcU0GTqzY8dQg
+81egrlLWe3fo28zKA/+B3vl5Ne1YRN+0NADplBubxMde0DpTNmDKX7aoRfDUCb4
4aQGYyn+JqwJdSY6x4v81w4hMLWboOqqh1/jBQBFFBN/o+NWbsDYubv1pwyNlMHu
JBZHeg8aG/IghUZ5U0JQtg9wnKp5MoGo8R2FphQuWBxxOc/awiwOJA==
=LH9h
=====END PGP SIGNATURE=====
------------------------------
From: "Markus Eiber" <[EMAIL PROTECTED]>
Subject: another newbie
Date: Tue, 11 Jan 2000 11:09:22 +0100
Hi there,
I am looking for information about how to calculate the practical secrecy of
a cipher.
Is there a measure like the unicity distance for theoretical secrecy? How
can it be calculated?
Thanks for any input you could provide.
------------------------------
From: Paulo S. L. M. Barreto <[EMAIL PROTECTED]>
Subject: Re: Square root attacks against DSA?
Date: 11 Jan 2000 03:21:06 -0800
In article <[EMAIL PROTECTED]>, David says...
[...]
>lcs Mixmaster Remailer wrote:
[...]
>> The problem is that "mod p mod q" does not define a group structure.
>
>You're right, the attack doesn't work.
[...]
So the only effective attack known up to now seems to be the following idea
suggested by Serge Vaudenay:
>There is still a square root attack which consists in collecting 2^80
>(r,k) pairs in a hash table (sorted by the first entry), and waiting
>for a signature with an r in the table. After 2^80 signatures we can
>expect to get one, recover the only expected k, then get the secret
>key from s.
Initially I thought this attack could be easily extended to Schnorr signatures
as well, but this turned out not to be the case. Schnorr's algorithm sets r =
hash(m || t) and s = (k - xr) mod q, where t = g^k mod q (notice that creating a
table with (t, k) pairs is less useful now because t cannot be recovered as g^s
y^r mod p unless the hidden public key y = g^x mod p itself is known, or if the
message m is kept constant).
Paulo Barreto.
------------------------------
From: Staffan Ulfberg <[EMAIL PROTECTED]>
Subject: Re: The Cipher Challenge from the Code Book
Date: 11 Jan 2000 13:14:29 +0100
[EMAIL PROTECTED] (Paris Guffey) writes:
> On Tue, 04 Jan 2000 07:23:25 GMT, Sisson <[EMAIL PROTECTED]>
> wrote:
> [snip]
>
> >begin 644 DEBUGGER.BIN
> > (-&>`_EU-_/$`
> ><blank line>
> >end
>
> You should know that an errata was posted on the Cipher Challenge
> website correcting this code. There should be a single back-quote(`)
> on the blank line.
Well, but a space works as well as a back-quote, and I suppose that's
what Singh used. Of course, in print a space doesn't show very well
at the end of a line... (Try encoding the file using the standard
tool on Solaris and compare it with the output on a BSD system to get
the idea.)
Staffan
------------------------------
From: Paulo S. L. M. Barreto <[EMAIL PROTECTED]>
Subject: Rijndael (was: Square?)
Date: 11 Jan 2000 03:46:10 -0800
In article <[EMAIL PROTECTED]>, "Daniel says...
>
>> Rijndael supports both keysizes and blocksizes of 128, 192,
>> and 256 bits, giving 9 combinations. The number of rounds
>> is size dependent, however: 10 rounds if both parameters are
>>128, 12 rounds if the larger of them is 192, and 14 rounds if the
>> larger of them is 256.
>
>I think (correct me if I'm wrong), that Rijndael actually allows to use key
>sizes other than those 3, as long as it is dividable by 32. At least that's
>what the documentation says, and the key setup procedure seems to support
>that without making great changes to the code.
>The reference implementations only support 128, 192 and 256 bits 'cos that's
>what is required by NIST. But you could use Rijndael with say 224 bit keys,
>and that well within its specifications.
>
>
>/Dan
In principle, yes. But the number of rounds for other key sizes is not
specified. The obvious choice (interpolating or extrapolating from the defined
values) is not likely to be wise unless a security analysis is done (e.g.
remember that the diffusion properties originate from 4-round sequences).
Paulo.
------------------------------
From: "Derek Potter" <[EMAIL PROTECTED]>
Subject: Re: Simple Encryption ...
Date: Tue, 11 Jan 2000 12:36:22 -0000
"r.e.s." <[EMAIL PROTECTED]> wrote
> SHA1 hashes "any" input document into 20 bytes of output
OK. I get the idea. I'll have a look for
SHA1 and maybe learn a bit :)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: AES & satellite example
Date: Tue, 11 Jan 2000 12:26:11 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (DJohn37050) wrote:
> I am writing a paper for 3rd AES and remember someone discussing in
sci.crypt
> that a reason for having multiple AES winners were situations where
hardware
> was used but was not able to be updated, as in satellites, Does
anyone
> remember who said that?
> I want to give proper attribution.
Jerry Coffin. Usenet is archived by DejaNews. Eg, here is a
URL to Bruce Schneier saying that it is a moronic example, in
response to one of your messages.
http://x44.deja.com/[ST_rn=ps]/getdoc.xp?AN=538664081
Just click on "Thread" to see the entire thread.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jeff Williams <[EMAIL PROTECTED]>
Subject: Re: another newbie
Date: Tue, 11 Jan 2000 07:20:33 -0600
==============7EE7642AF4A8BE2890583344
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Well, doubtless some folks will disagree with me, but that's okay; they have the
right to be wrong, if they so choose :)
My answer would be "maybe". Assuming that there is no known attack against
the particular cipher of interest, the simplest, and most common, method I've
seen is based on keyspace. That is, how many possible keys would an attacker
have to try to break the message using a brute force and ignorance (BFI) attack.
This isn't really a practical limit, it's more of a theoretical limit. But it is one
that
you can actually calculate with real numbers. For example, a Caesar cipher has
26 keys (one of which is pointless). DES has 2^56 keys. Which would you
prefer. (Please DO remember the assumption I made at the start of this
paragraph. A crappy algorithm with a large keysize may be worse than a good
algorithm with a smaller keysize.)
I must point out that the efficacy of a cipher, while very important, is only part of
the efficacy of a system as a whole. If you monitor this group for a while, you will
see that there are lots of other aspects to security. Many of those aspects
involve users who may not understand (or care) about security. To judge security,
you must look at the whole system.
Markus Eiber wrote:
> Hi there,
> I am looking for information about how to calculate the practical secrecy of
> a cipher.
> Is there a measure like the unicity distance for theoretical secrecy? How
> can it be calculated?
>
> Thanks for any input you could provide.
--
Jeff Williams - Alcatel USA.
Did you know that there is enough sand
in North Africa to cover the entire
Sahara desert?
==============7EE7642AF4A8BE2890583344
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Well, doubtless some folks will disagree with me, but that's okay; they
have the
<br>right to be wrong, if they so choose :)
<p>My answer would be "maybe". Assuming that there is no known attack
against
<br>the particular cipher of interest, the simplest, and most common, method
I've
<br>seen is based on keyspace. That is, how many possible keys would
an attacker
<br>have to try to break the message using a brute force and ignorance
(BFI) attack.
<br>This isn't really a practical limit, it's more of a theoretical limit.
But it is one that
<br>you can actually calculate with real numbers. For example, a
Caesar cipher has
<br>26 keys (one of which is pointless). DES has 2^56 keys.
Which would you
<br>prefer. (Please DO remember the assumption I made at the start
of this
<br>paragraph. A crappy algorithm with a large keysize may be worse
than a good
<br>algorithm with a smaller keysize.)
<p>I must point out that the efficacy of a cipher, while very important,
is only part of
<br>the efficacy of a system as a whole. If you monitor this group
for a while, you will
<br>see that there are lots of other aspects to security. Many of
those aspects
<br>involve users who may not understand (or care) about security.
To judge security,
<br>you must look at the whole system.
<p>Markus Eiber wrote:
<blockquote TYPE=CITE>Hi there,
<br>I am looking for information about how to calculate the practical secrecy
of
<br>a cipher.
<br>Is there a measure like the unicity distance for theoretical secrecy?
How
<br>can it be calculated?
<p>Thanks for any input you could provide.</blockquote>
<pre>--
Jeff Williams - Alcatel USA.
Did you know that there is enough sand
in North Africa to cover the entire
Sahara desert?</pre>
</html>
==============7EE7642AF4A8BE2890583344==
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
