Cryptography-Digest Digest #606, Volume #14      Wed, 13 Jun 01 16:13:00 EDT

Contents:
  Re: Simple Crypto II, the public key... (Mark Wooding)
  ?? (Mykhailo Lyubich)
  Re: The 94 cycle 64-bit block cipher :-) (Tom St Denis)
  Re: OTP WAS BROKEN!!! (Tim Tyler)
  Re: Simple Crypto II, the public key... (Tom St Denis)
  Re: Sophie-Germain Primes for sale (Tom St Denis)
  Re: Uniciyt distance and compression for AES ([EMAIL PROTECTED])
  Re: The 94 cycle cipher (Tom St Denis)
  Looking for Mitsuru Matsui paper (Tom St Denis)
  Re: Uniciyt distance and compression for AES ([EMAIL PROTECTED])
  Re: IV ("Cristiano")
  Re: Sophie-Germain Primes for sale (John Savard)
  Re: Alice and Bob Speak MooJoo (David A Molnar)
  Re: Sophie-Germain Primes for sale ("Joseph Ashwood")
  Re: Sophie-Germain Primes for sale ("Tom St Denis")
  Re: fast CTR like ciphers? (jlcooke)
  Re: curious about MD3 (jlcooke)
  Re: Simple Crypto II, the public key... (Fat Phil)
  Re: curious about MD3 ("Tom St Denis")
  Re: Uniciyt distance and compression for AES (SCOTT19U.ZIP_GUY)
  Re: IV (SCOTT19U.ZIP_GUY)
  Re: ?? (jlcooke)

----------------------------------------------------------------------------

From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Simple Crypto II, the public key...
Date: 13 Jun 2001 17:21:21 GMT

Phil Carmody <[EMAIL PROTECTED]> wrote:
> Vincent Quesnoit wrote:
>
> > int mod_pow(int ch, int exp, int modulo)
> > {
> >         int i, result,power;
> >         result = 1;
> >         power = ch;
> >         while (exp !=0){
> >             if ((exp & 1)==1) {
> >                 result = (result * Power) % modulo;
> >             }
> >             Power = (Power *Power)% modulo;
> >             exp >>=1;
> >         }
> >         return result;
> > }
> 
> I'm a 'right-to-left' man myself.

Good, because the algorithm above is right-to-left.

I'm a left-to-right man.  The basic algorithms are very similar in terms
of efficiency, but right-to-left is the end of the road, whereas there
are all sorts of clever things you can do with left-to-right (sliding
window exponentiation, simultaneous exponentiation...)

-- [mdw]

------------------------------

From: Mykhailo Lyubich <[EMAIL PROTECTED]>
Subject: ??
Date: Wed, 13 Jun 2001 19:28:54 +0200

Hi,

is this list suitable to post a protocol description/question?


--
Mykhailo Lyubich



------------------------------

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: The 94 cycle 64-bit block cipher :-)
Date: Wed, 13 Jun 2001 17:29:16 GMT

Phil Carmody wrote:
> 
> Tom St Denis wrote:
> > Well I feel honoured that you are archiving my stuff :-)  Feel free to
> > download/repost/edit/whatever anything on my site.  You can take my source
> > and redistribute it if you want.  (That's the point of sharing ya know :-0).
> 
> Sharing is good. Readers contributing back is even better.
> 
> > I would appreciate comments on my upcomming ideas though.  Even if you don't
> > have something rigorous more than "oh neat".  It's nice to just hear from
> > others.
> 
> Upcoming? Hmmm, I'd rather rewind the clock a few months if I may :-)
> 
> I'm curious about your 3-hash actually.
> <<<
>     for (r = 16; r < SIZE; r++) {
>         t = W[r - 3] ^ W[r - 8] ^ W[r - 14] ^ W[r - 16] ^ r ^
> 0x9E379B93ul;
>         W[r] = (t << 1ul) | (t >> 31ul);
>     }
> >>>
> 
> The ^r seems to be added to add a little more non-linearity, an the
> ^0x9E379B93ul seems to add some noise to those cases over-populated with
> zeros.
> However, the ^r only touches the bottom 7 bits (or thereabouts)
> 
> Assuming x86 has a nice fast integer multiply, wouldn't
> ^(r*0x9E379B93ul)
> do a better job, potentially touching all bits?

Yes it would.  I used ^r for speed.  Admittedly I stole that scheme from
Serpent.  The ^r is actually not required at all.

> I'm also curious - why aren't the well-known CRC algorithms used as
> hashes? Is it that they aren't one-way? (they look reversable, but I've
> not studied them closely). Or is it just that they are too short, and if
> they were make longer they'd take too long to actually get all the bits
> mixed up? (so would be useless for a short message)

