Cryptography-Digest Digest #642, Volume #14 Mon, 18 Jun 01 18:13:01 EDT
Contents:
Re: SHA2 PRNG. ("Tom St Denis")
Re: SHA2 PRNG. ("Cristiano")
Re: Is ECB truly more secure than CBC? ("Joseph Ashwood")
Re: SHA2 PRNG. ("Tom St Denis")
Re: Single-cycle sbox question ("Henrick Hellström")
Re: SHA2 PRNG. ("Cristiano")
Re: Single-cycle sbox question ("Tom St Denis")
Re: SHA2 PRNG. ("Tom St Denis")
Re: SHA2 PRNG. ("Joseph Ashwood")
Re: Counter mode, the better way to do it? (Tim Tyler)
Re: Counter mode, the better way to do it? (Tim Tyler)
Re: Counter mode, the better way to do it? ("Tom St Denis")
Re: Counter mode, the better way to do it? ("Tom St Denis")
----------------------------------------------------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: SHA2 PRNG.
Date: Mon, 18 Jun 2001 21:11:10 GMT
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:cjtX6.157080$[EMAIL PROTECTED]...
>
> "Cristiano" <[EMAIL PROTECTED]> wrote in message
> news:9glm23$739$[EMAIL PROTECTED]...
> > "Tom St Denis" <[EMAIL PROTECTED]> ha scritto:
> > .> "Cristiano" <[EMAIL PROTECTED]> wrote in message
> > .> news:9gknsa$rr0$[EMAIL PROTECTED]...
> > .> > "Tom St Denis" wrote:
> > .> > > "Cristiano" <[EMAIL PROTECTED]> wrote in message
> > .> > > news:9gj15m$fan$[EMAIL PROTECTED]...
> > .> > > > "Tom St Denis" <[EMAIL PROTECTED]> ha scritto:
> > .> > > > >
> > .> > > > > "Cristiano" <[EMAIL PROTECTED]> wrote in message
> > .> > > > > news:9gimtg$d4d$[EMAIL PROTECTED]...
> > .> > > > Now I changed the generator in this way:
> > .> > > > 1) I fill a 256 bits vector with 8 pseudorandom 32 bits
numbers;
> > .> > >
> > .> > > Careful here. You should typically bring in more bits then you
put
> > out.
> > .> > > This is because you want to make sure the amount of entropy
comming
> > in
> > .> is
> > .> > > sufficient. Let's say you bring in 256 bits from say the mouse
> > .> > co-ordinates
> > .> > > [the lsbs]. But there is a huge skew of say p=0.95 for 1 in the
> lsb,
> > .> this
> > .> > > means your 256 bits has only -256 * log2(0.95) = 19 bits of real
> > .> entropy.
> > .> > > You would need 3460 bits to get your 256 bits of entropy.
> > .> >
> > .> > Is there any empirical method that allows me to calculate how much
do
> > bits
> > .> > need?
> > .>
> > .> Typically with bits you can do say an 10-th order adaptive predictor.
> > I.e
> > .> given the past 10 bits, what is more likely to come?
> > .>
> > .> If your data is truly random it will be 0.5/0.5 either way. So you
> train
> > .> the model on your data [you will need a lot of data, say 50,000 bits
at
> > .> least] then for each new bit you add the entropy. If for example you
> > have
> > .> 0000011111 0, given the ten bits 0000011111 you look up in the model
> > which
> > .> is more likely to occur 0 or 1. Let's say P(1) = 0.95, then we know
> that
> > .> only -log2(0.95)=0.07 bits were added to the output.
> >
> > I am a bit confused. I don't understand how you can say "[...]
P(1)=0.95".
>
> > If my sequence is 0101010001111011, how much big is the entropy?
>
> Do this
>
> int counts[2][1024], state=0;
You should use "long" if you are using a 16-bit compiler
> float entropy_bit(int bit)
> {
> float p;
>
> counts[0][state] += bit;
> ++counts[1][state];
>
> p = counts[0][state] / counts[1][state];
This should be
p = (float)counts[0][state] / (float)counts[1][state];
> if (!bit) p = 1.0 - p;
> p = -log(p) / log(2.0);
>
> state <<= 1;
> state |= bit;
> state &= 1023;
> return p;
> }
>
> If this is correct, it should give you the 10-th order prediction of the
> output.
>
> Feed say 50,000 bits from your seed material [not the PRNG output] thru
> this. Then feed another 100 bits. In the last 100 bits keep a sum of the
> output of entropy_bit() [ignore the return value for the first 50,000
bits].
>
> Note: This is not the only test in the world. In fact it's possible to
pass
> this and still be insecure.
To add to this. Technically a oo-order predictor like this will give you the
"exact" entropy. Since oo-order is not possible higher orders will have to
suffice.
Basically what a n-order predictor like this will tell you is whether or not
the past n bits are a good predictor of the next bit or not. If the source
is random it will be hit and miss which means the prob will be 0.50 [or 1
bit]. If given the past n bits the next bit is biased this will show up.
Typically you have to "train" the model first. This means you have to gain
significant data to make the model work. [try summing the entropy_bit()
before training the model]. I would suggest a rule of thumb as at least
5*2^n bits. [this comes from Knuth]. But typically the more the better.
I have a program
http://tomstdenis.home.dhs.org/src/ent.c
You can try on files. You will see often [even zip files] files have lower
entropy then you think.
You can change the order of the model by changing the # of bits. Try
replacing "&= 1023" with "&= 255" and note the difference.
Have fun and good luck!
Tom
------------------------------
From: "Cristiano" <[EMAIL PROTECTED]>
Subject: Re: SHA2 PRNG.
Date: Mon, 18 Jun 2001 23:05:46 +0200
"Tom St Denis" <[EMAIL PROTECTED]> ha scritto
> > If my sequence is 0101010001111011, how much big is the entropy?
>
> Do this
>
> int counts[2][1024], state=0;
>
> float entropy_bit(int bit)
> {
> float p;
>
> counts[0][state] += bit;
> ++counts[1][state];
>
> p = counts[0][state] / counts[1][state];
> if (!bit) p = 1.0 - p;
> p = -log(p) / log(2.0);
>
> state <<= 1;
> state |= bit;
> state &= 1023;
> return p;
> }
>
> If this is correct, it should give you the 10-th order prediction of the
> output.
This code doesn't work in my computer.
I modified the code in this way (double is not necessary):
static int counts[2][1024], state=0;
double entropy_bit(const int bit)
{
counts[0][state] += bit; ++counts[1][state];
double p = counts[0][state] /(double)counts[1][state];
if (!bit) p = 1.0 - p;
p = -log(p) / log(2.0);
state <<= 1; state |= bit; state &= 1023;
return p;
}
I think that count[2][1024] must be initialized to 0.
> Feed say 50,000 bits from your seed material [not the PRNG output] thru
> this. Then feed another 100 bits. In the last 100 bits keep a sum of the
> output of entropy_bit() [ignore the return value for the first 50,000
bits].
My seed material is a very good prng (MT19937 by Makoto Matsumoto and Takuji
Nishimura).
I feed 50000 bits of MT19937 and then I feed another 100 bits and I do
entropy+=entropy_bit(bit[i]) (i from 1 to 100).
In this way "entropy" sum is around 48700. Is this good?
What's the meaning of 1023 and 1024 constants? Can I modify them?
Thank you very much
Cristiano
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
Date: Mon, 18 Jun 2001 14:11:32 -0700
I was making some assumptions regarding the level of computational ability
available. It is certainly arguable that you only need 1 known pair to
attack 3DES (brute force attack). At the other extreme knowing 2^64 unique
pairs gives you the entire permuatation table. Each of the major attacks on
3DES requires a certain amount of RAM to mount the attack in a certain
amount of time, I picked what I considered a fair balance for the argument.
Off hand I don't remember which attack in particular I had chosen, but both
of the best key-recovery attacks on 3DES can be parameterized to behave the
way I exploited.
Joe
"Nomen Nescio" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> > The example should be fairly familiar to everyone here; encrypting XML
with
> > 3DES is weaker under a key recovery attack when using CBC than it is
with
> > ECB. To prove this you need to know that the key recovery attacks on
3DES
> > take knowledge of > 2^56 known pairs.
>
> So what exactly is the key recovery attack on 3DES that takes > 2^56
> known plaintexts?
>
> The standard references say that a brute force key recovery attack on 3DES
> takes roughly 2^112 work and 2^56 blocks of memory. Presumably this can
> work with as few as 3 known plaintexts, to provide enough redundancy to
> determine the key. They don't mention an advantage being available by
> having access to 2^56 known plaintexts.
>
> How does this supposed 2^56 known plaintext 3DES attack work? How much
> compute time does it take, how much memory?
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: SHA2 PRNG.
Date: Mon, 18 Jun 2001 21:28:51 GMT
"Cristiano" <[EMAIL PROTECTED]> wrote in message
news:9glqk7$85p$[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> ha scritto
> > > If my sequence is 0101010001111011, how much big is the entropy?
> >
> > Do this
> >
> > int counts[2][1024], state=0;
> >
> > float entropy_bit(int bit)
> > {
> > float p;
> >
> > counts[0][state] += bit;
> > ++counts[1][state];
> >
> > p = counts[0][state] / counts[1][state];
> > if (!bit) p = 1.0 - p;
> > p = -log(p) / log(2.0);
> >
> > state <<= 1;
> > state |= bit;
> > state &= 1023;
> > return p;
> > }
> >
> > If this is correct, it should give you the 10-th order prediction of the
> > output.
>
> This code doesn't work in my computer.
> I modified the code in this way (double is not necessary):
>
> static int counts[2][1024], state=0;
> double entropy_bit(const int bit)
> {
> counts[0][state] += bit; ++counts[1][state];
> double p = counts[0][state] /(double)counts[1][state];
> if (!bit) p = 1.0 - p;
> p = -log(p) / log(2.0);
> state <<= 1; state |= bit; state &= 1023;
> return p;
> }
>
> I think that count[2][1024] must be initialized to 0.
global statics are zeroed by default.
> > Feed say 50,000 bits from your seed material [not the PRNG output] thru
> > this. Then feed another 100 bits. In the last 100 bits keep a sum of
the
> > output of entropy_bit() [ignore the return value for the first 50,000
> bits].
>
> My seed material is a very good prng (MT19937 by Makoto Matsumoto and
Takuji
> Nishimura).
> I feed 50000 bits of MT19937 and then I feed another 100 bits and I do
> entropy+=entropy_bit(bit[i]) (i from 1 to 100).
> In this way "entropy" sum is around 48700. Is this good?
Hmm? You can't get 48700 since the sum at most outputs 1.00 +/-
small_small_error.
Show me how you are using entropy_bit.
perhaps you *do* have to zero the state [in C it should be zeroed already].
> What's the meaning of 1023 and 1024 constants? Can I modify them?
1024 = 2^10 = 10th order.
Tom
------------------------------
From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Re: Single-cycle sbox question
Date: Mon, 18 Jun 2001 23:39:29 +0200
"Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
news:DStX6.157428$[EMAIL PROTECTED]...
>
> "Henrick Hellström" <[EMAIL PROTECTED]> wrote in message
> > Oh, that's one of the reasons why I strongly discourage anyone from
using
> C.
> > ;-)
>
> Why? You can write bad code in any language.
Sure you can. But in my opinion you are encouraged to do so in C. The code
that is fastest, most compact or easiest to read, is usually not one and the
same in C. It was in Standard Pascal. (This is just an opinion of course,
but I doubt I am the only one who believe this.)
> > One line double assignments like that aren't logical and tend to result
in
> > extremely messy code (in particular if they are mixed with post/pre
> > in/decrements). In my opinion, an assignment is an instruction and not
an
> > expression. If it should have any value at all, it should be the address
> of
> > the code it corresponds to.
>
> Not really...
>
> a=b=c=d=e=f=g=0;
>
> Much better than
>
> a=0;
> b=0;
> c=0;
> d=0;
> e=0;
> f=0;
> g=0;
I suggest that you should write either:
Let a, b, c, d, e, f, g be such that a=b=c=d=e=f=g=0
or
Let a <- 0; b <- 0; c <- 0; d <- 0; e <- 0; f <- 0; g <- 0;
if you are writing pseudo code in some more formal context.
My point of view regarding multiple assignments in the same statement still
stands. It is not coherent with several programming languages to presume
that assignments evaluate to the right hand value. In Standard Pascal you
would get a compiler error. In some languages I believe that "a = 0" would
evaluate to a pointer to the machine code instruction. In many Basic
dialects "a = b = 0" would be equalivalent to "if b = 0 then a = -1 else a =
0"
--
Henrick Hellström [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: "Cristiano" <[EMAIL PROTECTED]>
Subject: Re: SHA2 PRNG.
Date: Mon, 18 Jun 2001 23:39:51 +0200
> > I feed 50000 bits of MT19937 and then I feed another 100 bits and I do
> > entropy+=entropy_bit(bit[i]) (i from 1 to 100).
> > In this way "entropy" sum is around 48700. Is this good?
>
> Hmm? You can't get 48700 since the sum at most outputs 1.00 +/-
> small_small_error.
>
> Show me how you are using entropy_bit.
>
> perhaps you *do* have to zero the state [in C it should be zeroed
already].
Now I go to sleep (here is about midnight) :-)
The result range is about 98-102. It is good?
Cristiano
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Single-cycle sbox question
Date: Mon, 18 Jun 2001 21:49:14 GMT
"Henrick Hellström" <[EMAIL PROTECTED]> wrote in message
news:9glsci$c5h$[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
> news:DStX6.157428$[EMAIL PROTECTED]...
> >
> > "Henrick Hellström" <[EMAIL PROTECTED]> wrote in message
> > > Oh, that's one of the reasons why I strongly discourage anyone from
> using
> > C.
> > > ;-)
> >
> > Why? You can write bad code in any language.
>
> Sure you can. But in my opinion you are encouraged to do so in C.
Says you. My mentor always made me write clearly indented code with
comments and clever variable names.
> The code > that is fastest, most compact or easiest to read, is usually
not one and the
> same in C.
Again my mentor had a nack for very good and efficient code. He also wrote
the simplest code I have ever seen.
> I suggest that you should write either:
>
> Let a, b, c, d, e, f, g be such that a=b=c=d=e=f=g=0
I though we were discussing programming langauges.
I would just say let <a,b,c,d,e,f,g> be the null vector.
> or
>
> Let a <- 0; b <- 0; c <- 0; d <- 0; e <- 0; f <- 0; g <- 0;
>
> if you are writing pseudo code in some more formal context.
>
> My point of view regarding multiple assignments in the same statement
still
> stands. It is not coherent with several programming languages to presume
> that assignments evaluate to the right hand value. In Standard Pascal you
> would get a compiler error. In some languages I believe that "a = 0" would
> evaluate to a pointer to the machine code instruction. In many Basic
> dialects "a = b = 0" would be equalivalent to "if b = 0 then a = -1 else a
=
> 0"
In standard pascal you can write
function myfunction: real;
var
c, b:integer;
function someother(b:integer): integer;
var a, c: integer;
begin
a := 3;
for c := 0 to b do a := a + a;
someother := a;
end;
begin
b := 0;
for c := 0 to 34 do
b := b + someother(c+b);
myfunction := real(b);
end;
Tell me that's good coding style !!!
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: SHA2 PRNG.
Date: Mon, 18 Jun 2001 21:50:31 GMT
"Cristiano" <[EMAIL PROTECTED]> wrote in message
news:9glsh8$8mo$[EMAIL PROTECTED]...
> > > I feed 50000 bits of MT19937 and then I feed another 100 bits and I do
> > > entropy+=entropy_bit(bit[i]) (i from 1 to 100).
> > > In this way "entropy" sum is around 48700. Is this good?
> >
> > Hmm? You can't get 48700 since the sum at most outputs 1.00 +/-
> > small_small_error.
> >
> > Show me how you are using entropy_bit.
> >
> > perhaps you *do* have to zero the state [in C it should be zeroed
> already].
>
> Now I go to sleep (here is about midnight) :-)
> The result range is about 98-102. It is good?
Yes. You will get 102 (>100 assuming you use 100 bits) due to rounding
errors. Try 1000 bits instead. Sorry I shouldn't have said 100.
But yes if your PRNG seed material gets 1 bit of entropy per bit that means
you can use your SEED material as PRNG output.
What are you using for your SEED material?
Tom
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: SHA2 PRNG.
Date: Mon, 18 Jun 2001 14:48:40 -0700
"Cristiano" <[EMAIL PROTECTED]> wrote in message
news:9gimtg$d4d$[EMAIL PROTECTED]...
> I need a cryptographically secure prng.
Ok. That's doable.
> To such purpose I fill a 256 bits vector with 8 pseudorandom 32 bits
numbers
> and then:
Not good. You should be feeding it numbers from a source of true randomness.
Position of the mouse what keys are typed, when things hit the network
interface, how long each read/write from/to the HD takes, the screen buffer,
and just about anything else you can think of.
> 1) I hash the vector and I store the result in the same vector;
> 2) I get the 8 numbers;
> 3) go to step 1.
It would probably be better to implement an additional function
hashStateDuplicate(...) that copies the state of the hash into another
memory location. Use this like this:
generate_random_number(...)
{
static long long count = 0;
//put more data into a global hash1
hashStateDuplicate(hash1, hash2)
hashAdd(hash2, count++);
//return value from hash2
}
You should also have a periodic update that occurs regardless where you
sample your random sources and add those into hash1.
> Any comment?
The tests you perform won't mean much. Because SHA-256 gives outputs like a
very good hash it is highly likely that even if you were to hash just a
counter it would pass most general purpose tests, but would always fail a
cryptanalytic attack (one where they know that you hash a counter). You
might also consider only taking a portion of the hash result, this will make
cryptanalysis much more difficult.
Joe
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Counter mode, the better way to do it?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 18 Jun 2001 21:49:47 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> : "Julian Morrison" <[EMAIL PROTECTED]> wrote in message
:> :> Two approaches I've seen to doing CNT mode for Rijndael:
:>
:> :> - use the raw count, say a 32 bit unsigned int in one quad of bytes and
:> :> the 12 remaining bytes as 0x00. [...]
:> :>
:> :> - feed the count through a scrambling function first, such as MD5.
:> :>
:> :> Which is safer and better?
:>
:> : In a good cipher.....neither.
:>
:> I presume that use of a hash would help eliminate the CTR mode proviso
:> that you change keys before you've transmitted sqrt(2^blocksize) blocks.
: I don't see how the birthday paradox applies to this case. Pairs of known
: texts will not lead to knowing the output as far as I know.
The suspicious absence of repeated blocks allows the stream to be
distinguished from a random one. Deviations from randomness will
slowly leak information about the plaintext.
:> However if you *do* want to avoid it, you could do something like instead
:> of adding 1, add an odd constant with roughly the same number of 1 and 0
:> bits set in it, and rather than padding with 0s, duplicate the counter
:> across the block size. These are not expensive operations to perform -
:> in contrast to hashing - which has a large cost.
: Adding a constant doesn't change the situation much from the naive pov. The
: attacker still knows the inputs.
Sorry, yes. I was thinking of the structure as a RNG, where the
counter may not be known.
--
__________
|im |yler http://rockz.co.uk/ http://alife.co.uk/ http://atoms.org.uk/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Counter mode, the better way to do it?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 18 Jun 2001 21:54:09 GMT
Julian Morrison <[EMAIL PROTECTED]> wrote:
: Two approaches I've seen to doing CNT mode for Rijndael:
: - use the raw count, say a 32 bit unsigned int in one quad of bytes and
: the 12 remaining bytes as 0x00. But feeding that much known plaintext into
: a cipher function on every single block looks scary to me.
: - feed the count through a scrambling function first, such as MD5.
If you're going to apply a hash, I think applying it after encryption
would be more effective.
If you apply it first, the attacker still gets plaintext/cyphertext pairs
- so the only difference is that the known plaintexts that you give the
attacker don't differ in only a few bits from one another, and are thus
perhaps slightly less likely to be useful.
If you apply it afterwards, the cypher's output is protected by the hash.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Counter mode, the better way to do it?
Date: Mon, 18 Jun 2001 22:05:11 GMT
"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> :> Tom St Denis <[EMAIL PROTECTED]> wrote:
> :> : "Julian Morrison" <[EMAIL PROTECTED]> wrote in message
>
> :> :> Two approaches I've seen to doing CNT mode for Rijndael:
> :>
> :> :> - use the raw count, say a 32 bit unsigned int in one quad of bytes
and
> :> :> the 12 remaining bytes as 0x00. [...]
> :> :>
> :> :> - feed the count through a scrambling function first, such as MD5.
> :> :>
> :> :> Which is safer and better?
> :>
> :> : In a good cipher.....neither.
> :>
> :> I presume that use of a hash would help eliminate the CTR mode proviso
> :> that you change keys before you've transmitted sqrt(2^blocksize)
blocks.
>
> : I don't see how the birthday paradox applies to this case. Pairs of
known
> : texts will not lead to knowing the output as far as I know.
>
> The suspicious absence of repeated blocks allows the stream to be
> distinguished from a random one. Deviations from randomness will
> slowly leak information about the plaintext.
Yeah you get
P(L: right) = 1 / (2^W - L)
Where L is the # of known blocks and W is the block size.
So if you use AES and know 1,073,741,824 blocks of output your advantage
should be about 2^-127.999.
This assumes there is no attack for L blocks.
> :> However if you *do* want to avoid it, you could do something like
instead
> :> of adding 1, add an odd constant with roughly the same number of 1 and
0
> :> bits set in it, and rather than padding with 0s, duplicate the counter
> :> across the block size. These are not expensive operations to perform -
> :> in contrast to hashing - which has a large cost.
>
> : Adding a constant doesn't change the situation much from the naive pov.
The
> : attacker still knows the inputs.
>
> Sorry, yes. I was thinking of the structure as a RNG, where the
> counter may not be known.
Oh, even in a PRNG like Yarrow the counter is not private. In both cases
[Yarrow and CTR, which are in fact the same mode of operation] the key is
the private information.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Counter mode, the better way to do it?
Date: Mon, 18 Jun 2001 22:05:53 GMT
"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Julian Morrison <[EMAIL PROTECTED]> wrote:
>
> : Two approaches I've seen to doing CNT mode for Rijndael:
>
> : - use the raw count, say a 32 bit unsigned int in one quad of bytes and
> : the 12 remaining bytes as 0x00. But feeding that much known plaintext
into
> : a cipher function on every single block looks scary to me.
>
> : - feed the count through a scrambling function first, such as MD5.
>
> If you're going to apply a hash, I think applying it after encryption
> would be more effective.
>
> If you apply it first, the attacker still gets plaintext/cyphertext pairs
> - so the only difference is that the known plaintexts that you give the
> attacker don't differ in only a few bits from one another, and are thus
> perhaps slightly less likely to be useful.
>
> If you apply it afterwards, the cypher's output is protected by the hash.
You might as well just use a hash in CTR mode.
Tom
------------------------------
** 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
******************************
