Cryptography-Digest Digest #491, Volume #13 Thu, 18 Jan 01 18:13:01 EST
Contents:
Re: SAC question (Tom St Denis)
Re: block algorithm on variable length without padding? (Terry Ritter)
Re: block algorithm on variable length without padding? ("N. Weicher")
Re: Where can I find software tools for Known-text decryption ("Joseph Ashwood")
Re: [H] one-way hash functions ("Joseph Ashwood")
Re: block algorithm on variable length without padding? ("Joseph Ashwood")
Re: using AES finalists in series? ("Joseph Ashwood")
Re: using AES finalists in series? (Terry Ritter)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: SAC question
Date: Thu, 18 Jan 2001 22:00:09 GMT
In article <[EMAIL PROTECTED]>,
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> > > No. The strict definition of SAC says output bits change 1/2 of the time. If
>the count is 2^(n-1) that it changes, then the count is 2^(n-1)-1 of it not changing.
> Since (2^(n-1))/((2^n)-1) is not 1/2, then no substitution box of finite size is SAC.
> >
> > I beg to differ. If there are 256 possible inputs, then it must flip for 128 of
>them and not flip for 128 of them. That satisfies SAC.
>
> In an 8x8 table, you can count 256 possible changes only if you count a change of 0
>bits as a change. If you consider a change of 0 bits to not be a change, then there
>are 255 possible changes. If each of those 255 possible input changes produces an
>output change, well, there are 255 possible output changes. Consider just the first
>bit of output: the output change values 1..127 produce a change of 0 in the first
>bit; the output change values 128..255 produce a change of 1 in the first bit. There
>are 127 cases where the first bit doesn't change, and there are 128 cases where the
>first bit does change.
What are you talking about? SAC refers to SINGLE FREAKING
BITS!!!!!!!!!!!!!!!!!!!!!!!
So over all 2^n possible inputs it must flip 2^n-1 of the time, etc..
> > > Suppose I have an 8 bit table. Flipping 1 bit of input can cause any of 255
>different differences; The odds of a change is 128/255. Not 1/2. It's almost SAC,
>but it is not SAC.
> >
> > Yeah but SAC only concerns a SINGLE bit of input *AND* a SINGLE bit of output.
>Not multiple. So a 8x8 table can be SAC.
>
> Strict SAC requires that each input change cause each output bit to change with
>exactly 50% probability. As I said above, in an 8x8 table, nonzero input changes
>cause output bits to change with probability 128/255. 128/255 != 50%. This is not
>SAC.
Um over 256 inputs!!!! 128/256 = 50%. You are mixing differential
cryptanalysis with SAC. They ARE NOT THE SAME!
This is the SAC test.
Given a function F, of size 2^n.
Table A[n][n] initialized to zero
for x = 0 to n
for y = 0 to n
for z = 0 to 2^n
if flipping bit 'x' of 'z' causes bit 'y' of the output to flip
(i.e (F(z) ^ F(z^(1<<x))) & (1 << y))
add one to A[x][y]
else
sub one from A[x][y]
next z
next y
next x
If all the entries of A[][] are zero it's SAC.
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: block algorithm on variable length without padding?
Date: Thu, 18 Jan 2001 22:14:14 GMT
On 18 Jan 2001 20:27:40 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (DJohn37050) wrote:
>The previous ciphertext block for block number 1 is the initialization vector.
>This is best if it is varying, looks random, and is OK to be public. I thought
>this was well known.
Let me quote from the original question:
"what if padding is not an option, ie, the encrypted data must
be the exact same length as the plaintext data?"
There can be no initialization vector. I thought this was quite
clear.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
Reply-To: "N. Weicher" <[EMAIL PROTECTED]>
From: "N. Weicher" <[EMAIL PROTECTED]>
Subject: Re: block algorithm on variable length without padding?
Date: Thu, 18 Jan 2001 22:13:43 GMT
I'm not sure I follow you. Let's say that you have N blocks, but the Nth
block contains less than 8 bytes (for convenience we'll assume N > 1 so we
know we have at least one full block).
Are you saying that the final block is computed as follows? I.e., the
partial final block is XORed with the next to last encrypted block?
C(N) = P(N) ^ C(N-1)
In this case, all you need to do to recover the final partial block is to
XOR it with the encrypted next-to-last block. You don't even need to know
the key.
If this is not what you mean, how are you encrypting the final partial
block?
I must be missing something here.
Thanks for the feedback (no pun intended <g>).
Neil
==================================================
"DJohn37050" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> You can also use ciphertext stealing from the previous block to fill out
the
> last block. This is no weaker than CBC. The trick comes in deciphering,
you
> need to handle the last partial block and previous full block
appropriately,
> but this is not hard to figure out.
> Don Johnson
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Where can I find software tools for Known-text decryption
Date: Thu, 18 Jan 2001 14:13:29 -0800
> Are there any availble software tools for Known-Text decryption?
There are several, for different encryption types. What is the encryption
algorithm? What you have may or may not be enough.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: [H] one-way hash functions
Date: Thu, 18 Jan 2001 14:15:49 -0800
The best advice we can give you on this is to do it the simplest way, pick 8
bytes you want to keep, and keep them. You can use the last 8 bytes, the
first, the middle, the first half of each byte. Just don't start playing
with extra has functions afterward, you run a very real risk of weakening
the system (with hash functions in particular it is not difficult).
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: block algorithm on variable length without padding?
Date: Thu, 18 Jan 2001 14:09:35 -0800
That won't work very well with modern OSs. They actually changed the
filesystems in some systems because of a very similar issue (encrypted files
can contain EOF as a valid character). They now store the actual file length
and leave the file as is when storing it. So your EOF would have no effect.
Joe
"Adrian S. Thompson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> By placing an EOF (End Of File) at the beginning of the padding after
encrypting
> will trick the file system into thinking the file was as long as it was
before
> the padding as added.
>
> Hypothetical ie.
>
> 77k = file size
> 3k = padding
>
> the encrypted text after padding would be 80k; after placing the EOF at
the
> 77001byte place, the OS/App would only see 77k of data. This would keep
the
> plaintext and the cyphertext the same size.
>
> Take care,
> -=Adrian=-
>
> "N. Weicher" wrote:
>
> > But then you fail the requirement that the ciphertext be the exact same
> > length as the plaintext, unless I am missing your point.
> >
> > Neil
> >
> > -----------------------------------------------
> >
> > "Adrian S. Thompson" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > Hi,
> > >
> > > Couldn't a person just pad the plaintext, encrypt the plaintext, then
> > place an
> > > EOF at the first byte of the padding? Just a hypothosis. ;-)
> > >
> > > Take care,
> > > -=Adrian=-
> > > > N. Weicher <[EMAIL PROTECTED]> wrote in message
> > > > news:kAj96.59822$[EMAIL PROTECTED]...
> > > > > Is it possible to use a block algorithm (such as Blowfish or DES)
to
> > > > encrypt
> > > > > plaintext where the length is not a multiple of eight bytes? I
know
> > about
> > > > > padding, but what if padding is not an option, ie, the encrypted
data
> > must
> > > > > be the exact same length as the plaintext data? Is this feasible?
If
> > so,
> > > > > how is it done?
>
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: using AES finalists in series?
Date: Thu, 18 Jan 2001 14:23:24 -0800
Of course you can. There is no known weakness created by doing so. It is
extremely unlikely that such a weakness will ever be found. However it is
not necessarily true that by adding another cipher the security must
increase. Allow me to demonstrate with a very contrived example. Take two
ciphers, DES and DES' where DES' is the decryption sequence for DES, key
them with the same value. Viola, all security disappears. A less contrived
example is that of 2DES (DES(key1, DES(key2, data))), where it was shown
that it was no stronger than DES (meet in the middle attack). However the
AES finalists offer enough diversity that this is very unlikely to be the
case. However to have a higher assurance in this regard I would recommend
that you use independent key material for each, this makes it less likely
that a flaw will be found.
Joe
"Gary Watson" <[EMAIL PROTECTED]> wrote in message
news:nuF96.1804$wL5.36733@NewsReader...
>
> If one had sufficient CPU power or minimal throughput requirements, is
there
> any reason why one couldn't use all five AES round two finalists in
series?
> This would guard against a weakness being found in one of them, or if one
or
> two of the candidates were deliberately weak systems promulgated by
sinister
> government forces. (Is it necessarily true that security must improve at
> least a little each time you run the ciphertext through a new crypto
> algorithm? Don't know, this isn't my line of work...)
>
> As a side note, if a government or large company implements its crypto in
an
> FPGA, why not distribute the entire FPGA design as the keying material?
It
> fits in a $5 serial prom the size of your fingernail; it's loaded once
and
> then the keying material is removed and possibly destroyed. You could
have
> a room full of semi-trained people generating variants of the chosen
cipher
> and re-running the synthesis tools, or maybe automate the process using a
> bit of clever VHDL such as multiple architectures per entity in each major
> functional block, and the architectures would be selected randomly before
> synthesis.
>
> --
>
> Gary Watson
> [EMAIL PROTECTED] (you should leave off the digit two for email)
> Nexsan Technologies Ltd.
> Derby DE21 7BF ENGLAND
> UK-based Engineers: See our job postings at
> http://www.nexsan.com/pages/careers.htm
>
>
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: using AES finalists in series?
Date: Thu, 18 Jan 2001 22:31:42 GMT
On Thu, 18 Jan 2001 14:08:34 -0800, in
<[EMAIL PROTECTED]>, in sci.crypt Roger Schlafly
<[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>> >Sure, you can do all those things if you want. But your ideas are
>> >directly contrary to the idea of a standard. The point of AES is
>> >to have one cipher that is efficient and secure for a lot of
>> >people to use and interoperate. It is not to encourage people to
>> >roll their own crypto because they don't trust the AES design.
>> Wrong. The point of AES is to have a government-approved cipher so
>> banks need not worry about legal liability.
>
>They already had that with triple-DES.
OK, they wanted a faster solution.
>> "Interoperation" is precisely what we design ciphers to not do.
>> Ciphers specifically do not interoperate without correct keys. But if
>> we can deliver correct keys, we can also deliver the correct cipher --
>> or perhaps just a description of what the correct cipher should be.
>
>Those with no need or use for standardization can ignore the standard.
I would say "should."
>> AES is of course an attempt to limit cipher development, and
>> especially to limit the profits available to continue cipher
>> development.
>
>If so, then it has been a huge failure. It sure looks to me that
>AES has spurred the development of good ciphers.
There is no industry of cipher design to fund industrial research and
development into cipher design and testing. AES brought forth a few
academic-type designs, with ad-hoc, unplanned, donated testing. It
seems strange to see someone promote that as a good process.
>> A widely-used standard cipher is the best possible target for real
>> cryptanalysis. By breaking only one cipher, one exposes a fount of
>> information, and nobody will know -- or can afford to believe -- that
>> has happened. Absent unarguable proof of strength, embracing any
>> single cipher puts real security at risk.
>
>The internet is a target for similar reasons.
Yes, the internet is insecure.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
** 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
******************************
