Cryptography-Digest Digest #657, Volume #13 Thu, 8 Feb 01 12:13:01 EST
Contents:
Re: unpredicable random number generator ? (Mok-Kong Shen)
Re: Encrypting Predictable Files [now on AONTs] ([EMAIL PROTECTED])
Re: PGP 2.6.3ia-cb (now supports CAST5 and BLOWFISH) ([EMAIL PROTECTED])
Re: Bleichenbacher finds bug in DSA RNG (DJohn37050)
Re: relative key strength private vs public key (DJohn37050)
Re: unpredicable random number generator ? (Eric's Login)
Re: Disk Overwriting (Richard Herring)
Re: Disk Overwriting (Richard Herring)
Re: unpredicable random number generator ? ("John A. Malley")
Distributed entropy distribution (Richard Heathfield)
Re: relative key strength private vs public key (Tom St Denis)
Re: File encryption with Rijndael (Jirka Klaue)
Re: Pseudo Random Number Generator (Benjamin Goldberg)
Re: relative key strength private vs public key (DJohn37050)
Re: Distributed entropy distribution (Tom St Denis)
Re: Phillipine math guy claims to have fast RSA Factoring... (Jerry Coffin)
Re: relative key strength private vs public key (Benjamin Goldberg)
Re: Distributed entropy distribution ("Paul Pires")
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: unpredicable random number generator ?
Date: Thu, 08 Feb 2001 15:15:26 +0100
Amaury Jacquot wrote:
>
> the only known ones are based on counting radio-actives beep on a geiger
> counter.
Presumably you wouldn't also be able to predict my sequences
obtained from casting of dice.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Encrypting Predictable Files [now on AONTs]
Date: Thu, 08 Feb 2001 14:14:25 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > leave signatures in the result output. What I mean by this
> > is that if someone studies enough of your messages why let
> > them know what method your using for encryption. ... But why
> > add weknesses in when it is not necessiary.
>
> The counterargument is that security should not depend on
> the enemy not knowing the method you're using anyway, so
> if you have sufficient security anyway then the fact that
> the enemy learns your method doesn't help him any.
>
> Simplistic example:
> filep -> [scott19u] -> filec1
> filep -> [scott19u] -> [prefix with "SCOTT19U:"] -> filec2
> While filec2 is about 10 bytes longer than filec1, which
> is a different kind of drawback, I don't think you want to
> argue that it is *less secure* just because the enemy can
> readily identify the method of encryption by examining the
> ciphertext.
>
Why not even the NSA keeps its ciphers secret and it thinks
they are secure. Why give any information you don't have to.
Sure I think my cipher is strong but I think any cipher can be
broken to a degree far easier than most people let on. Also
why advertise to an enemy so that they can focus all there
resources on the methdos you used. If anysthing leave a false
trail so they think you used something else. Or use two or
more methods in series. Unfortunately this can't be done with
Public key crypto. But even in PGP alot more of the structure
of the file or method used could be hidden in the public key part.
Dave
I anwsered this yesterday but it did not post for some reason
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP 2.6.3ia-cb (now supports CAST5 and BLOWFISH)
Date: Thu, 08 Feb 2001 16:32:49 +0200
jungle wrote:
> > I just added another cipher to PGP 2.6.3ia - Blowfish
> > why? because it was easy :)
>
> and you are calling it PGP ?
> it is not PGP any more ...
then PGP5, 6, 7 is not PGP too ! or is it ? ;-)
== <EOF> ==
Disastry http://i.am/disastry/
http://disastry.dhs.org/pgp <--PGP plugins for Netscape and MDaemon
^^^^^^^^^--^^^^^^^^^----GPG for Win32 (supports loadable modules & IDEA)
^--------PGP 2.6.3ia-cb (supports CAST5 and BLOWFISH)
remove .NOSPAM.NET for email reply
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 08 Feb 2001 14:50:31 GMT
Subject: Re: Bleichenbacher finds bug in DSA RNG
Bleichenbacher's attack exploits a 2:1 skew (towards low values) of the per
message secret (key) k in DSA, as given by the DSA spec.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 08 Feb 2001 14:57:29 GMT
Subject: Re: relative key strength private vs public key
Just for the record, for 256 bit AES keys, I have heard ideas that RSA keys
should be 20,000 bits or even more. I prefer to call the numbers I use NIST
numbers, as that is where they came from. It is EXACTLY because I MAY be
identified as anti-RSA (which I am NOT, but that is another matter) that I
defer to NIST and their numbers. Similarly, others may be identified with
other interests and results can be skewed but still be reasonable, by always
choosing the appropriate plausible value from the range of estimation that gets
the calculation to come out as one wishes.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (Eric's Login)
Subject: Re: unpredicable random number generator ?
Reply-To: [EMAIL PROTECTED]
Date: 8 Feb 2001 07:02:14 -0600
On Thu, 08 Feb 2001 09:48:28 +0000, yomgui <[EMAIL PROTECTED]> wrote:
>by unpredicable,
>I mean that knowing the algorithm
>and a serie of generated numbers
>one can't deduct the seed used to produce them.
>
>is there a such thing?
Yes. They're called random number generators, and they use the
entropic residues of various unpredictable events (at a quantum level)
to produce values. No seed is involved. Thus you can't deduce the seed
(grin).
A *PSEUDO* random number generator, which appears to be what you're
talking about, is the type of generator that needs a seed. There are
two kinds of PRNG's of interest here -- statistical quality PRNG's
(where it does not matter that you can predict past and future values
when given a series of numbers) and cryptographic quality PRNG's
(where it does). The "rand" function in your C compiler's math library
is a statistical-quality PRNG -- it is entirely predictable, meaning
that you can also predict 1-1th value (the seed) if you have the first
value. Cryptographic-quality PRNG's, on the other hand, use one-way
functions to make sure that you can't go from the output back to the
source without brute force. MD5, SHA1, and various symmetric block
ciphers have often been used here as the one way function (note that
the whole point of a symmetric block cipher is that, from looking at
the output, you can't decipher what the input was unless you know the
key... for a PRNG based on a symmetric block cipher, the key is the
seed and the original random block).
Note that even for cryptographic-quality PRNG's, if you ever have the
first <n> outputs of the PRNG for some particular seed (for some <n>
that I don't have the math skills to talk about) you can always find
the seed value and thus perfectly predict past and future values, even
though you have to use brute force (i.e., try all possible seed values
until you get that same stream). Thus the goal for a
cryptographic-quality PRNG is to a) make the seed value large enough
that brute-forcing the algorithm is computationally infeasible (for
Ocotillo I use a 256-bit seed, which means that the heat death of the
universe will occur shortly before a computer cracks it by brute
force), and b) occasionally re-seed from a source of true random
numbers so that the attacker has to repeat the process for the next
<n> numbers if he wants to continue to attack your PRNG.
--
Eric Lee Green Linux Subversives
[EMAIL PROTECTED] http://www.badtux.org
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Subject: Re: Disk Overwriting
Date: 8 Feb 2001 15:06:30 GMT
Reply-To: [EMAIL PROTECTED]
In article <95q380$58d$[EMAIL PROTECTED]>, Tom St Denis ([EMAIL PROTECTED]) wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > Since, once again, we have posters authoritatively claiming either
> >
> > (1) "Disk data can be recovered from under any amount of overwriting,"
> > or
> > (2)"Just overwriting once with FF is sufficient to preclude recovery,"
> >
> > both of which statements are true, but only in context, it seems
> > useful to once again post the following overview in an attempt to
> > provide such context:
> Um if the polly's come and steal my HD what is to stop them from just
> planting a camera in my room.
Er what is to stop you from finding it? What would they see anyway?
How would a camera let them read everything on your HD? But if
you securely wipe a disk *now*, you don't care if they steal it *later*.
In short, you can't set up a coherent security strategy
without first constructing a threat model.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Subject: Re: Disk Overwriting
Date: 8 Feb 2001 15:07:49 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Albert P. Belle Isle
([EMAIL PROTECTED]) wrote:
> Since, once again, we have posters authoritatively claiming either
> (1) "Disk data can be recovered from under any amount of overwriting,"
> or
> (2)"Just overwriting once with FF is sufficient to preclude recovery,"
> both of which statements are true, but only in context, it seems
> useful to once again post the following overview in an attempt to
> provide such context:
How about turning it into an official FAQ ?
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: unpredicable random number generator ?
Date: Thu, 08 Feb 2001 07:18:18 -0800
yomgui wrote:
>
> can I find the code for BBS generator on the net ?
>
> yomgui
>
The "Handbook of Applied Cryptography" web site
http://cacr.math.uwaterloo.ca/hac/
links to C code for the examples in the handbook, including examples of
cryptographically secure pseudorandom bit generators (thanks to Pate
Williams) at
http://www.mindspring.com/~pate/
and specifically for the BBS CSPRBG
http://www.mindspring.com/~pate/crypto/chap05.html
It's worthwhile downloading Chapter 5 of the HAC and reading about the
cryptographically secure pseudorandom bit generator concept (in a
nutshell, given the past history of output of a CSPRBG, there is no
algorithm running in polynomial time that can estimate the next output
bit's value with a probability negligibly greater than 1/2 - and
negligible is defined as well.)
The thread of conversation with M. K. Shen and Amaury Jacquot may be
mixing the concept of a random bit generator with a cryptographically
secure pseudorandom bit generator. Physical processes (casting dice,
radioactive decay) are not "pseudorandom." The dice and decay don't
start from a user-configurable "seed value" that allows you to
regenerate the exact same sequence of outputs (cast die value, time to
particle decay) each and every time you run the sequence of
measurements. These physical processes are not deterministic.
Physical random processes measured as random variables are not always
uniformly distributed (so some values appear more often than other
values - a bias.) The random variable values as measured may depend on
the values of the previous measurements due to the nature of the
physical process. The current value of the random variable is
conditional on past values of the random variable - a statistical
dependence. There are techniques to map the measured output of a random
physical process to other distributions (like a uniform distribution on
[0,1] to make bits.)
Hope this helps,
John A. Malley
[EMAIL PROTECTED]
------------------------------
Date: Thu, 08 Feb 2001 15:53:12 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Distributed entropy distribution
Ladies and Gentlemen, it's Alice n' Bob time again. :-)
Alice and Bob correspond regularly, using a symmetric cipher which they
designed themselves, and which they have not cryptanalysed or submitted
to sci.crypt for analysis. More fool them. Still...
They once met face-to-face, and worked out a key, Key0, between them,
using a mechanical method akin to dice.
They believe their cipher to be secure enough for rock'n'roll, and their
messages are relatively short - a few hundred bytes; but they are
worried that, if Eve[1] got hold of a /lot/ of ciphertext encrypted with
the same key, she might be able to find a crack. Therefore, they want to
change their key regularly. But they don't like the idea of sending a
new key via the old one. Instead, Alice suggests to Bob that one of them
could send the other a few bits of entropy with /each message/ (new bits
each time). Hence the thread subject line.
[1] As ever when I ask this kind of question, the threat model - Eve -
is a spotty teenager with an attitude and a packet sniffer. So perhaps
it should be Mallory instead.
So...
Let's say the key is 128 bits, or - for easy maths - 16 octets. :-)
Alice's idea is to have each message carry one octet of entropy, so that
after 16 messages the whole key has been transferred. Bob is tempted by
this idea, but suggests that they do this "out of phase", as follows:
1) In Alice's first 16 messages to Bob using Key0, she sends one octet
of entropy per message. This is Key1.
2) In the next eight messages (17-24), Alice continues to use Key0, and
still sends one octet of entropy per message. She is now "saving up" for
Key2.
3) In messages 25-32, Key1 is used, and the rest of Key2 is transmitted.
4) In messages 33-40, Key1 is used, and the first half of Key3 is
transmitted.
5) In messages 41-48, Key2 is used, and the rest of Key3 is transmitted.
6) In messages 49-56, Key2 is used, and the first half of Key4 is
transmitted.
7) In messages 57-64, Key3 is used, and the rest of Key4 is transmitted.
etc.
I'm not worried about protocol - e.g. the danger of Bob missing a
message - I can work that out, I'm sure. But can anyone spot any glaring
weaknesses in the security (apart from the homegrown algorithm, that
is!)?
Would the entropy be put to better use as a key /adjustment/ - i.e. a
sort of secret salt?
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: relative key strength private vs public key
Date: Thu, 08 Feb 2001 16:02:40 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (DJohn37050) wrote:
> Just for the record, for 256 bit AES keys, I have heard ideas that RSA
keys
> should be 20,000 bits or even more. I prefer to call the numbers I
use NIST
> numbers, as that is where they came from. It is EXACTLY because I MAY
be
> identified as anti-RSA (which I am NOT, but that is another matter)
that I
> defer to NIST and their numbers. Similarly, others may be identified
with
> other interests and results can be skewed but still be reasonable, by
always
> choosing the appropriate plausible value from the range of estimation
that gets
> the calculation to come out as one wishes.
Well the NFS is well known in it's time/space requirements (well the
estimates).
RSA provides such estimates on the following page.
http://www.rsasecurity.com/rsalabs/bulletins/twinkle.html
I suggest you read them and look at the "Sieve" size for 1024 bit
composites.
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Jirka Klaue <[EMAIL PROTECTED]>
Subject: Re: File encryption with Rijndael
Date: Thu, 08 Feb 2001 17:20:37 +0100
Amaury Jacquot wrote:
>
> your assembly language code may be cool, but won't run on my _alpha_
> processor. His Java thing, however, will (that's the point...)
>
The point is, that "his Java thing" will run on a system
with a Java-Virtual-Machine and *only* there. And there
will never be a JVM on a chip-card, for instance.
Furthermore, there is the bondage of licensing, if one
wants to implement a JVM.
Assembler, or even better ISO-C code, can easily be
ported to *any* system.
Jirka
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Pseudo Random Number Generator
Date: Thu, 08 Feb 2001 16:22:12 GMT
Minor correction: I abbreviated Uniform Random Value as UNV, when I
should have typed URV.
--
A solution in hand is worth two in the book.
Who cares about birds and bushes?
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 08 Feb 2001 16:42:19 GMT
Subject: Re: relative key strength private vs public key
Tom, I have read them. Comp Sci is FULL of instances where algorithms have
been improved and space requirements have gone down. If you want to depend on
space requirements for factoring holding you are free to do so, just do not ask
EVERYONE to do so. Each person can make his own choice. I try to be
conservative in analysis and prudent and make my choice based on the NIST
numbers, others are free to do otherwise.
Don Johnson
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Distributed entropy distribution
Date: Thu, 08 Feb 2001 16:43:10 GMT
In article <[EMAIL PROTECTED]>,
Richard Heathfield <[EMAIL PROTECTED]> wrote:
> Ladies and Gentlemen, it's Alice n' Bob time again. :-)
>
> Alice and Bob correspond regularly, using a symmetric cipher which
they
> designed themselves, and which they have not cryptanalysed or
submitted
> to sci.crypt for analysis. More fool them. Still...
>
> They once met face-to-face, and worked out a key, Key0, between them,
> using a mechanical method akin to dice.
>
> They believe their cipher to be secure enough for rock'n'roll, and
their
> messages are relatively short - a few hundred bytes; but they are
> worried that, if Eve[1] got hold of a /lot/ of ciphertext encrypted
with
> the same key, she might be able to find a crack. Therefore, they want
to
> change their key regularly. But they don't like the idea of sending a
> new key via the old one. Instead, Alice suggests to Bob that one of
them
> could send the other a few bits of entropy with /each message/ (new
bits
> each time). Hence the thread subject line.
>
> [1] As ever when I ask this kind of question, the threat model - Eve -
> is a spotty teenager with an attitude and a packet sniffer. So perhaps
> it should be Mallory instead.
>
> So...
>
> Let's say the key is 128 bits, or - for easy maths - 16 octets. :-)
>
> Alice's idea is to have each message carry one octet of entropy, so
that
> after 16 messages the whole key has been transferred. Bob is tempted
by
> this idea, but suggests that they do this "out of phase", as follows:
>
> 1) In Alice's first 16 messages to Bob using Key0, she sends one octet
> of entropy per message. This is Key1.
> 2) In the next eight messages (17-24), Alice continues to use Key0,
and
> still sends one octet of entropy per message. She is now "saving up"
for
> Key2.
> 3) In messages 25-32, Key1 is used, and the rest of Key2 is
transmitted.
> 4) In messages 33-40, Key1 is used, and the first half of Key3 is
> transmitted.
> 5) In messages 41-48, Key2 is used, and the rest of Key3 is
transmitted.
> 6) In messages 49-56, Key2 is used, and the first half of Key4 is
> transmitted.
> 7) In messages 57-64, Key3 is used, and the rest of Key4 is
transmitted.
>
> etc.
>
> I'm not worried about protocol - e.g. the danger of Bob missing a
> message - I can work that out, I'm sure. But can anyone spot any
glaring
> weaknesses in the security (apart from the homegrown algorithm, that
> is!)?
>
> Would the entropy be put to better use as a key /adjustment/ - i.e. a
> sort of secret salt?
There is much simpler solution to the problem "I don't want to encrypt
with the same key too much".
Do this.
1. Share a key0 (128-bit string or whatever), this is when they meet
face to face.
For each message:
1. Hash the msg i.e H = HASH(msg).
2. Encrypt the msg using msg_key = HASH(H || key0)
3. Transmit the ciphertext and H to the other person.
That way they have to reverse a hash function not a cipher to find your
key. I.e you can keep using your homegrown algorithm as long as you use
a secure hash like SHA or MD5 (yes MD5 would work for this purpose since
collision resistance is a side benefit as longas it's not terrible this
will work).
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Phillipine math guy claims to have fast RSA Factoring...
Date: Thu, 8 Feb 2001 09:16:20 -0700
In article <95ng3v$s1j$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> That was my initial impression, but the news article *claims* that
> there is an efficient way to solve the congruence 2^x = 1 mod N. IF
> this is true, then it can be used to factor N, and as a consequence,
> break RSA.
I suppose all of this depends a bit on what you call "efficient", but
this is the well-known discrete-log problem, and yes, there are some
methods of solving it that are more or less efficient --
specifically, more efficient than the direct search he seems to be
advocating, but less efficient than doing the factoring directly.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: relative key strength private vs public key
Date: Thu, 08 Feb 2001 17:04:16 GMT
Steve Portly wrote:
>
> In cryptographic applications a symmetric key is often negotiated and
> passed using a public key method. There is often some confusion
> concerning relative strength of RSA public keys and smaller but more
> efficient symmetric keys. As an example, I remember reading somewhere
> that a 1024 bit RSA key should be treated as having an effective
> strength of an ~80 bit symmetric key. In the ideal situation where
> one did not have to discount the effects of hash collisions does this
> correspondence continue? Specifically if we were charged with the
> task of passing a symmetric key for the following key strengths,
> ideally what strength public key should be used?
> 112 bit double DES?
> 168 bit Triple DES?
> 350 bit custom?
It depends on what PKE method you are using, and on what type of
equivilance calculation you are using.
A comparison of comparable symettric key, RSA, and ECC sizes is as
follows (copied from Joseph Ashwood's post):
Considering time equivilance only:
Symmetric | RSA n | DSA p | DSA q | ECC n
56 | 512 | 512 | 112 | 112
80 | 1024 | 1024 | 160 | 161
112 | 2048 | 2048 | 224 | 224
128 | 3072 | 3072 | 256 | 256
192 | 7680 | 7680 | 384 | 384
256 | 15360 | 15360 | 512 | 512
Considering cost equivilance (which is a measure of time+memory):
Symmetric | ECC | RSA
56 | 112 | 430
80 | 160 | 760
96 | 192 | 1020
128 | 256 | 1620
Both tables given here omit DH/ElGamal and NTRU, so if you want to use
one of them (or for that matter, any others not in the table), you'll
have to do your own research to find what size keys are equivilant.
--
A solution in hand is worth two in the book.
Who cares about birds and bushes?
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Distributed entropy distribution
Date: Thu, 8 Feb 2001 09:01:33 -0800
I can't figure out how this is logically different from using a "random"
I.V. during each keying process and encrypting the IV used with
the last state of their cipher as "last keyed" for the "next keyed"
traffic. That would be "adding entropy" regularly. Sure, you have
them cooperating to share the creation of the I.V. but it doesen't
seem all that different to me.
I'm just trying to simplify. A&B want to use one symetric key
but they want to regularly smoosh around that key. "Smoosh"
is a technical term :-)
Sounds like an I.V. would work.
Oops, Just re-read your last line, seems that you see it this
way too. I really don't see any functional difference between
the complex dance you have A&B doing and the simple
approach.
I got the feeling that someone is getting ready to "lead me to
knowledge"
Oh well.
Paul
Richard Heathfield <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Ladies and Gentlemen, it's Alice n' Bob time again. :-)
>
>
> Alice and Bob correspond regularly, using a symmetric cipher which they
> designed themselves, and which they have not cryptanalysed or submitted
> to sci.crypt for analysis. More fool them. Still...
>
> They once met face-to-face, and worked out a key, Key0, between them,
> using a mechanical method akin to dice.
>
> They believe their cipher to be secure enough for rock'n'roll, and their
> messages are relatively short - a few hundred bytes; but they are
> worried that, if Eve[1] got hold of a /lot/ of ciphertext encrypted with
> the same key, she might be able to find a crack. Therefore, they want to
> change their key regularly. But they don't like the idea of sending a
> new key via the old one. Instead, Alice suggests to Bob that one of them
> could send the other a few bits of entropy with /each message/ (new bits
> each time). Hence the thread subject line.
>
> [1] As ever when I ask this kind of question, the threat model - Eve -
> is a spotty teenager with an attitude and a packet sniffer. So perhaps
> it should be Mallory instead.
>
>
> So...
>
> Let's say the key is 128 bits, or - for easy maths - 16 octets. :-)
>
> Alice's idea is to have each message carry one octet of entropy, so that
> after 16 messages the whole key has been transferred. Bob is tempted by
> this idea, but suggests that they do this "out of phase", as follows:
>
> 1) In Alice's first 16 messages to Bob using Key0, she sends one octet
> of entropy per message. This is Key1.
> 2) In the next eight messages (17-24), Alice continues to use Key0, and
> still sends one octet of entropy per message. She is now "saving up" for
> Key2.
> 3) In messages 25-32, Key1 is used, and the rest of Key2 is transmitted.
> 4) In messages 33-40, Key1 is used, and the first half of Key3 is
> transmitted.
> 5) In messages 41-48, Key2 is used, and the rest of Key3 is transmitted.
> 6) In messages 49-56, Key2 is used, and the first half of Key4 is
> transmitted.
> 7) In messages 57-64, Key3 is used, and the rest of Key4 is transmitted.
>
> etc.
>
> I'm not worried about protocol - e.g. the danger of Bob missing a
> message - I can work that out, I'm sure. But can anyone spot any glaring
> weaknesses in the security (apart from the homegrown algorithm, that
> is!)?
>
>
> Would the entropy be put to better use as a key /adjustment/ - i.e. a
> sort of secret salt?
>
>
> --
> Richard Heathfield
> "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
> C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
> K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
