Cryptography-Digest Digest #443, Volume #10 Sun, 24 Oct 99 21:13:03 EDT
Contents:
Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E (Anthony Stephen Szopa)
Re: compression and encryption (Tom St Denis)
Re: Key size vs number of rounds (Mok-Kong Shen)
Re: Unbiased One to One Compression
Re: Unbiased One to One Compression
Re: Unbiased One to One Compression
Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E (Tom St Denis)
Re: compression and encryption (Tom St Denis)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
([EMAIL PROTECTED])
Re: Portable crypt() function (Chad Hurwitz)
----------------------------------------------------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E
Date: Sun, 24 Oct 1999 12:45:56 -0700
Reply-To: [EMAIL PROTECTED]
Tom St Denis wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E
> >
> > You don't have to buy the software. It is shareware.
> >
> > This means you can have the software delivered for free via email for
> > evaluation purposes.
> >
> > This is noted in very large FLASHING bold letters right at the top of
> > the web page.
> >
> > Are you saying that none of you noticed this?
> >
> > Get the software.
> >
> > http://www.ciphile.com
>
> Reasons for not using ciphile software:
>
> 1) Author does not seem to know much about cryptography in general.
>
> Proof. 'Pseudo-OTP' are not OTPs. No matter how you word it.
>
> 2) The author uses non-accepted or studied methods.
>
> Proof. The generator is a large ROTOR which has been dropped quite a
> while ago. It's also inefficient and most likely not very secure at
> all.
>
> 3) The software provides only the ability to use one algorithm with
> passwords you have to remember.
>
> OR you could get PGP (http://www.pgp.com) which has been accepted for
> some quite time.
>
> I have also recently developed a message encryption program (which is
> free, includes source and is pretty much the most compact win32 program
> I have ever seen). It lets the user pick from one of seven popular
> block ciphers, provides diffie-hellman key exchange (don't have to
> remember passwords). at
> http://www.cell2000.net/security/peekboo/index.html
>
> Just my opinion.
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
You are afraid to get the software: OAP-L3.
You have talked yourself into a corner and everyone knows it.
If you were to get the software and found out you are completely wrong then
you would have to eat your words: quite a belly full.
We are not holding our breath waiting for you to get the software.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: compression and encryption
Date: Sun, 24 Oct 1999 19:59:07 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Jerry Coffin) wrote:
> If you've written so many compressors and taught information theory,
> then how is it that you know SO little about compression and
> decompression? Your statement is simply blatantly false. It's
> entirely possible (and in fact pretty simple) to come up with a
stream
> that an LZSS or LZW compressor simply can't decompress. I suppose
> from a technical viewpoint, they can produce SOME output, and if the
> programmer was any good, it'll probably be sensible -- something like
> "ERROR: Corrupt input file" should be about right.
>
> It IS true that with something like Huffman compression that any
input
> bit pattern will decompress to something, but to make a long story
> short, the absence of a header does NOT mean that others will do so
at
> all.
>
In LZ77 for example with <index, length, literal> codewords it's
impossible to have an invalid code. The <index> is a fixed length of
bits and will always be in the window somewhere. etc...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Key size vs number of rounds
Date: Sun, 24 Oct 1999 22:19:08 +0200
Jerry Coffin wrote:
>
> Looking at things much more specifically and directly: a round of a
> cipher will diffuse the results of changing a given bit in the input
> over a given number of bits in the output -- e.g. changing one bit of
> input might affect three different bits of the output after one round.
> Your aim is to have each bit of the input affect ALL the bits of the
> output.
>
> If you have a diffusion rate of 3 bits per round as the example above
> does, then as you increase the block size, you have to also increase
> the number of rounds before each bit of input has had a chance to
> affect all the bits of the output.
>
> You also want changing any bit of the key to affect all bits of the
> output. Again, the effect happens at a more or less constant rate per
> round, so as you increase the key size, you also have to increase the
> number of rounds to have each bit of key affect the entire output.
>
> The TwoFish team took a slightly different approach: instead of
> increasing the number of rounds, they increased the diffusion rate --
> e.g. increasing the diffusion rate from 3 bits per round to 5 bits per
> round.
>
> Note that the numbers I'm using are purely artificial -- I'm not
> suggesting that they apply to any particular cipher at all. In fact,
> unless memory serves me ill, 3 and 5 bits per round are both
> substantially lower than most modern ciphers achieve. Note, however,
> that (for example) among the AES finalists, there's quite a bit of
> variation here, which accounts for some of the differences in the
> number of rounds used in different ciphers. You can use a LOT of
> really simple rounds, or you can use fewer rounds, each of which is
> more complex and diffuses changes more widely.
Thank you for the explanation. The question may be asked whether
the realizablity of an increase of diffusion rate per round is
dependent on the increase of the key and block size. If the answer
is yes, then it is at least conceivable that the round number could
under circumstances be decreased as the key and block size increases.
If the answer is no, then the diffusion rate is to be considered
as another design dimension to be optimized. Anyway, I guess it is
probably correct to say that Massey's statement does not have general
coverage.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Unbiased One to One Compression
Date: 24 Oct 99 20:46:29 GMT
Tim Tyler ([EMAIL PROTECTED]) wrote:
: I have a high opinion of John Savard, based on his usenet contributions.
Why, thank you.
: However, I'm not sure I've done as well as I could have done in explaining
: why having one - and only one - decompressed file for every compressed one
: is potentially important to security.
: If you *don't* have this, then the compressor, when compressing, can
: choose more than one compressed file to compress to.
: If the compressor chooses between these files at random, then there's no
: security problem - you just wind up with fatter compressed files than you
: need to.
Yes, you need to choose between those files at random.
: Making the cypher "one-on-one" avoids the possibility of any information
: or regularity *added* by the compressor being used in the attack on the
: cypher - since no information has been added.
: Attacks can still be based on any regularities left by sub-optimal
: compression, though.
There is a problem with one-to-one compression.
As I recently noted, I had found a way to perform Huffman compression so
as to approximate the one-to-one condition between the files to be
compressed, and strings of bits of arbitrary length.
But the next step, converting to a message that is a whole number of bytes
in length, is the problem.
Here is an example of a mapping between messages an arbitrary number of
bits in length, and messages that are an even number of bytes long.
Leave all of the message alone, except for the last 0 through 7 bits.
These may have 255 possible values, so these can be coded in the last byte
as follows:
Code Represents
00000000 not used
00000001 <nothing>
00000010 0
00000011 1
00000100 00
00000101 01
00000110 10
00000111 11
00001000 000
...
00001111 111
00010000 0000
...
00011111 1111
00100000 00000
...
00111111 11111
01000000 000000
...
01111111 111111
10000000 0000000
...
11111111 1111111
Each byte represents the bits that follow the first 1 in the byte.
This is the most efficient way to represent arbitrary-length bit strings.
What is wrong with it?
When we compress a message, it is reasonable to expect that, for good
compression:
- the probability of each bit in the compressed message being a 0 or a 1
is 50% each way, and
- the probability of the number of bits in the message being of the form
8n+k, for k from 0 to 7, is 12.5% for each value of k.
Given that, we find that the last byte of the message, using the
representation above, has the probabilities:
00000001 12.5%
00000010 6.25%
00000011 6.25%
00000100 3.125%
...
00000111 3.125%
00001000 1.5625%
and so on.
This problem is _fundamental_, and not due to my particular choice of
representations. The probability distribution of "random strings of bits
of arbitrary length" and of "random strings of bits an even number of
bytes in length" are different in shape.
Of course, simple techniques can distribute this bias throughout the
message. For example, XOR the last byte with a checksum of the rest of the
message.
But in that case, the whole idea of one-to-one compression is not
necessary, since whether or not the message ends in the middle of a
Huffman symbol can only be found out by reading the message from beginning
to end.
Adding random padding, on the other hand, lets the two probability
distributions match in shape. The case that is twice as likely as another
case has one more bit of random padding added to it.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Unbiased One to One Compression
Date: 24 Oct 99 20:49:32 GMT
Tim Tyler ([EMAIL PROTECTED]) wrote:
: However, if you *systematically* choose to compress to one type of file
: rather than another one, your compressor may well be adding information to
: the compressed file, which was not present in the original message.
: It /may/ be possible for an attacker to utilise information added in
: the process of compression to aid his attack on the subsequent cypher.
: Making the cypher "one-on-one" avoids the possibility of any information
: or regularity *added* by the compressor being used in the attack on the
: cypher - since no information has been added.
And, by the way, there is a section on my web page about "Red Thread
Resistance", which talks about ways to minimize an encryption program's
opportunity to exploit a subliminal channel by means of random IVs and the
like.
However, I felt that the small number of bits added - at the very
beginning of encipherment - to make the number of bits come out to an even
multiple of 8 was not a significant hazard, even if other things, like
64-bit IVs, can be usefully eliminated.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Unbiased One to One Compression
Date: 24 Oct 99 20:52:09 GMT
SCOTT19U.ZIP_GUY ([EMAIL PROTECTED]) wrote:
: But could you anwser one question directly. Can your compress/decompression
: method take a random binary file of bytes then uncompress it a file. Which
: when compressed will give back this same file? I don't think this question
: is to hard to anwser or to test for. But I either think you don't understand
: this or don't want to understand this particular point.
No, it can't, and thus it isn't really "one-to-one". It only satisfies the
weaker condition that decompression is "onto". When compressed, a file
gives one of the files it could be decompressed from. In a response to Tim
Tyler's post, I explained the reason that I have avoided the one-to-one
method that I can think of.
John Savard
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E
Date: Sun, 24 Oct 1999 21:09:47 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> You are afraid to get the software: OAP-L3.
Um stupid, I already got the software and your 'paper' on it a while
back when you emailed me at goplay.com. I determined at that time that
you were a clueless snake oil peddler.
> You have talked yourself into a corner and everyone knows it.
Yup.
> If you were to get the software and found out you are completely
wrong then
> you would have to eat your words: quite a belly full.
>
> We are not holding our breath waiting for you to get the software.
Who is we? You and your alternate personality? Look if you want to
make it in sci.crypt you have to be a bit more intelligent. Your site
smells like snake oil (whatever that smells like) to me. Clean up your
site, and change your attitude.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: compression and encryption
Date: Sun, 24 Oct 1999 21:06:15 GMT
In article <r7JQ3.5246$[EMAIL PROTECTED]>,
gtf[@]cirp.org (Geoffrey T. Falk) wrote:
> Precisely. I was not talking about LZ, which are far from headerless
> algorithms. All flavours of Lempel-Ziv rely on pointers throughout the
> message, which essentially provide header-type information that can
> be used by an attacker.
>
> An example of a headerless algorithm would be adaptive arithmetic
> or Huffman coder/decoder. The output can be considered as a bit stream
> with no special structure.
If I am not mistaken LZ methods have no implicit header information.
They build their 'dictionaries' as they process the input. Just like
adaptive single symbol entropy coders (i.e huffman, arith, range,
etc...)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 24 Oct 1999 21:26:59 GMT
In article <7uueot$[EMAIL PROTECTED]>,
"Roger Schlafly" <[EMAIL PROTECTED]> wrote:
> Even if your analysis is correct, it is stronger by only a trivial
> amount. It would be more secure to just increase the key size
> by a few bits.
If my analysis is correct then it shows that it does make sense to use
a pool of independent ciphers because it increases security (against
any attack) without decreasing the speed of the system.
Now, I agree that if the pool is not very large then the practical
advantage is negligible. If somebody discovered a k=0.5 attack against
the AES class ciphers then the "fourAES" cipher I described would
increase the cost of attack only in 25% (not even one additional bit of
security).
Using multiple ciphers becomes interesting only with M>>1. Let us for a
moment assume we had 2^128 independent ciphers (M=128). If we use only
one of them with a key of 256 bits and somebody discovers an k=0.2
attack then we get a cipher with 256*0.2=51 bits of effective security,
i.e. we have a catastrophic failure in our hands. If, on the other
hand, we use all of them with a key of 128 bits and use the other 128
bits of the key to index the pool of ciphers, then the average cost of
the attack 2^(k*N-1)*(2^M+1)=2^153, i.e. it would afford us a very
significant 153 bits of security.
How do we get 2^128 ciphers? First of all observe that each individual
cipher can be very weak indeed. For large M, the cost of breaking the
"pooled" cipher would be 2^(k*N+M-1), i.e. that cipher's strength would
be k*N+M-1 bits. Even if k=0.01, i.e. even if each individual cipher
offers only 1.28 bits of security, the "pooled" cipher would still
offer 128.28 bits of security. So the question here is how to produce a
great many independent ciphers without much thought about the strength
of each individual one.
The best way I can imagine to achieve this is to create a cipher
generator: take a large number of bits out of the key and use them to
produce a cipher (code+tables). Use the rest of the key plus the
plaintext blocks to drive that cipher and produce the ciphertext.
This is almost exactly what my Frog algorithm does. Only about 5.6% of
the key material is really used as key data. The rest is used for
building tables and for "expressing" code. The AES specifications
didn't allow assembly code - therefore the only code variability I
included in my AES candidate was key dependent addresses. Frog is not
unique in that respect. Twofish can also be considered a "pool" of 2^64
ciphers because it uses that many key dependent tables. The big
question for any such cipher is whether the cipher instances are
independent.
I have written a more generalized version of Frog that works like a
compiler and literally produces code. That version generates key
dependent instructions as well as key and data dependent addresses.
Therefore, arguably, the generalized version of Frog covers a much more
"variable" subset of the cipher space, which brings it nearer to the
ideal of a generator that produces independent ciphers.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Chad Hurwitz)
Subject: Re: Portable crypt() function
Date: 24 Oct 1999 15:08:04 -0700
In article <7uvfcj$[EMAIL PROTECTED]>,
Chad Hurwitz <[EMAIL PROTECTED]> wrote:
>
>Is there a standard function that will be in a library on both a microsoft
>platform AND a unix platform? I can't find any crypt library functions
>in micro$ofts Visual C++ compiler help.
>
>If not, is there source publically available for a portable
>crypt(key,message) and decrypt(key,crypt_message) or are these kind of
>things government regulated?
>
>--
>/-------------------------------------------------------------------\
>| spam if you can, spam if you dare, spam if you must, i won't care |
>| spam is futile, spam is free, spam is filtered, so i won't see |
>\-------------------------------------------------------------------/
to answer my own question i found a nice link
http://www.eskimo.com/~weidai/cryptlib.html
--
/-------------------------------------------------------------------\
| spam if you can, spam if you dare, spam if you must, i won't care |
| spam is futile, spam is free, spam is filtered, so i won't see |
\-------------------------------------------------------------------/
------------------------------
** 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
******************************