CRC's typically are only 32-bits wide.  A collision can be found with
2^16 CRCs

Tom

------------------------------

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: OTP WAS BROKEN!!!
Reply-To: [EMAIL PROTECTED]
Date: Wed, 13 Jun 2001 16:56:23 GMT

Jim D <[EMAIL PROTECTED]> wrote:
: Charles Lyttle <[EMAIL PROTECTED]> wrote:

:>The second biggest problem with OTP is that it is very
:>difficult to get a large quantity of true random numbers. 

: Doesn't have to be. Need only be random enough so the cryptanalyst
: can't/is unlikely to be able to predict the next key byte.

That depends on what the cryptanalyst is tring to do.  If he's tring to
read a message from scratch - maybe.  If he's trying to reject the
possibility tha a message represents a given plaintext, a slight bias
can be enough to help him out.
-- 
__________
 |im |yler  [EMAIL PROTECTED]  Home page: http://alife.co.uk/tim/

------------------------------

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Simple Crypto II, the public key...
Date: Wed, 13 Jun 2001 17:32:23 GMT

Phil Carmody wrote:
> 
> Tom St Denis wrote:
> >
> > "John Savard" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > On Tue, 12 Jun 2001 23:04:40 GMT, "Tom St Denis"
> > > <[EMAIL PROTECTED]> wrote, in part:
> > >
> > > >How do you cheat with "mod operations"?  I have a list of good DH primes
> > if
> > > >you want
> > >
> > > Well, if P is 2^n-1, one can perform modulo arithmetic without long
> > > division. I don't know if a prime can be Mersenne and Sophie Germain
> > > at the same time, though.
> 
> (2^n+/-c)/d for small c and d are good primes for this.
> 
> > Ah but the # of good primes of the form 2^n - 1 is few.  i dunno of any good
> > ~1024 bit primes of that form.
> >
> > Of course [for anyone in the dark] a mod operation with these modulos is
> > just a shift right n bits and an addition.
> >
> > So "mod 255" would be
> >
> > a = ((a >> 8) + a) & 255;
> 
> Stick 65535 into that :-)

65535 cannot be the product of two #'s less than 255.

> 
> > In C... so you could do a mult like
> >
> > a = b * c;
> > a = ((a >> 8) + a) & 255;
> 
> a=(a&255) + (a>>8);
> twice.
> and then turn 255s into 0.
> 
> However, if you're doing this repeatedly, just accumulate the carries
> 
> Anyway, this is the cheating I'm thinking of.
> 
> Cor I'm full of questions... (and this groups is brilliant for answers,
> thanks!) here comes another!
> 
> How are these good 'DH' primes (Diffie Hellman) related to use in
> ElGamal? Is it the same class of primes, it's just that the name 'DH'
> stuck? If so, what makes a good DH prime? As I was on the topic of
> 'minimal' algorithms - what makes a _bad_ DH prime?

The technical name in general is DLP, i.e the Discrete Logarithm
Problem.  Given g,y and p find 'x' in y=g^x mod p.

