Cryptography-Digest Digest #476, Volume #10 Sat, 30 Oct 99 23:13:04 EDT
Contents:
Re: How to use CBC w/ RC4? ([EMAIL PROTECTED])
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
([EMAIL PROTECTED])
Re: How to use CBC w/ RC4? ([EMAIL PROTECTED])
Re: compression and encryption (gtf[@])
Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E ([EMAIL PROTECTED])
Re: Newly Encountered Crypto System ([EMAIL PROTECTED])
Re: Some humble thoughts on block chaining ([EMAIL PROTECTED])
Re: Compression: A ? for David Scott (Clinton Begin)
Re: Bruce Schneier's Crypto Comments on Slashdot (Matt Curtin)
Re: Compression: A ? for David Scott (Tom)
----------------------------------------------------------------------------
Date: Mon, 25 Oct 1999 14:49:33 +0200
Subject: Re: How to use CBC w/ RC4?
From: [EMAIL PROTECTED] ([EMAIL PROTECTED])
On Mon, 25 Oct 1999 12:38:45 GMT, [EMAIL PROTECTED] (Tom) wrote:
>>As I understand it, using RC4 without an IV or feedback to encrypt
>>multiple messages with the same key makes a known plaintext attack
>>trivial, as you just xor the known plaintext with the ciphertext to
>>recover the key stream.
Using RC4 without an IV, or just using the same IV for two different
messages
is easily attacked. You can XOR the two streams together and get a XOR of
the
two plaintexts, if both messages and normal english the attacker stands a
fair
chance of recovering both messages, even if no plaintext is known. That
is why
RC4 specifies a different IV for each message. If you aren't using a
different
IV for each message, you aren't using RC4.
The trouble with RC4 is coming up with IV values that are sufficiently
random
to prevent using the same one twice. With a truly random 80 bit IV, you
have
about a one in a million chance of repeating one of the IV values with one
billion messages sent. If you are using a computer RNG that only has 32
bits of
randomness to generate your IV, you hit your one in a million chance with
only
65 messages. There are various known methods of tweaking the IV generated
with
a 32 bit RNG to make sure they aren't easily repeated (XOR with current
system
date and clock digits, user keyboard keystroke timing, even keep a list of
used
IVs, ect.)
Johnny Bravo
{}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{}
{}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{}
{}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}
------------------------------
Date: Mon, 25 Oct 1999 19:52:04 +0200
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
From: [EMAIL PROTECTED] ([EMAIL PROTECTED])
In article <7v0ula$cc9$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Vernon Schryver) wrote:
>>
>> The worst result of the compression negotiation complications (as well
>as
>> egregious bugs by a large vendor or two, and a dose or two of
>> embrace-and-extend by a very large software outfit) is that you can't
>> count on your PPP data being compressed. The equivalent result for
>> negotiating ciphers, not being able to count on your data being
>encrypted,
>> strikes me as a little more serious.
It does not follow that if you pick a sending cipher, from a list that you
are ready to use, that you worry about your data not being encrypted. If
someone will not accept the same cipher(s), then you have a problem, so
you only negotiate one list of mutually acceptable ciphers. Compression
has nothing to do with it, unless both of you agree on a cipher that uses
it.
--
Sometime ago, Gates bought lots of shares of Apple.
My preference is to keep the Worm out of the Apple.
{}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{}
{}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{}
{}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}
------------------------------
Date: Mon, 25 Oct 1999 20:05:55 +0200
Subject: Re: How to use CBC w/ RC4?
From: [EMAIL PROTECTED] ([EMAIL PROTECTED])
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>> Trying to figure out how to use RC4 to encrypt multiple files, as on a
>> directory of a hard drive, with a single password. If you mean use a
>> different public IV to xor with the password to create the key to
>> initialize RC4, then I understand. If you mean a different password
>> for each file, then it would be a mess. The separate passwords would
>> have to be stored together in a file, then encrypted with a human
>> rememberable password.
>>
You do this right KEY = HASH(PASSWORD)
Just change that to KEY[i] = HASH(PASSWORD + SALTi)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
{}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{}
{}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{}
{}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}
------------------------------
Date: Mon, 25 Oct 1999 19:29:03 +0200
Subject: Re: compression and encryption
From: gtf[@] (gtf[@])
In article <7v0mc4$s62$[EMAIL PROTECTED]>,
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>>In article <1UMQ3.5326$[EMAIL PROTECTED]>,
>gtf[@]cirp.org (Geoffrey T. Falk) wrote:
>>>David's "1-1" criterion is not mathematically necessary. All that is
>>>necessary is to ensure that every file is a valid input file to the
>>>decompressor. If the algorithm is not "1-1" then some input files may
>>>produce infinite-length output files. But this does not help the
>>>attacker, because determining this is equivalent to the halting problem.
>>>
>> I think you are lost. If one is decompressing a file and it does not
>>stop uncompressing due to your method using an infinite loop. Then
>>you have a bad file and the key was wrong.
You missed my point. Detecting loops can be a hard problem.
One can detect certain kinds of loops easily, but in general the
problem of showing that the output of an arbitrary Turing machine
is infinite is intractable. This leads me to believe that your strict
"1-1" criterion is not necessary. There are non-bijective
compression algorithms which will give you the same thing. And
that is all I am claiming. I am not saying that your ideas are bad
or that your algorithm is bad.
>> I would also think you have a bad compression program if some of the
>>compressed files of finite length represent some infintie file.
Why? It would still work as a compression program. For that, all you
really care about is that you can take a real file, compress it and
decompress it back to the original file.
For cryptography, you also want the decompressor to process any file
and not signal an error message. You also want to make sure that
for a given X, either Comp(Decomp(X)) = X, or Decomp(X) is infinite.
Otherwise the attacker can try Comp(Decomp(X)) and if it does not
equal X, he knows he has the wrong key. But if Decomp(X) is infinite,
he can't even do this. And if you design your algorithm well, he
will have a hard time even detecting this possibility: Your file
might have a trillion zeros in a row--how can he prove it doesn't?!
>> Since the files I use all compressed files decompress to finite
>>files.
David, you can relax. I have nothing against your algorithm.
But it is not the only algorithm in existence...
>> You are also missing the point that if a file is decompressed you
>>want it to come back to the same exact file when compressed or
>>you are giving information to the attacker.
I am not missing that at all. The only thing that is different in my
scenario is the possibility of getting infinite-length files when
decompressing. But even if that happens, the attacker cannot be
guaranteed to detect it. He can only do it if he knows an upper
bound on the size of your plaintext. So, in a strictly theoretical
sense, this may not help him at all. That is all I am saying.
>>>In practice it is easy to imagine a decompressor that can produce
>>>infinite-length output files. All you need is a pointer that points back
>>>to itself and produces the same block of output over and over.
>> I grant that you could in therory write a compress decompression
>>program that would cause some files to uncompress forever however
>>this is not what the thread was about. And the adaptive huffman
>>coder will not do this. However I can think of mods that would allow it
>>but I think it is more than reasonable to stick with finite files only.
>You
>>need to understand what is going on with finite files before you add in
>>the infintie.
>> Also you are
>>wrong just becasue a decompressor runs to completion does not
>>mean that you get the same file back when you compress. You have to
>>test for this.
I never said that. Actually I am assuming that it has that property,
at least for finite files. Otherwise, the attacker can run the compressor
after the decompressor and compare it to the original file. If they
don't match, he knows the decryption was wrong.
>>>Ok, here goes. The "ideal" compression function for a given probability
>>>model is given as follows: Let P be the set of finite-length ASCII
>>>plaintexts, ordered by their likelihood of occurrence. You can think
>>>of P as the positive integers, with "1" representing the most likely
>>>plaintext, "2" the second most likely, etc. according to the probability
>>>model. The compression consists of replacing the ASCII plaintext with
>>>the corresponding integer. This is a bijective function, hence
>invertible.
>>>This is also provably the best possible compression algorithm, although
>>>you cannot necessarily implement it in practice given a probability
>>>model.
>> Actaully this is not the ideal compression from my point of view
>for at
>>least two reasons.
I think you misunderstood my use of the word "ideal." The method I
outlined is the theoretically best compression scheme for a given
probability model, and this is a proven fact. Of course, it will only
perform well if the probability model is a good one.
>>1) what if there is no most likely set of messages. Since it may be
>possible
>>for several messages to have the same likely hood.
If two messages have the same likelihood, you rank them alphabetically.
This does not change the argument at all.
>>2)I am strictly working with 8 bit files mulitples not integers.
Then you simply use a fixed mapping between finite-length ASCII files and
integers. This doesn't make a difference either. It was a theoretical point
I was trying to make. For this purpose integers are just easier to deal
with.
Regards
g.
--
I conceal nothing. It is not enough not to lie. One should strive
not to lie in a negative sense by remaining silent. ---Leo Tolstoy
ADDRESS ALTERED TO DEFLECT SPAM. UNSOLICITED E-MAIL ADS BILLED $500
Geoffrey T. Falk <gtf(@)cirp.org> http://www.cirp.org/~gtf/
{}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{}
{}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{}
{}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}
------------------------------
Date: Mon, 25 Oct 1999 18:14:05 +0200
Subject: Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E
From: [EMAIL PROTECTED] ([EMAIL PROTECTED])
Crossposted-To: talk.politics.crypto
>>[EMAIL PROTECTED] wrote:
>> ...
>> But what people have criticized about Original Absolute Privacy is
>that,
>> for various reasons, they feel they do not have adequate reasons to
>> believe that it will genuinely securely encrypt their messages. (I
>> understand that it may be frustrating to you that these reasons appear
>to
>> be chiefly _ad hominem_ reasons rather than technical ones.)
>
>I don't remember them that way. Or do you consider a statement
>of the form "a system that uses a PRNG to generate a pseudo one
>time pad and then claims this is good because of the strength
>of (real) one time pad is snake oil" to be an ad hominem attack?
>I would not. The fact that it comes across that way to snake
>oil vendors doesn't change that.
>
>paul
{}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{}
{}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{}
{}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}
------------------------------
Date: Mon, 25 Oct 1999 19:12:02 +0200
Subject: Re: Newly Encountered Crypto System
From: [EMAIL PROTECTED] ([EMAIL PROTECTED])
"Melinda Harris" <[EMAIL PROTECTED]> wrote, in part:
>>For hackers
it's
>>a cryptographic poison without a
cryptanalytic
>>antidote.
I have this feeling I've seen this phrase - and possibly other parts
of this post - somewhere before. But a web search and a USENET search
have turned up nothing.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
{}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{}
{}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{}
{}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}
------------------------------
Date: Mon, 25 Oct 1999 19:07:26 +0200
Subject: Re: Some humble thoughts on block chaining
From: [EMAIL PROTECTED] ([EMAIL PROTECTED])
"Trevor Jackson, III" <[EMAIL PROTECTED]> wrote, in part:
>>Is this property, statelessness, actually part of the definition of a
>block
>>cipher, or simply the case in most modern ciphers? It appears to me
>that the
>>"blockiness" of a cipher is based on the internal data paths, which are
>><blocksize> wide, rather than the internal state.
Usually, the term "stream cipher" is used even when the ever-changing
cipher acts on objects larger than single bits, since historically
polyalphabetic ciphers acted on whole letters, and might have had
mixed alphabets.
It is a fact, though, that most of today's stream ciphers do just XOR
to a plaintext bitstream, with vulnerability to a bit-flipping attack.
Thus, those stream ciphers essentially only consist of a PRNG. (There
was even a recent thread about the fact that a stream cipher is not
necessarily just a PRNG.) Terry Ritter has some stream ciphers that
don't do this, but otherwise I haven't seen much in the way of recent
designs without that limitation.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
{}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{}
{}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{}
{}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}
------------------------------
From: Clinton Begin <[EMAIL PROTECTED]>
Subject: Re: Compression: A ? for David Scott
Date: Sun, 31 Oct 1999 00:27:48 GMT
> I think you made up this concept with out testing it. Please let me
> know where you get the figures 1 ro 2 % change if decompressing
> a random file becasue this is not even close to what I get.
Here you go. Below is a directory listing of the files I used for my
test, wich includes their sizes.
The file called 'Random.tmp' is 2kb of random data that I produced with
a PRNG. Encrypted data that is decrypted with the wrong key would
probably look something like it no? (i.e. I used random data for this
test because most good encryption algorithms produce 'random looking'
data, decrypting with the wrong key probably makes the data even
more 'random looking' as in EDE type algorithms like 3DES --minus the
second 'E' that is) ;-)
The file called 'RANDOM.UNC' is the result of running ith H3UNC.EXE
with 'Random.tmp' as the parameter. That is, I decompressed the random
data without compressing it to simulate the effect it would have on
improperly decrypted data (i.e. data that was the result of an
attempted decryption with the wrong key). Very little change in the
size of the data. 2.2% to be fairly exact.
Unfortunately I can't seem to post binary to this group (B64 or UUE).
If you want, I can email you the file (Rantom.tmp).
If you like, I can post more examples (more detailed). But I've run
this test a number of times using various types of files (mostly
random). I get the same results every time.
Because this file didn't decompress to a probable size (i.e. by 2 or 3
times), a hacker could easily conclude that a valid huffman structure
didn't exist in the decrypted data and therefore the key can be
eliminated. This method would need to be extended to make it work when
the original data was uncompressible, but this would not be too
difficult.
I maintain my opinion.
Cheers,
Clinton.
===============
Directory of C:\Ah3
10/30/99 05:58p <DIR> .
10/30/99 05:58p <DIR> ..
09/22/99 09:13p 43,520 H3UNC.EXE
10/30/99 05:53p 2,048 Random.tmp
10/30/99 05:58p 2,094 RANDOM.UNC
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Matt Curtin <[EMAIL PROTECTED]>
Subject: Re: Bruce Schneier's Crypto Comments on Slashdot
Date: 30 Oct 1999 19:55:25 -0500
>>>>> On Sat, 30 Oct 1999 12:20:08 GMT, [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) said:
>> Pray tell us, what would be the point of something with a known
>> flaw that could be exploited by third parties and used to make the
>> widespread adoption of the product fail if The Man had the ability
>> to get at the data using escrow keys?
SCOTT19U> First of all in violation of what most consider a safe
SCOTT19U> parctice. The actual method was to be secret. Part of the
SCOTT19U> security was based on hoping no one knew that algorithm.
What is the basis of this assertion? Keep in mind what precisely
you're saying: the security of Skipjack was dependent upon the
algorithm's secrecy.
Matt Blaze demonstrated a flaw in the system whereby someone could
encrypt data with the system in such a way that the escrow keys
wouldn't work. Hiding the algorithm obviously didn't prevent
successful attacks from being launched against it.
SCOTT19U> The method also was never intended for highly classifed
SCOTT19U> government data so one would never suspect that it should
SCOTT19U> have been super secure.
This is silly. There's no such thing as "highly classified". It's
either classified or not. If it's more secretive than "classified",
it's got to be "secret" or "top secret".
Why classified government data wouldn't be used by the system is
obvious: it has escrow keys. The existence of escrow keys is the
known weakness of this system.
SCOTT19U> And thirdly the LEAF ( the law enforcement field ) which was
SCOTT19U> suppose to aid the government through the use of escrow but
SCOTT19U> there were methods already in the open literature to get by
SCOTT19U> this method. The NSA designed it so that it could be easily
SCOTT19U> broken by them when people on through own take the chip
SCOTT19U> apart and learn the method or try the techniques in the
SCOTT19U> literature to get a tound the LEAF stuff. So in reality it
SCOTT19U> had to be a weak method. But as weak as it is I don't think
SCOTT19U> people in the open literature could even today actaully
SCOTT19U> break a message very easily in a timely matter. But it
SCOTT19U> would be a safe beat the NSA could.
Absolute nonsense. You're confusing algorithm design (Skipjack) and
implementation (Clipper). Weaknesss in Clipper's implementation have
*nothing* to do with the Skipjack algorithm, which is what you claimed
was designed to be insecure.
--
Matt Curtin [EMAIL PROTECTED] http://www.interhack.net/people/cmcurtin/
------------------------------
From: [EMAIL PROTECTED] (Tom)
Subject: Re: Compression: A ? for David Scott
Date: Sun, 31 Oct 1999 04:17:38 GMT
Reply-To: [EMAIL PROTECTED]
On 30 Oct 1999 19:21:30 GMT, [EMAIL PROTECTED] (Rebus777) wrote:
>[EMAIL PROTECTED] wrote:
>
>>>>>If the problem is only that a
>>>>>good compression program (i.e. pkzip) adds known information to the
>>>>>header (as exist in many file formats), why wouldn't moving the
>>>>header
>>>>>to the end of the plaintext, and running in a feedback mode
>>>>>effectively eliminate or greatly reduce the problem?
>>>>Running in a feedback mode would reduce the problem
>>>> - however it would
>>>>be better to eliminate the problem (i.e. find a cure not treat the
>>>>symptoms) by removing all added structure from the post-compression
>>>>plaintext.
>
>Yes this is what I believe, but David Scott and some others in this group seem
>to have an idealized and purist idea that if it can't be done with just a
>compression algo, then we should just stop and be satisfied with what we have.
>
>It seems to me if you have the GOAL to create the best compression you can
>(reduction in the plaintext size) for pre encryption, do it and then deal with
>the header and created patterns. My gosh, just tack on TinyIdea (only about
>440 bytes) and you have a great compressor that I don't think anyone would
>consider to leave a weakness.
Hey, I'm getting more out of this than I anticipated! What is
tinyidea and do you have a pointer?
>
>But that's cascading encryption! So WHAT!! It is still only the 2 steps you
>where willing to take in the first place.
>
>-RSC
>
------------------------------
** 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
******************************
