Cryptography-Digest Digest #34, Volume #13 Sun, 29 Oct 00 10:13:00 EST
Contents:
Re: DATA PADDING FOR ENCRYPTION (SCOTT19U.ZIP_GUY)
Re: BEST BIJECTIVE RIJNDAEL YET? (John Savard)
Re: Is OPT the only encryption system that can be proved secure? (John Savard)
Re: Is OPT the only encryption system that can be proved secure? (John Savard)
Re: DATA PADDING FOR ENCRYPTION (SCOTT19U.ZIP_GUY)
Re: Psuedo-random number generator ("Trevor L. Jackson, III")
Re: BEST BIJECTIVE RIJNDAEL YET? (SCOTT19U.ZIP_GUY)
Re: BEST BIJECTIVE RIJNDAEL YET? (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: DATA PADDING FOR ENCRYPTION
Date: 29 Oct 2000 14:00:19 GMT
[EMAIL PROTECTED] (Bryan Olson) wrote in
<8tgmd1$35i$[EMAIL PROTECTED]>:
>Tim Tyler wrote:
>> Bryan Olson wrote:
>No. Just don't bother with the pointless non-standard
>padding schemes.
The problem is the so called standard padding schemes suck
and to stick ones head in the sand and use no new padding
schemes that are better while allowing underlying block
encryption progrmas to chane is stupid. Especaill when most
real world breaks occur due to know weakness in the resulting
cipher test. Why on earth not use something that does not add
any information to the resulting file.
>That's where you've made your mistake - moving away from
>the standard padding schemes solves no problem.
>
WHY? Do you naviely belive the current padding schemesa
are written on some holy grail. They are not and they are
plain stupid.
>
>As John Myre wrote
> Nobody with any sense cares, and you know why.
I guess becasue you think you have specail special
sense that makes only your views correct. Well you wrong.
>And yet your examples fail. You thought small messages
>can't cover the unicity distance; not so since you can send
>more than one. You thought intercepted encrypted messages
>won't have useful redundancy. Did it occur to you that the
>attacker could have intercepted the same messages, or that
>the original sender is a likely attacker?
All an attacker could learn from exteremly short messages
if he could do this type of chosen text attack is what message
a few characters long are. He is no closer to solving what any
message of over a few bytes is. That is unless Rijndael is
inheirently weak in the first place. Also what we are discussing
is a single tool and how it should preform. If one is in battle
one would send long messages and would use something like the
example of my rotat and dsc to add ransom data to the file and
rotate it before Matts code is called. One could aslo add a digital
signature after Matts code used.
Another point is although Matts code is 1-1 (unadulterated bijective
whatever) It does not mean that one byte of plaintext maps to one
byte of cipher test. It just means all is used. And most likey one
byte of text would map to 16 bytes of output. While 16 bytes of
input could map to one byte. So the padding as you would call it
is not what you think. In fact I dare say it hasn't been used in
any program combination compression encryption till matt coded it
up for easy use.
I would say you have to open up your closed mind as hard as that
is and check it out.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Date: Sun, 29 Oct 2000 14:04:39 GMT
On Sun, 29 Oct 2000 11:58:45 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>Probably I misunderstood. If key and IV and what not are
>the same, then one plaintext message cannot produce more
>than one ciphertext message and vice versa. I don't yet
>understand why there is non-bijectivity. Could you please
>explain a bit? Or is the issue that of his 1-1 compression
>which has nothing to do with the encryption as such? Thanks.
Well, if the key is the same, then one plaintext message can produce
as many different ciphertext messages as there are possible IV values.
And the issue is concerned with the overall context of encrypting
messages, which has nothing to do with the fact that the block cipher
Rijndael is bijective by itself on blocks, so it is sort of what you
are saying.
Of course, that is swiftly not becoming the issue; instead, the issue
is how one can act like Humpty Dumpty in Alice in Wonderland, and then
call someone a liar and "stupid" simply because he interprets English
sentences as having their usual meaning.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: Sun, 29 Oct 2000 14:10:02 GMT
On Sat, 28 Oct 2000 17:07:32 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>I do of course agree that mathematical models *can* help, but I do not
>agree that they *necessarily* help. This discussion of OTP's is one
>case in which the mathematical model provides nothing we can rely upon
>in practice.
If by practice you exclude low-bandwidth applications where the pad is
generated by, say, rolling dice, I might be less completely in
disagreement with that.
Of course, the proof really is important in telling us what we
*cannot* rely upon. It tells us that when our key is short, we can
always fall prey to the brute-force search.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: Sun, 29 Oct 2000 14:12:03 GMT
On Sat, 28 Oct 2000 17:45:53 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>On Sat, 28 Oct 2000 09:58:24 -0700, in
><[EMAIL PROTECTED]>, in sci.crypt Sundial Services
><[EMAIL PROTECTED]> wrote:
>>[...]
>>Having said that, however, I must go on to say that OTP is rather an
>>exception to that rule, or maybe, an extreme example of it. We can
>>prove that, "except for that wild card," OTP is impregnably secure.
>I'm sorry, but that is fundamentally wrong: We cannot *prove* any
>such thing about any *real* system which simply claims to be an OTP.
>We can't *prove* that any generator meets OTP needs, and thus cannot
>appeal to results from the OTP theoretical model. It probably is
>secure, but there can be no proof.
This _appears_ to be a quibble about language. If you exclude the
"wild card", then you are not talking about a "real" system, so a
proof can exist subject to that constraint.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: DATA PADDING FOR ENCRYPTION
Date: 29 Oct 2000 14:10:24 GMT
[EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>: [EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>:>SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>:>: [EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>
>[what Applied Cryptography has to say about padding]
>
>:>:>we also have a method which does not change the size of the message.
>:>:>
>:>:>The idea is to encrypt the last full block *again* truncate this to
>:>:>the size of any short block at the end and XOR this with the plaintext
>:>:>of the short block (rather than encrypting that with the cypher).
>:>:>
>:>:>This means that the OFB-like bit-flipping attacks can only be applied
>:>:>to the short block at the end. (2nd e. p. 195 for details).
>:>:>
>:>:>This method gets a bijection - at the expense of not encrypting the
>:>:>end of the file very securely.
>:>
>:>: Tim I may by wrong but I don't see how it gets a bijection of all
>:>: 8 bit file to all 8 bit files. Example if the encrypted file is one
>:>: byte long [...]
>:>
>:>The case of a single block is not explicitly mentioned.
>:>
>:>It can be dealt with (for example) by encryping a block of zeros
>:>and XORing that with the plaintext.
>:>
>:>I.e. "encrypt the last full block *again* (or encrypt zero if there
>:>is no full block in the first place)...".
>:>
>:>I believe this method gets a bijection - though any fractional last
>:>block is susceptible to bitflipping attacks - and such problems would
>:>not normally be tolerated.
>
>: I am not saying thats its not possible, It is just that the
>: procedure is incomplete and can't be directly bijective unless
>: it tells explicitedly how to create an ecnrypted file shorter than
>: a block. [...]
>
>Applied cryptography is a kind-of chatty book. The author is describing
>the algorithm, not presenting a full working algorithm. I expect he
>would consider the case of a single block to be a simple degenerative
>case.
>
I guess by that you could mine he did not understand the problem
well enough to make it a complete solution. Many after he studys
Matt niffty approach he will fix it up in the next release.
>Anyway, I missed out another important bit:
>
>After describing the bitflipping problem, it goes on to say:
>
>``Ciphertext stealing is a better way (see figure 9.5[snip ref]).
> [snip description which makes little sense withouut the diagram]
> The benefit of this method is that all the bits of the plaintext
> go through the encryption algorithm.''
>
>I believe this is bijective *provided* more than 1 block is present.
I don't like to think I'm a purest. But it is sort of skipping
the problem. Especailly when it can be solved with a little thought.
>
>It seems that the plaintext and the cyphertext are always the same
>length under such conditions, anyway.
But when one solves the whole problem for all files this
goes away. What happened is the same thing as in bzips's poor
run lenght encoder. It was really never gived enough thought to
do it right the first time.
>
>It pads with (say) zeros, encrypts, and then uses some clever XORing
>to make sure that truncating the cyphertext does not lose any
>information.
>
>AFAICS, ciphertext stealing does genuinely *not* work with short single
>blocks.
>
>http://www.io.com/~ritter/NEWS4/CTXSTEAL.HTM discusses the case of
>applying ciphertext stealing to single blocks in more detail.
>
He may have to update this after he looks at Matts clever code.
>Ciphertext stealing in conjunction with OFB (i.e. simple XOR) for
>single blocks would be bijective (I believe) - and it's weakness
>would probably arise only infrequently in practice.
>
>At any rate, this is the best traditional method of dealing with
>the combination of large-power-of-two size block cyphers and real
>world files that I have seen to date.
Have you lookes at Matts method yet.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
Date: Sun, 29 Oct 2000 09:31:48 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Terry Ritter wrote:
> And if you want to use overall network delays as your base, presumably
> you will assure that the Opponents will not be reading the traffic on
> the network. Otherwise, they can read the differences as well as you.
> Better, probably.
As I'm sure you know, the worst threat is not that the Opponents can read the
differences better than we can. The worst case occurs when the Opponents control
the differences. In that case our OTP pad "jest happens" to be a trivial pattern,
and we'll ascribe the flaw to the exigencies of true randomness rather than enemy
activity.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Date: 29 Oct 2000 14:26:34 GMT
[EMAIL PROTECTED] (Brian Gladman) wrote in
<24TK5.3148$zO3.88341@stones>:
>"John Savard" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> On Sun, 29 Oct 2000 00:59:37 +0100, "Brian Gladman"
>> <[EMAIL PROTECTED]> wrote, in part:
>>
>> >No it was not a lie and it most certainly does not depend on how
>> >Rijndael
>is
>> >implemented.
>>
>> I can't defend the style of his comments, but he doesn't mean that
>> Rijndael, the block cipher, isn't bijective over the domain of 128-bit
>> blocks.
>
>I am glad that you have a paranormal ability to translate what he says
>into what he means to say but most of us don't have such powers. In
>consequence we have to take what he says at face value and in this
>context much of what he says is worthless. He has said that asserting
>that Rijndael is bijective is a lie. He is wrong - within its domain of
>operation Rijndael is bijective and whatever he or anyone else does with
>it ***externally*** does not change this.
>
>> He is talking about bijectivity over the domain of messages. And one
>> certainly can use Rijndael in one of those block cipher modes which
>> require an _initialization vector_.
>
>As you know, Rijndael does not deal with "messages" - all it knows about
>are sets of bits without any semantic meaning - 128 bits in its input
>and output blocks and sets of 128, 192 or 256 bits in its key input
>blocks. The statement he called a lie was about ***Rijndael*** - it was
>not about a feedback mode or some wider product that uses Rijndael, even
>if this is actually what was in his mind.
As you should know by know Matts faithful implemention of Rijndael
with compression is fully bijective to any 8-bit byte file. Just
because one is useing a large block file does mean the input and
output file to such a program has to have the fixed mutliply block size.
Just becuase others have been so stupid to try to force this in their
code does not mean its the only way. WHen Matt calls Rijndael it uses
it faithfully to the spec. He even use the spec code. I suspect
when the dust settles done. Unless the MSA fucks it up. Eventually
most real public impliments will copy this superior type of method.
Or use something damn close.
>
>At the moment I have been pointing out the consistent stupidity of much
>of what he says as an experiment to see his reaction and in the hope
>that this will either (a) encourage him to be more careful, accurate and
>considerate in his responses (and hence more effective in influencing
>others to take him seriously), or (b) attract further idiotic outbursts
>from him and hence reinforce the already widespread view that his
>contributions are worthless (they aren't all worthless but those that
>have some value are completely obscured by the attitude to others that
>his postings exhibit).
>
To sum it up you as well as Tim and most know exactly what I said.
So you are just picking nits. It was a lie plain and simple and you
know it. When one discusses something a lot of what is said relies on
what is previously said. One does not need or should not need to go
over the basic prerequists over and over. My style is my style. True
maybe fewer people well take wHat I say as true. But I don't care if
the assholes who get offended by my poor ability to write can't belive
it becuase of me. They don't desrive to know the truth if they are so
blind as to think sugar coating makes it more true. Those people can
waste there money on MR BS book and let him be their truth filter.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Date: 29 Oct 2000 14:39:14 GMT
[EMAIL PROTECTED] (Brian Gladman) wrote in
<K4VK5.3233$zO3.92645@stones>:
>
>"Tim Tyler" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> Tom St Denis <[EMAIL PROTECTED]> wrote:
>> : [EMAIL PROTECTED] wrote:
>> :> Tom St Denis <[EMAIL PROTECTED]> wrote:
>> :> : [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>> :>
>> :> :> If you folks check at comp.compression you we see a note
>> :> :> from Matt Timmermans on his super bijective PPM compressor
>> :> :> with a built in bijective RIJNDAEL in modied CBC mode. [...]
>> :>
>> :> :> http://www3.sympatico.ca/mtimmerm/bicom/bicom.html
>> :>
>> :> : Perhaps us "know nothing" people prefer to leave our security to
>> :> : security related algorithms.
>> :>
>> :> I believe that's why the product includes a bijective version of
>> :> Rijndael [...]
>>
>> : Of course Rijndael is bijective it's a friggin block cipher.
>>
>> That's not the point. Have you considered issues related to dealing
>> with files which are not exact multiples of the Rijndael block length?
>>
>> Can you point me at any other implementation of Rijndael where
>> decrypting an arbitrary cyphertext, and re-encrypting again with the
>> same key produces exactly the same file?
>
>He cannot do this because this is not what Rijndael does. Rijndael (in
>its AES form) operates on sequences of 128-bits on which the algorithm
>imposes no semantics other than the order and placement of the bits in
>the sequences. To encrypt a 'file' there has to be additional code and
>this might, or might not, produce results that are bijective.
>
>The big problem in this debate is that the term 'file' is ill-defined.
>I can certainly define a file in a particular way and trivially produce
>a program, using Rijndael, that decrypts and re-encrypts to produce the
>original file. But my guess is that what I would define as a file
>others would see differently.
>
>It would certainly help this debate if someone who thinks they know what
>is meant by the term 'file' in the context of bijective compression
>could ***carefully*** specify their use of this term.
>
> Brian Gladman
>
>
Brain Glady will i do that. In the case of matts program think of
file as a any set of bits ( where a bit has a only two vlasue "0" or
"1") and the number of bits that represent this file when divided by
8 will exactly match a number in the set { 1 2 3 4 ...)
I hope that is specific enough. Matts program magically maps every
member to every other member in a unique way based on the key.
The main way it does this is he cleverly compresses to a intermediate
file that is infinite in length. This infinite file has at last one
bit that is a one. And the last bit that is a one is a finite distacne
from the start. He then basically encrypts this file wiht Rijndael use
full block sizes to map it to another unique file in the specail
cinsturction. When this process is done he converts the output back
to normal files as descriped at start of this paragraph.
Know this is a quick summary and not fully detailed. But I hope you
get the drift. Check out his code.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