Both ElGamal and DH are as hard as finding the DL [or is this just
assumed?  afaik it's true].

Therefore in either case large sub-groups are desirable.

Tom

------------------------------

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Sophie-Germain Primes for sale
Date: Wed, 13 Jun 2001 17:34:52 GMT

Mark Wooding wrote:
> 
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > David Hopwood wrote:
> > > Tom St Denis wrote:
> > >
> > > > A SG prime is of the form p = 2q + 1, where q itself is prime and of
> > > > course p mod 4 = 3.
> > >
> > > No. It's not two weeks since I last corrected you on this (message ID
> > > <[EMAIL PROTECTED]>).
> > >
> > > If p = 2q + 1 for p and q both prime, then q is a Germain prime, and
> > > p is a safe prime. Also it is not part of the definition that p = 3
> > > (mod 4) (counterexample: p = 5, q = 2, although admittedly that is
> > > the only counterexample).
> >
> > Ok.  Well if you checked the numbers you would realize they are all 3
> > mod 4.
> 
> Learn to read.
> 
> The correction is that, when p = 2 q + 1 with p and q prime, it's *q*
> which is the Sophie Germain prime.  We in the crypto community call p a
> `safe' prime, though I don't believe it has a name among general
> mathematicians.

I don't get why.  q is just any prime (even a 'safe' one itself).  I
thought SG referred to p which is what I'm interested in anyways.

> You're right that if q is odd then p = 2 q + 1 = 3 (mod 4).  That's why
> David said that 5 is the only safe prime not congruent to 3 (mod 4).
> 
> > When I said "and of course p mod 4 = 3" I meant "of course I made them
> > such that ...", although I can see how that could have been misleading.
> 
> You couldn't have made nontrivial safe primes to have any other residue
> mod 4.

Rightly so which is why I forced the two bits to 1.

Tom

------------------------------

From: [EMAIL PROTECTED]
Subject: Re: Uniciyt distance and compression for AES
Date: Wed, 13 Jun 2001 08:40:03 -0800

Tim Tyler wrote:
> 

> Here is the model I think you should have adopted:
> 
>   Alice -> [encrypt] -> ...eve... -> [decrypt] -> Bob
> 
> Unicity distance is as measured by Eve.
> 
> We are interested in the effect of replacing [encrypt] and [decrypt]
> by [compress encrypt] and [decrypt decompress] respectively.
> 
> What you have done is not /just/ make changes to the stages represented
> inside square brackets.

> You have made fundamental changes to the set of messages which are sent
> and their probabilities. 


How is this avoidable if messages are compressed from n=4 to n=3?
There are 16 possible messages before compression and 8 possible after
compression.

 Your system after the compressor is added can't
> even transmit some messages that were transmitted before - and *all* the
> probabilities of the messages occurring are changed!

This isn't surprising. Can *any* compressor compress *all* possible
messages in the original message space?

> Why should putting in a compressor affect the frequency of the messages
> being sent?  It should not.
> 
> If you /must/ use a lossy compressor at least set the probability of
> messages it can't handle to be 0 initially, or you are comparing different
> systems with different message spaces.

Again, doesn't one *have* to compare different message spaces since the
value of n is different after compression??

> Also, do not change the probabilities of the messages occurring, or else
> you are comparing entropies in very different systems - and it is no
> suprise that your unicity distances are all over the map.

The probabilities in the original message space are what they are. If
they
are non-zero then assigning them zero probability isn't an option;
*that* would
be altering the message space. If a compressor does compress a low
probability
message, then it must be included in the message space whether or not
it is encrypted because it is a possible decryption with a randomly
chosen key.


All the probabilities in my compressed message spaces sum to one and
retain
the original ratios as the original message space i.e. p(000)=2p(111) if
p(0000)=2*p(1111).
I wasn't sure I had those right but that's the only way that makes sense
to me.

Propose other probabilities.

------------------------------

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: The 94 cycle cipher
Date: Wed, 13 Jun 2001 17:37:44 GMT

Phil Carmody wrote:
> 
> Tom St Denis wrote:
> >
> > If anyone is interested you can get a copy of the 94 cycle cipher (94 cycles
> > on an Athlon).  at
> >
> > http://tomstdenis.home.dhs.org/tc16.zip
> >
> > It uses the quadratic and rotation as the Feistel round function.
> 
> It's certainly short.
> Any reason why you do
>   xor edi, eax
>   mov eax, edi
> rather than
>   xor eax, edi
>   mov edi, eax
> at the conjunction of two rounds? It's a simply replacing one of the 2
> read-after-writes with a write-after-read.

The idea was just to hack off some code to test the idea.  I didn't
spend a lot of time on it.  

> You're computation bound so that the above probably has little or no
> real effect on an out-of-order processor. However I'm sure that you
> could trivially do two blocks in almost the same time as you do 1!
> Remember that there are 32x32->32 multiply instructions in the >386 with
> any register as the destination.

That's only IMUL IIRC.

Tom

------------------------------

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Looking for Mitsuru Matsui paper
Date: Wed, 13 Jun 2001 18:02:21 GMT

A while back Matsui did a paper on a new feistel design and had some
analysis of cubic and inverse functions in GF(2^x).  

Does anyone know where I can find that paper?  Matsui doesn't have a
website!

Tom

------------------------------

From: [EMAIL PROTECTED]
Subject: Re: Uniciyt distance and compression for AES
Date: Wed, 13 Jun 2001 09:37:20 -0800

"SCOTT19U.ZIP_GUY" wrote:

> 
> ... but here in simple terms here is why
> your wrong. You state that 1/32 are the meaningless messages. The point
> is you only encrypt meaningful messages. So if I rescale you propabilites
> and change 1/32 to "zero" now I have a message space with messages and
> meaningless data.

Even though only meaningful messages are encrypted, meaningless
messages must be included in the compressed message space if it
is possible to compress a meaningless message with the compressor.
A decryption with a randomly chosen key may produce this meaningless
compressed value.

------------------------------

From: "Cristiano" <[EMAIL PROTECTED]>
Subject: Re: IV
Date: Wed, 13 Jun 2001 20:36:20 +0200

"Tim Tyler" <[EMAIL PROTECTED]> ha scritto nel messaggio
news:[EMAIL PROTECTED]...
> :> That means identical plaintexts (at those offsets) will result in
> :> identical cyphertexts.
>
> : Yes. [...] could you tell me if is there any weakness in my method?
>
> The fact that identical plaintext blocks (every N bytes) will result in
> identical cyphertexts /is/ a weakness - if not an earth shattering one.
>
> An attacker who observed repeated blocks at those intervals can tell that
> the plaintext repeated itself.  He should not be able to do this.

In this sense also ECB mode is a weakness.

Cristiano



------------------------------

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Sophie-Germain Primes for sale
Date: Wed, 13 Jun 2001 19:00:21 GMT

On Wed, 13 Jun 2001 17:34:52 GMT, Tom St Denis <[EMAIL PROTECTED]>
wrote, in part:
>Mark Wooding wrote:

>> The correction is that, when p = 2 q + 1 with p and q prime, it's *q*
>> which is the Sophie Germain prime.  We in the crypto community call p a
>> `safe' prime, though I don't believe it has a name among general
>> mathematicians.

