Cryptography-Digest Digest #526, Volume #14 Tue, 5 Jun 01 16:13:01 EDT
Contents:
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Wide Trail Strategy (was Re: Help with Comparison Of Complexity of Discrete Logs,
Knapsack, and Large Primes) ("Joseph Ashwood")
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
Re: Definition of 'key' ("Augusto Jun Devegili")
Re: Def'n of bijection ([EMAIL PROTECTED])
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
Re: Welcoming another Anti-Evidence Eliminator stooge to USENET (P. Dulles / AKA
Loki) ("Tom St Denis")
Re: Def'n of bijection (SCOTT19U.ZIP_GUY)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
fast CTR like ciphers? ("Tom St Denis")
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Tue, 5 Jun 2001 19:09:13 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
:> :> [...] a 1-byte cyphertext can only represent 256 possible plaintexts.
:> :>
:> :> Do you think it is acceptable to have a 128 bit key and then
:> :> throw away 120 bits of entropy from it when dealing with
:> :> particular plaintexts?
:> :>
:> :> What sort of "provable security" do you think that is?
:>
:> : This is meaningless and you should know it. First off there are 256! =
:> : 2^1680 ways to permute a byte. So technically you are not throwing away
:> : entropy. So even if it *were* a 1-byte block cipher you're not reducing
:> : the key space.
:>
:> We're *not* talking about "permuting a byte"!
:>
:> We're talking about *XOR*ing it with another 1-byte value!
:>
:> You *do* know what CTR mode is, don't you? ;-)
: You lost me here. If you encrypt 32 bytes with CTR for example, you are
: encoding different the bytes by encrypting different counters. If the
: cipher is a 64-bit block ciphere there are 2^64! possible permutations so a
: 128-bit key would not be lose entropy here.
Of course not - but we are discussing an 8 bit cyphertext.
: I really don't get the comparison. Why is encrypting via CTR throwing key
: material away (as you pointed out).
You map a 128 bit key (and a counter) to a 8 bit byte. *Many* keys
produce the same byte. Approximately 2^120 keys produce the same byte.
The differences between those keys are thrown away. The result in
discarding approximately 120 bits of the 128 bits of entropy that were
in the key.
After this narrowing transformtion has been made, you XOR the resulting
byte with the plaintext to produce the cyphertext.
Your 256! figure has nothing to do with this situation.
:> : Second, in CTR mode the counter is not fixed in size. You do encode
:> : full blocks. You just end up not having to use all of the output.
:>
:> If you like - so you encode 128 bits and then throw away 120 of them,
:> leaving you with 8. How on earth do you think this is a point in your
:> favour?
: Why is a point against? [...]
It isn't. You brought it up, not me. It's a true statement, which has
little bearing on the topic under discussion AFAICS.
: Yes there will be equivalent keys but not enough to tell from random.
Tell /what/ "from random".
: If you are encoding a single byte the unacity (arrg) distance will be
: larger then the byte so you can't tell the correct key from random.
Indeed.
: So how are you throwing key material away?
By processing it into a single byte before applying it to the plaintext?
: The only way I could see is if you encode larger messages [...]
If that's the /only/ way you can see, then I should give up on this
discussion - since I'm not going to take that route in my attempt to
show you that a cyphertext only having 256 possible decrypts is a
problem with the orthodox CTR mode.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Tue, 5 Jun 2001 19:13:19 GMT
Mark Wooding <[EMAIL PROTECTED]> wrote:
: Tim Tyler <[EMAIL PROTECTED]> wrote:
:> DS> And you never anwsered the FACT that a one byte ouput file
:> DS> from CTR mode (though you have no working program) would imediately
:> DS> lead an attacker to realize that the input file could only have
:> DS> come from 1 of 256 possible messages. With BICOM you have many
:> DS> many more messages. That alone makes it more secure. [...]
: This is wrong.
No it is not - you misinterpreted it.
: 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.
No. You are talking about an unknown 1-byte cyphertext under a *known* key.
David was talking about a specified cyphertext under an *unknown* key.
This is the attacker's position. David made it clear he was talking about
an attacker by mentioning him explicitly.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Wide Trail Strategy (was Re: Help with Comparison Of Complexity of Discrete
Logs, Knapsack, and Large Primes)
Date: Tue, 5 Jun 2001 12:23:34 -0700
"Gregory G Rose" <[EMAIL PROTECTED]> wrote in message
news:9fhb44$[EMAIL PROTECTED]...
> What is this Wide Trail Strategy?
The wide trail strategy is a method of cipher design developed by Joan
Daemen for his PhD. It was introduced in the PhD and because there is such a
massive amount of information surrounding it I would suggest you get a copy
of the thesis (http://www.esat.kuleuven.ac.be/~cosicart/ps/JD-9500/). If you
just want the short version of it see the Whirlpool (available from
Cryptonessie) specification or the Rijndael (aka AES) specification they are
both well written and are Wide Trail Strategy ciphers.
Joe
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Tue, 05 Jun 2001 19:48:32 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]...
>
> :> In a system with a 128 bit key, being able to narrow the message down
> :> from one of 2^128 possibilities to one of 2^8 possibilities surely
> :> represents a gigantic loss of security, no?
>
> : In this case the key is the same length of the message.
>
> In bits: Len(key) = 128. Len(msg) = 8. 128 != 8.
>
> : What cipher are you talking about that uses a 128-bit key and a 8-bit
block?
>
> I never mentioned an 8 bit block cypher. We're talking about an ordinary
> block cypher in CTR mode.
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.
Hence, what is the problem? If it's an OTP then it's provably resilient to
all known attacks! (I say it's an OTP since we assume the msglen < keylen
and the key material is used with a uniform distribution making all possible
messages equalprobable)
Tom
------------------------------
From: "Augusto Jun Devegili" <[EMAIL PROTECTED]>
Subject: Re: Definition of 'key'
Date: Tue, 5 Jun 2001 15:54:48 -0300
Considering that a cryptosystem is a five-tuple comprised of (P, C, K, E,
D), where P is the set of possible plaintexts, C is the set of possible
ciphertexts and K is the key space (possible keys):
* for each k belonging to K there is an encryption rule e_k belonging to E
and a correspondent decryption rule d_k belonging to D
* each e_k : P -> C and d_k : C -> P are functions so that for each x
belonging to P, d_k(e_k(x)) = x
Take a look at Cryptography: Theory and Practice by Dr. Stinson.
Regards,
Augusto Jun Devegili
"Patrick Aland" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I was talking to someone today and we were trying to come up with a
> good formal definition of a key (in regards to cryptography, no
> car/house/etc key comments please :) )
> Now after looking through the few crypto books I have (Applied crypto,
> etc) they don't seem to have a good definition either.
> Can anyone help me out?
>
> Thanks.
------------------------------
Subject: Re: Def'n of bijection
From: [EMAIL PROTECTED]
Date: 05 Jun 2001 15:51:27 -0400
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.
> : 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.
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 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.
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.
Which is why I inferred from the earlier discussion that BICOM was
supposed to give a bijection between meaningful messages and arbitrary
files. 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.
Hint: ``It might well help; 2^128 is a lot of decompressions!'' does not
prove anything.
Len.
--
Could you describe the mess, and explain why you think that the lack
of opportunistic bombardment is a contributing factor?
-- Dan Bernstein
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Tue, 05 Jun 2001 19:51:24 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:
> :> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
>
> :> :> [...] a 1-byte cyphertext can only represent 256 possible
plaintexts.
> :> :>
> :> :> Do you think it is acceptable to have a 128 bit key and then
> :> :> throw away 120 bits of entropy from it when dealing with
> :> :> particular plaintexts?
> :> :>
> :> :> What sort of "provable security" do you think that is?
> :>
> :> : This is meaningless and you should know it. First off there are 256!
=
> :> : 2^1680 ways to permute a byte. So technically you are not throwing
away
> :> : entropy. So even if it *were* a 1-byte block cipher you're not
reducing
> :> : the key space.
> :>
> :> We're *not* talking about "permuting a byte"!
> :>
> :> We're talking about *XOR*ing it with another 1-byte value!
> :>
> :> You *do* know what CTR mode is, don't you? ;-)
>
> : You lost me here. If you encrypt 32 bytes with CTR for example, you are
> : encoding different the bytes by encrypting different counters. If the
> : cipher is a 64-bit block ciphere there are 2^64! possible permutations
so a
> : 128-bit key would not be lose entropy here.
>
> Of course not - but we are discussing an 8 bit cyphertext.
>
> : I really don't get the comparison. Why is encrypting via CTR throwing
key
> : material away (as you pointed out).
>
> You map a 128 bit key (and a counter) to a 8 bit byte. *Many* keys
> produce the same byte. Approximately 2^120 keys produce the same byte.
> The differences between those keys are thrown away. The result in
> discarding approximately 120 bits of the 128 bits of entropy that were
> in the key.
>
> After this narrowing transformtion has been made, you XOR the resulting
> byte with the plaintext to produce the cyphertext.
>
> Your 256! figure has nothing to do with this situation.
>
> :> : Second, in CTR mode the counter is not fixed in size. You do encode
> :> : full blocks. You just end up not having to use all of the output.
> :>
> :> If you like - so you encode 128 bits and then throw away 120 of them,
> :> leaving you with 8. How on earth do you think this is a point in your
> :> favour?
>
> : Why is a point against? [...]
>
> It isn't. You brought it up, not me. It's a true statement, which has
> little bearing on the topic under discussion AFAICS.
>
> : Yes there will be equivalent keys but not enough to tell from random.
>
> Tell /what/ "from random".
Tell the plaintext. If you guess a key (or output byte from CTR) and can't
tell if the plaintext makes sense then you don't win.
> : If you are encoding a single byte the unacity (arrg) distance will be
> : larger then the byte so you can't tell the correct key from random.
>
> Indeed.
>
> : So how are you throwing key material away?
>
> By processing it into a single byte before applying it to the plaintext?
>
> : The only way I could see is if you encode larger messages [...]
>
> If that's the /only/ way you can see, then I should give up on this
> discussion - since I'm not going to take that route in my attempt to
> show you that 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.
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.
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?
Hence don't you agree it's provably secure?
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Crossposted-To:
alt.privacy,alt.security,alt.security.pgp,alt.security.scramdisk,alt.privacy.anon-server
Subject: Re: Welcoming another Anti-Evidence Eliminator stooge to USENET (P. Dulles /
AKA Loki)
Date: Tue, 05 Jun 2001 19:53:09 GMT
"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
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Def'n of bijection
Date: 5 Jun 2001 19:40:52 GMT
[EMAIL PROTECTED] wrote in <[EMAIL PROTECTED]>:
>Tim Tyler <[EMAIL PROTECTED]> writes:
>>
>> [Compression] also helps with bandwidth - but it doesn't help with
>> security.
>
>That's what I keep telling you--but you only half believe it. Because
>next you say:
>
Very Sneaky and dishonest. You did not quote Mt Tyler correctly
at all. I looked at the previous message. What kind of game are you
playing And who do you think it fools.
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: Best, Strongest Algorithm (gone from any reasonable topic)
Date: 5 Jun 2001 19:49:48 GMT
[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.
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 19:57:35 GMT
"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
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: fast CTR like ciphers?
Date: Tue, 05 Jun 2001 20:08:20 GMT
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
------------------------------
** 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
******************************
