Cryptography-Digest Digest #527, Volume #14       Tue, 5 Jun 01 17:13:01 EDT

Contents:
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
  Re: Def'n of bijection (SCOTT19U.ZIP_GUY)
  Re: Def'n of bijection (Mok-Kong Shen)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: fast CTR like ciphers? ("Tom St Denis")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
  Re: Welcoming another Anti-Evidence Eliminator stooge to USENET (Anonymous)
  Re: Def'n of bijection (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)

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

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: 5 Jun 2001 19:58:14 GMT

[EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:

 Tim I think TOM is just trying to make ass out of himself
The thread will go no where. He will only twist it. He can't
even answser the simple fact theat if one used CTR mode so
a one byte cipher text file decrypts to 256 messages. And
one used BICOM where a one byte output file could represent
thousands and thousands of possible input messages. He in
this example doesn't know which case is more secure. If he
can't comprehend the obvious why keep tryinig. He does not
want to know the truth. He doesn't care. You can give a pig
singing lessoons but his not going to learn. You just waste your
time and the pigs.




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: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Tue, 05 Jun 2001 20:25:06 GMT


"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>
>  Tim I think TOM is just trying to make ass out of himself
> The thread will go no where. He will only twist it. He can't
> even answser the simple fact theat if one used CTR mode so
> a one byte cipher text file decrypts to 256 messages. And
> one used BICOM where a one byte output file could represent
> thousands and thousands of possible input messages. He in
> this example doesn't know which case is more secure. If he
> can't comprehend the obvious why keep tryinig. He does not
> want to know the truth. He doesn't care. You can give a pig
> singing lessoons but his not going to learn. You just waste your
> time and the pigs.

Funny.  Why can't you answer any simple questions?

Again.

C = P + K mod 256
C = 55

What is P?

Tom



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

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: 5 Jun 2001 20:13:38 GMT

[EMAIL PROTECTED] (Tom St Denis) wrote in
<PQaT6.36859$[EMAIL PROTECTED]>: 

>
>"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> [EMAIL PROTECTED] (Mark Wooding) wrote in
><[EMAIL PROTECTED]>:
>>
>> >
>> >Hence, there are at most 256 possible plaintext messages for any
>> >one-byte ciphertext.  They might not all be one-byte long, but there
>> >are at most 256 of them.
>> >
>> >-- [mdw]
>> >
>>
>>   Sorry but you whole analysis is full of shit. Even you could sit
>> down and test decrypt 300 keys to decrypt one one byte cipher text
>> message. But like many you spout off shit thats wrong that you could
>> easily test. But you have so much blind belied in your false Gods
>> and false proof you don't even take the honest time to test it. Yes
>> there are strong words but the simple fact is your full of it.
>
>Yes you can decrypt it.
>
>The problem is you won't know when you found the key.
>
>Try this.
>
>C = P + K mod 256
>C = 56
>
>What was P or K?
>
>In this case both P and K are decorrelated and C doesn't reveal P. 
>Which is what the original argument was about.
>
>So what if you could guess P=23.  There is no way to verify that's the
>right answer.
>
>Tom
>
>
>

  Tom are you retarded or what. You don't seem to know what the
hell is going on. The first person who may not know better thinks
that if you have a one byte ciphertext output file your limited
to 256 possible input messages. He may not know better he really
has not heard much about things like BICOM. You on the other hand
have no excuse other than mental retardation since you have been
given many chances and explantions to discribe what is happening
yet you stay and act like an ass. You should have read what perfect
security is yet you act like someone first exposed to an OTP 
surely your not as dumb as your acting unless your retarded.
 

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: Def'n of bijection
Date: 5 Jun 2001 20:23:16 GMT

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

>Tim Tyler <[EMAIL PROTECTED]> writes:
>> [EMAIL PROTECTED] wrote:
>>
>> Compression *doesn't* help with securtity *if* your key is already the
>> size of the message. Under other circumstances, it might well help.
>
>As I've said, ``It's nice.'' But if your cipher needs the help, then
>you're using the wrong cipher.

    Then I supose you know of smalled keyed ciphers that are perfect
and don't need help. Maybe your just an ass and don't realize no one
knows if any current small keyed ciphers are secure. They give proofs
against certain forms of attack. But has history as showed somthing
that appears strong one day is trash the next day unless you know
a hell of a lot more than what you dumb anwsers seem to imply.

>
>Your assertion to the contrary rests on the assumption that trial
>decrypts are highly likely to decompress into something which I will
>mistake for the plaintext. In other words, you are hoping that false
>positives are more likely. Unfortunately, this needs to be proven--the
>fact that BICOM is bijective (if it is indeed a fact) is not enough to
>conclude increased security.

 Actaully shannon showed how the unicity distance goes up so that
longer and longer files are needed to be able to find a correct
decrypt. Compression helps a lot. But you seem to think you know it
all and would not belive Shannon

>
>And by the way, that means you *DO* care how densely meaningful messages
>are mapped to compressed messages. The ``added security'' of BICOM
>depends critically on the increased likelihood that wrong keys will
>yield plausible decrypts.

   Yes that what Shannons theroy is all about. 
Something I dought you understand based on your twisted
reasoning in these posts.


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: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Def'n of bijection
Date: Tue, 05 Jun 2001 22:21:05 +0200



Tim Tyler wrote:
> 
> [EMAIL PROTECTED] wrote:
> : "Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
> 
> :> If you take a 2048-bit ciphertext from a system that uses a 128-bit
> :> key, there are only 2^128 possible plaintexts, nowhere near the 2^2048
> :> that an ideal system would have. D.Scott's goal, in general terms,
> :> seems to be to develop a system that avoids having that property.
> 
> : Precisely--that's the desirable OTP property that Scott is after.
> : But he's failing to recognize (or at least describe) his goal clearly. If
> : he put it as clearly as you have, it would become clear that the number
> : of decrypts can be no larger than the size of the keyspace, period.
> 
> AFAICS, neither of you is discussing anything like what David Scott is doing.

I agree. Perhaps it is because of an unlucky choice of
the term 'bijective' that has led to a large number of
partly unnecessary discussions. I am surprised that
the debate on this topic has recurred a number of times 
in the group.

Let there be a compression C with its counterpart 
(decompression) D be given such that these always 
accept input of whole number of bytes and generate 
output of whole number of bytes. Let an 'arbitrary' 
sequence of n (whole) bytes be desinated by X. Then
what Scott requires is C(D(X))=X. This would seem to
be a trivial non-requirement. But in fact it is not 
so. If one tries with a normal Huffman algorithm to 
compress a given number of bytes, then one will in 
general have a result not ending on byte boundary.
If one actually makes some thoughts about how to fill
(pad) the output to byte boundary and how one is
going to deal with the padding material on 
decompression, one would see that the above requirement 
involves something not entirely trivial, though there
may certainly be more than one viable ways to achieve 
that purpose.

M. K. Shen

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

From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Tue, 05 Jun 2001 20:30:40 GMT


"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Tom St Denis) wrote in
> <PQaT6.36859$[EMAIL PROTECTED]>:
>
> >
> >"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
> >news:[EMAIL PROTECTED]...
> >> [EMAIL PROTECTED] (Mark Wooding) wrote in
> ><[EMAIL PROTECTED]>:
> >>
> >> >
> >> >Hence, there are at most 256 possible plaintext messages for any
> >> >one-byte ciphertext.  They might not all be one-byte long, but there
> >> >are at most 256 of them.
> >> >
> >> >-- [mdw]
> >> >
> >>
> >>   Sorry but you whole analysis is full of shit. Even you could sit
> >> down and test decrypt 300 keys to decrypt one one byte cipher text
> >> message. But like many you spout off shit thats wrong that you could
> >> easily test. But you have so much blind belied in your false Gods
> >> and false proof you don't even take the honest time to test it. Yes
> >> there are strong words but the simple fact is your full of it.
> >
> >Yes you can decrypt it.
> >
> >The problem is you won't know when you found the key.
> >
> >Try this.
> >
> >C = P + K mod 256
> >C = 56
> >
> >What was P or K?
> >
> >In this case both P and K are decorrelated and C doesn't reveal P.
> >Which is what the original argument was about.
> >
> >So what if you could guess P=23.  There is no way to verify that's the
> >right answer.
> >
> >Tom
> >
> >
> >
>
>   Tom are you retarded or what. You don't seem to know what the
> hell is going on. The first person who may not know better thinks
> that if you have a one byte ciphertext output file your limited
> to 256 possible input messages. He may not know better he really
> has not heard much about things like BICOM. You on the other hand
> have no excuse other than mental retardation since you have been
> given many chances and explantions to discribe what is happening
> yet you stay and act like an ass. You should have read what perfect
> security is yet you act like someone first exposed to an OTP
> surely your not as dumb as your acting unless your retarded.

Ok if I am so stupid what was K in the above example?

See you have to realize that what people want from crypto is not dictated by
you.  Specially if you can't legitimately explain your concerns.

If you can solve for K in the above system I will give you all my earthly
possesions and preach your crypto-wisdom.

Tom



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

From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: fast CTR like ciphers?
Date: Tue, 05 Jun 2001 20:40:19 GMT


"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:U_aT6.37003$[EMAIL PROTECTED]...
> 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?

Just to start the discussion I have a toy cipher (designed in all of five
mins) that we can use as a model of discussion.

I call it MUD for "Mirky UnderDeveloped".  it's not intended for real
use....

It's somewhat fast and on 8-bit cpus would be a dream to implement.  The
idea is that the cipher is used in CTR mode only so the decryption is
neither required nor provided.  The cipher is designed such that going from
plaintext to ciphertext is secure but not the vice versa...

http://tomstdenis.home.dhs.org/src/mud.c

Tom



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

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: 5 Jun 2001 20:39:07 GMT

[EMAIL PROTECTED] (Tom St Denis) wrote in 
<CebT6.37239$[EMAIL PROTECTED]>:

>
>"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> [EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>>
>>  Tim I think TOM is just trying to make ass out of himself
>> The thread will go no where. He will only twist it. He can't
>> even answser the simple fact theat if one used CTR mode so
>> a one byte cipher text file decrypts to 256 messages. And
>> one used BICOM where a one byte output file could represent
>> thousands and thousands of possible input messages. He in
>> this example doesn't know which case is more secure. If he
>> can't comprehend the obvious why keep tryinig. He does not
>> want to know the truth. He doesn't care. You can give a pig
>> singing lessoons but his not going to learn. You just waste your
>> time and the pigs.
>
>Funny.  Why can't you answer any simple questions?
>
>Again.
>
>C = P + K mod 256
>C = 55
>
>What is P?
>
>Tom
>
>
>

  Tell what little get a third party to encrypt using your ctr
mod a one cipher text output file. I will guess the input. I may
be wrong. Then you get to guess the input to a one byte output
file encrypted with BICOM. If you miss I guess again. And we
keep doing this till one gets it right. I am willing to put
a thousand bucks on this. On second thought you go first.
Do you feel secure enough to really bet. I doubt it.

  And no as in what many beginers try. I don't know what P is
uniquely but your a bigger fool than I thought if you thing
that even reducing the message space to a few messages is a 
sign of security. The larger the pool of uncertainy about the
message the better. 

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!


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

Date: Tue, 5 Jun 2001 22:45:02 +0200
From: Anonymous <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.security,alt.security.pgp
Subject: Re: Welcoming another Anti-Evidence Eliminator stooge to USENET

In article <FMaT6.36826$[EMAIL PROTECTED]>
"Tom St Denis" <[EMAIL PROTECTED]> wrote:
>
>
> "Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
> news:9fite0$h68$[EMAIL PROTECTED]...
> >
> > Kyle Paskewitz <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > Tom -
> > >
> > > You've forgotten that 2 is also prime.  If you take the product of any
> > > number of consecutive primes beginning with 2 (the first prime) and add
> 1,
> > > you will get another prime.  E.G.
> > >
> > > 2*3 + 1 = 7
> > > 2*3*5 + 1 = 31
> > > 2*3*5*7 + 1 = 211 , etc...
> >
> > Really???  I was under the impression that:
> >
> > 2*3*5*7*11*13+1 = 30031 = 59*509
> > 2*3*5*7*11*13*17+1 = 510511 = 19*97*277
> > 2*3*5*7*11*13*17*19+1 = 9699691 = 347*27953
> > 2*3*5*7*11*13*17*19*23+1 = 223092871 = 317*703763
> >
> > weren't prime.  I must be delusional, I suppose...
>
> Not to get into a flame war, but I did say "the sum is not divisible by any
> known primes, hence the opposite must be true QED".
>
> In my OP I never said the new value is prime, just not divisible by the
> "known" primes.
>
> Tom

WTF does this have to do with anon-server?































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

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Def'n of bijection
Reply-To: [EMAIL PROTECTED]
Date: Tue, 5 Jun 2001 20:42:04 GMT

[EMAIL PROTECTED] wrote:
: Tim Tyler <[EMAIL PROTECTED]> writes:
:> [EMAIL PROTECTED] wrote:
:>
:> Compression *doesn't* help with securtity *if* your key is already the
:> size of the message. Under other circumstances, it might well help.

: As I've said, ``It's nice.'' But if your cipher needs the help, then you're
: using the wrong cipher.

Apparently you read my example of a key book which is partially destroyed.

You also responded to my tale of keys being generated by a faulty RNG.

However, you already appear to have forgotten about these examples -
and have gone back to the false idea that the ability to reject keys is
only useful if your cypher is broken.

Should I present more examples?

What about the possibility that your cypher is broken - but you don't
realise it.

It's all very well to say that someone is using the wrong cypher - but
do you know which cypher is the right one?

:> : In particular, BICOM simply adds work: it adds a decompression step. Why
:> : is this simple fact eluding you?
:> 
:> It is an error - on your part - not a "simple fact".

: This is the heart of the issue--and you just don't seem to get it.

: *IF* meaningful files have no identifying characteristics when BICOM
: compressed (which is what you mean by ``no known plaintexts''), then I
: must decompress using BICOM and then look at the result; I cannot look
: at the trial decrypt, because the output of BICOM looks like
: garbage. Therefore, you've added work.

Of course.

: Each trial decryption has exactly one decompression. So if decryption
: followed by decompression leads to an intelligible message, then I have
: most likely found the key.

Your error.  You /may/ have found the key, or maybe not - it all depends.

If the message is short there may be *many* possible correct-looking
decrypts.  To find one - and then conclude that you have found the key -
would be premature in that case.

: Your assertion to the contrary rests on the assumption that trial decrypts
: are highly likely to decompress into something which I will mistake for the
: plaintext.

Or more likely than they were before at any rate.

: In other words, you are hoping that false positives are more likely.

Which they are going to be - if the compressor is at all competent at
compressing the data in question.

: Unfortunately, this needs to be proven [...]

A formal proof may be beyond my scope here.

Suffice to say that with any non-trivial lossless compressor, messages in
some target set are made shorter (and other messages are made longer).

Consequently, for any given size of compressed data, there are
likely to be more representations of files from the original target set
than there would have been if no compression had taken place.

: And by the way, that means you *DO* care how densely meaningful messages
: are mapped to compressed messages. The ``added security'' of BICOM depends
: critically on the increased likelihood that wrong keys will yield plausible
: decrypts.

Yes.

: Which is why I inferred from the earlier discussion that BICOM was
: supposed to give a bijection between meaningful messages and arbitrary
: files.

I can imagine why you concluded that - but it is still wrong.

: That is much stronger than you need to conclude ``added security'',
: but some result in that direction is needed for BICOM to provide any
: benefit at all. You don't seem to realize that any such result is needed.

This "result" seems unnecessary to me because I see it as being
rather obvious.  I've been hoping that you will see it as well
without my painfully spelling it out for you.

You seem to accept already that an "optimal compressor" is likely to make
rejecting keys practically impossible.

Why you can't go from there to a "good compressor" making rejecting keys
harder puzzles me.
-- 
__________
 |im |yler  [EMAIL PROTECTED]  Home page: http://alife.co.uk/tim/

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

From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Tue, 05 Jun 2001 20:54:00 GMT


"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Tom St Denis) wrote in
> <CebT6.37239$[EMAIL PROTECTED]>:
>
> >
> >"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
> >news:[EMAIL PROTECTED]...
> >> [EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
> >>
> >>  Tim I think TOM is just trying to make ass out of himself
> >> The thread will go no where. He will only twist it. He can't
> >> even answser the simple fact theat if one used CTR mode so
> >> a one byte cipher text file decrypts to 256 messages. And
> >> one used BICOM where a one byte output file could represent
> >> thousands and thousands of possible input messages. He in
> >> this example doesn't know which case is more secure. If he
> >> can't comprehend the obvious why keep tryinig. He does not
> >> want to know the truth. He doesn't care. You can give a pig
> >> singing lessoons but his not going to learn. You just waste your
> >> time and the pigs.
> >
> >Funny.  Why can't you answer any simple questions?
> >
> >Again.
> >
> >C = P + K mod 256
> >C = 55
> >
> >What is P?
> >
> >Tom
> >
> >
> >
>
>   Tell what little get a third party to encrypt using your ctr
> mod a one cipher text output file. I will guess the input. I may
> be wrong. Then you get to guess the input to a one byte output
> file encrypted with BICOM. If you miss I guess again. And we
> keep doing this till one gets it right. I am willing to put
> a thousand bucks on this. On second thought you go first.
> Do you feel secure enough to really bet. I doubt it.
>
>   And no as in what many beginers try. I don't know what P is
> uniquely but your a bigger fool than I thought if you thing
> that even reducing the message space to a few messages is a
> sign of security. The larger the pool of uncertainy about the
> message the better.

Here's a tip.

THE SIZE OF THE MESSAGE SPACE IS IRRELEVENT WRT TO SECURITY.

As long as all messages are uniformly probable you win.

Think.  Look at a OTP.  It can safely encode a SINGLE BIT.  But since all
messages are uniformly probable (0 or 1 with p=1/2) it's provably secure.
(I.e no way to tell which is which).

Similarly with a 8-bit message.  if I give you

C = P + K mod 256

and K is a random 8-bit string there is NO WAY to tell what P is.  You can
guess but you can never be sure over a prob of 1/256 (unless you know what P
is).

Suppose that P is one of four out of the 256 possible messages.  Even then
you have P=1/4 of picking the right one.  It's still uniformly
distributed... so again I win.

Tom



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

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Tue, 5 Jun 2001 20:49:10 GMT

Tom St Denis <[EMAIL PROTECTED]> wrote:

: Well CTR mode is not limited to 8-bit messages AND for any 8-bit message you
: can reach OTP status if the unacy distance is longer then 8-bits.

Which only gets us as far as an OTP - which has the *same* security
problem as counter mode if messages are of varying lengths and
the plaintexts and cyphertexts are of equal lengths.

: Hence, what is the problem?  If it's an OTP then it's provably resilient to
: all known attacks!

This is the problem.  You seem to think an OTP is some sort of holy
grail - and that by comparing CTR mode to it you banish all its problems.

OTPs do *not* have perfect secrecy if messages can be of varying lengths
and the plaintexts and cyphertexts are of equal lengths.

Such an OTP is *not* "provably resistant to all known attacks".

Comparing one damaged system with another one gets you nowhere.
-- 
__________
 |im |yler  [EMAIL PROTECTED]  Home page: http://alife.co.uk/tim/

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

From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Tue, 05 Jun 2001 20:59:27 GMT


"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> : Well CTR mode is not limited to 8-bit messages AND for any 8-bit message
you
> : can reach OTP status if the unacy distance is longer then 8-bits.
>
> Which only gets us as far as an OTP - which has the *same* security
> problem as counter mode if messages are of varying lengths and
> the plaintexts and cyphertexts are of equal lengths.

What problem?  If all possible messages are uniformly distributed you have
no advantage hence you can't tell which message is the real one.

>
> : Hence, what is the problem?  If it's an OTP then it's provably resilient
to
> : all known attacks!
>
> This is the problem.  You seem to think an OTP is some sort of holy
> grail - and that by comparing CTR mode to it you banish all its problems.
>
> OTPs do *not* have perfect secrecy if messages can be of varying lengths
> and the plaintexts and cyphertexts are of equal lengths.
>
> Such an OTP is *not* "provably resistant to all known attacks".
>
> Comparing one damaged system with another one gets you nowhere.

Hmm?  An OTP has #key = #msg = #ciphertext.  What are you talking about
"messages can be of varying lengths and plaintext and ciphertexts are of
equal lengths".  The plaintext is the message!

If you follow the rules of an OTP you can't lose.  it's a bloody fact of
math man.  If all messages are uniformly distributed you can't find the real
message.  (Could you just stop and think about this for 10 seconds please!)

Tom



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

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Tue, 5 Jun 2001 20:59:36 GMT

Tom St Denis <[EMAIL PROTECTED]> wrote:
: "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> Tom St Denis <[EMAIL PROTECTED]> wrote:

:> : Yes there will be equivalent keys but not enough to tell from random.
:>
:> Tell /what/ "from random".

: Tell the plaintext. [...]

I can very likely tell a randomly chosen plaintext from the decrypt of an
1 byte cyphertext using CTR mode.

Does the random plaintext have only 8 bits?  If not, I can immediately
distinguish them.

:> [...] a cyphertext only having 256 possible decrypts is a
:> problem with the orthodox CTR mode.

: It's not a problem.  You're just not looking for the answer.

AFAICS, your idea of an answer is one that isn't worth having ;-|

: The truth is if the message has a prob of 1/256 and all outputs from the
: cipher are equalprobable (i.e 1/256) then it's a provably secure for a
: single byte only.

Ah - you're sliding in that "for a single byte only"...

As though we're discussing the trivial case of only 256 possible messages...

: Consider the cipher some simple like

: C = P xor K

: where we discard the 120 upper bits of C before xoring against the message.
: Don't you agree this is just an OTP?

Yes - it's very much like an OTP.

: Hence don't you agree it's provably secure?

Of course it's not provably secure - unless you think only having 256
possible plaintexts out of the possible billions is something worthwhile.

We're trying to stop the attacker getting information about the message.
Giving him the length of the message on a plate is a terrible start.
-- 
__________
 |im |yler  [EMAIL PROTECTED]  Home page: http://alife.co.uk/tim/

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


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