>I don't get why.  q is just any prime (even a 'safe' one itself).  I
>thought SG referred to p which is what I'm interested in anyways.

Well, q isn't just any prime: not every prime p is such that 2p + 1 is
prime, any more than every prime p is such that (p-1)/2 is prime.

I made the same mistake myself on my web site, and have corrected it
after confirming that this is indeed the real definition of a Sophie
Germain prime.

2q+1 is special because it's safer for use with Diffie-Hellman.

But q is special too: long before Andrew Wiles, it was possible to
prove that a^q + b^q = c^q had no solutions for positive integers a,
b, and c for q of that type - and that's what Sophie Germain did,
which made her, and those primes, famous.

John Savard
http://home.ecn.ab.ca/~jsavard/frhome.htm

------------------------------

From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Alice and Bob Speak MooJoo
Date: 13 Jun 2001 18:51:46 GMT

Robert J. Kolker <[EMAIL PROTECTED]> wrote:

>> are inaccessible to her - then *why* would she *want* to listen to Alice
>> and Bob? and if she *can*, doesn't that destroy the claimed
>> "security-through-inaccessible-referent" ?

> If Eve listned in she has no way of knowing what Alice and
> Bob are saying to each other. So the communication between
> Alice and Bob is secure. From Eve's p.o.v. she is getting
> noise from the A/B link.

I think the issue here is in the model, then. Normally we say Eve has 
access only to the communication between Alice and Bob. As you point out, 
given these assumptions about language, this means Eve gets noise as long 
as she cannot observe Alice and Bob's referents. 

Except in the real world, Eve may observe some referents of Alice and Bob.
Troop movements, stock prices, whatever. Alice and Bob have to talk about
*something*, since the claim is that all language must refer to
*something*. So is this something accessible to Eve "in the real world" or
is it not?

If it is accessible, then Eve can learn to speak MooJoo.
If it is not accessible, then what's the point of Eve observing Alice and 
Bob? They won't affect her anyway; any effect they might have would create 
a referent which would allow Eve to start learning MooJoo.

So the model of Eve having access only to Alice and Bob's talk seems 
possibly too restrictive to be useful here. 

-David


------------------------------

From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Sophie-Germain Primes for sale
Date: Wed, 13 Jun 2001 12:02:21 -0700


"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (David Hopwood) wrote in
> <[EMAIL PROTECTED]>:
>
> >-----BEGIN PGP SIGNED MESSAGE-----
> >
> >Tom St Denis wrote:
> >
> >May I suggest that before posting anything else involving number theory
> >or abstract algebra, you check the definitions first (for example in HAC
> >or AC2), and also that you pay more attention when people correct you?
> >
>
>    Good Luck hes an arragant kid who seldom listens. Next for spouting
> facts his mind can't grasp he will call you a loon or something along
> those lines. Best just to ignore him for awhile and hope he either
> goes aways or grows up.

My experience with him has been quite contrary to that. Like most people if
you can make your point clearly and concisely, without attempting to judge
him instead of the information, he will very often pay attention. However if
you don't clearly state the problem, like most people he simply ignores what
was said.

With that said, I'm sure Tom understands now that the p=3 mod 4 check is
unnecessary because the only prime p = 2q+1 (for prime q) that is not 3 mod
4 is 5.
                    Joe



------------------------------

From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Sophie-Germain Primes for sale
Date: Wed, 13 Jun 2001 19:26:02 GMT


"Joseph Ashwood" <[EMAIL PROTECTED]> wrote in message
news:eJXiHwD9AHA.269@cpmsnbbsa07...
>
> "SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > [EMAIL PROTECTED] (David Hopwood) wrote in
> > <[EMAIL PROTECTED]>:
> >
> > >-----BEGIN PGP SIGNED MESSAGE-----
> > >
> > >Tom St Denis wrote:
> > >
> > >May I suggest that before posting anything else involving number theory
> > >or abstract algebra, you check the definitions first (for example in
HAC
> > >or AC2), and also that you pay more attention when people correct you?
> > >
> >
> >    Good Luck hes an arragant kid who seldom listens. Next for spouting
> > facts his mind can't grasp he will call you a loon or something along
> > those lines. Best just to ignore him for awhile and hope he either
> > goes aways or grows up.
>
> My experience with him has been quite contrary to that. Like most people
if
> you can make your point clearly and concisely, without attempting to judge
> him instead of the information, he will very often pay attention. However
if
> you don't clearly state the problem, like most people he simply ignores
what
> was said.
>
> With that said, I'm sure Tom understands now that the p=3 mod 4 check is
> unnecessary because the only prime p = 2q+1 (for prime q) that is not 3
mod
> 4 is 5.

Thanks for the reply here.  It's nice to know not everyone hates me :-)

Just to clear something up.  I'm not checking if p mod 4 =3, I am FORCING p
to be 3 mod 4 by setting the lower bits to 11.

Tom



------------------------------

From: jlcooke <[EMAIL PROTECTED]>
Subject: Re: fast CTR like ciphers?
Date: 13 Jun 2001 19:22:19 GMT

I had attempted a design similar to a few things Tom has been talking
about the past few threads.

A cipher which generates a stream of random bits seeded at the start by
a key.  Block size and key size B.

Encrypt;
  ctext[-1] = InitalVector
  loop:
    ctext[n] = BALA(ctext[n-1],key) xor ptext[n]
Decrypt:
  ctext[-1] = InitalVector
  loop:
    ptext[n] = BALA(ctext[n-1],key) xor ctext[n]

Where the output of the BALA transform is depended exactly on each bit
of input.

Description of "O = BALA( I )";
  O[0] = some complex binary function using all bits of I
  O[1] = ditto but a different function.
  ...

These functions (B in total) would be determined by the key and the
simplest for would be a XOR with the key.
Example:
  temp = <the key>;
  O[0] = I[0] ^ temp; temp = nextVal(temp);
  O[1] = I[1] & temp; temp = nextVal(temp);
  ...

Where nextVal() could be multiplication by 2 in GF, x=((x*x) >>
(log2(x)/2)) in integers, or a combination of ROL/ADD/XOR.

If there is interest, and implementation can be made.

JLC

Tom St Denis wrote:
> 
> I was just thinking.  It's probably very easy to make a super-fast cipher
> thats made for one-way encryption for CTR modes....?
> 
> We could make a UFN which favors the encryption direction for diffusion and
> designed to be fast?
> --
> Tom St Denis
> ---
> http://tomstdenis.home.dhs.org

------------------------------

From: jlcooke <[EMAIL PROTECTED]>
Subject: Re: curious about MD3
Date: 13 Jun 2001 19:25:13 GMT

If I recall MD3 never mad it out of Ron's study and circle of friends.

JLC

Tom St Denis wrote:
> 
> In Applied Crypto P446 Schneier mentions MD3.  I can't find the reference
> online.
> 
> Does anyone have a description?
> --
> Tom St Denis
> ---
> http://tomstdenis.home.dhs.org

------------------------------

From: Fat Phil <[EMAIL PROTECTED]>
Subject: Re: Simple Crypto II, the public key...
Date: Wed, 13 Jun 2001 22:28:48 +0300

Mark Wooding wrote:
> > I'm a 'right-to-left' man myself.
> 
> Good, because the algorithm above is right-to-left.

I need a holiday.
I even thought _twice_ before writing that.
I'm L-R. DOH!
 
> I'm a left-to-right man.  The basic algorithms are very similar in terms
> of efficiency, but right-to-left is the end of the road, whereas there
> are all sorts of clever things you can do with left-to-right (sliding
> window exponentiation, simultaneous exponentiation...)

I've recently thrown together most of a witty base conversion (into -1,
0, +1) algorithm that seems faster than the one listed in HAC. However,
it's really not an important issue (timewise), so I can't be bothered to
finish the final 1% of the algorithm. To be honest, when reading HAC, to
about 30% of the algorithms I'd throw my hands in the air and just say
"why". I guess it's not until you implement them and play with them that
you get to appreciate the fine details.

Phil

------------------------------

From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: curious about MD3
Date: Wed, 13 Jun 2001 19:39:35 GMT


"jlcooke" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> If I recall MD3 never mad it out of Ron's study and circle of friends.
>
> JLC

Geez I wish I was an MIT alumnist now :-)

Darn... I'm curious!

Tom



------------------------------

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Uniciyt distance and compression for AES
Date: 13 Jun 2001 19:38:45 GMT

[EMAIL PROTECTED] wrote in <[EMAIL PROTECTED]>:

>"SCOTT19U.ZIP_GUY" wrote:
>
>> 
>> ... but here in simple terms here is why
>> your wrong. You state that 1/32 are the meaningless messages. The
>> point is you only encrypt meaningful messages. So if I rescale you
>> propabilites and change 1/32 to "zero" now I have a message space with
>> messages and meaningless data.
>
>Even though only meaningful messages are encrypted, meaningless
>messages must be included in the compressed message space if it
>is possible to compress a meaningless message with the compressor.
>A decryption with a randomly chosen key may produce this meaningless
>compressed value.
>

  Obviously you never looked at what I wrote or you would see the problem.

David A. Scott
-- 
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
        http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
 made in the above text. For all I know I might be drugged or
 something..
 No I'm not paranoid. You all think I'm paranoid, don't you!


------------------------------

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: IV
Date: 13 Jun 2001 19:35:59 GMT

[EMAIL PROTECTED] (Volker Hetzer) wrote in
<[EMAIL PROTECTED]>: 

>Well, do you think of the otp as an example of what encryption is
>not about too? After all it has the same flaw CTR has.
>

  Only if the OTP is used in a form as badly as CTR. THere
was a thread of over 3 hundred messages due to peoples lack
of knowledge of what "perfect security is". You most likely
have been poorly educated as to the proper use of a OTP.


David A. Scott
-- 
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
        http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
 made in the above text. For all I know I might be drugged or
 something..
 No I'm not paranoid. You all think I'm paranoid, don't you!


------------------------------

From: jlcooke <[EMAIL PROTECTED]>
Subject: Re: ??
Date: 13 Jun 2001 19:43:23 GMT

Yes and thank you for your courtesy.

JLC

Mykhailo Lyubich wrote:
> 
> Hi,
> 
> is this list suitable to post a protocol description/question?
> 
> --
> Mykhailo Lyubich

------------------------------


** 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
******************************

Reply via email to