Cryptography-Digest Digest #455, Volume #10 Wed, 27 Oct 99 02:13:04 EDT
Contents:
Re: This compression argument must end now (SCOTT19U.ZIP_GUY)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
([EMAIL PROTECTED])
Re: Unbiased One to One Compression (Tim Tyler)
Re: There could be *some* truth to it (Tim Tyler)
The Perils of Protocol Negotiation (Paul Crowley)
Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E (John Savard)
Re: Browsers Random Number Generator ([EMAIL PROTECTED])
Re: frequency of prime numbers? (Donald Welsh)
Random dot stereograms ([EMAIL PROTECTED])
Re: This compression argument must end now (Tom St Denis)
Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E (Tom St Denis)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: This compression argument must end now
Date: Tue, 26 Oct 1999 23:41:21 GMT
In article <7coR3.7409$[EMAIL PROTECTED]>, gtf[@]cirp.org (Geoffrey T.
Falk) wrote:
>In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> claimed:
>>the one-on-one property directly affects source statistics. If your
>>compressor does not have the property - and is deterministic - it will
>>be systematically adding information to the file.
>
>Not true in general. It depends on the compressor, and the input data.
>
>"Adding information to the file" is just another way of saying that
>the compression algorithm does not accurately estimate the probability
>distribution of the input messages.
>
No Adding information to the file is not just another way of saying
that the compression algorithm does not accurately estimate the
proabitlity distribution of the input messages. Use you pride and
joy the one to one Identity Compression on a pure set of text files.
it will not add information to the file and it sure as heck is not the
slickest compression algorithm based on probability distribution.
Do you see any extra information added to the file.
..
>>Compressing a "random" file with a bad compressor might add checksum
>>bits or fail in other ways to be one-on-one.
>>*Unless* it is one-on-one it will be likely to add information
>>to the compressed file which could help cryptanalysis.
>
>There are counterexamples. I already described one: The identity,
>or trivial compression function, which is the best possible
>compression for random data, and which does not add information
>to the file.
Unless I missed your point the identity function as you called did
nothing to show what happens when you compress using a non
one to one compression method. Since it is one to one it did not
weaken the encryption by adding information. It was only a counter
example in your mind.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 26 Oct 1999 23:04:06 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Terry Ritter) wrote:
> To start any conversation in cipher, it is currently necessary to
> acquire common keys. Everyone understands this. So everyone should
> be well prepared to understand that we can *also* acquire a cipher
> name, or even a cipher itself, in the same way, through the same
> channel. This is not a big conceptual leap.
>
> Once we have a conversation in cipher, we can assign part of it to a
> "control channel," where negotiation takes place (...)
I quite agree, but maybe the word "negotiation" is not the best one in
this context. We can add to the encrypted data the code necessary for
decrypting it. That is, we can create software objects that include
both data and methods for processing it. In a world that is
interconnected and software driven, you don't have to physically add
code, just point to a place where certified code can be downloaded from
(as you say just "name" it). If the code is in Java you have a solution
that is global in scope and flexible. If you worry about speed publish
code optimized for several hardware platforms.
No negotiation between the communicating partners takes place for
defining which security algorithms will be used. Simply, the one who
receives an encrypted message (or a challenge for starting a secure
session) checks to see if the code necessary for processing this is
loaded locally. If not, it downloads it from a central repository,
checks its signature, checks whether the signer is to be trusted, and
executes the code (and adds it to the menu of code held locally for
future use). Encryption technology can now grow unhindered by widely
used standards that in the future may become unstable or be left behind.
For this to work of course, we do need one certification standard we
can trust for the long run. Everything else though becomes liquid. If
you write your own email client and want to send mail encrypted by the
second AES winner cascaded with 3DES and ABC and finally with XYZ, just
publish Java code for your super-duper cipher in the central server,
get it certified and assigned a number (or a name for that matter), and
you are done. Your email client will be able to send encrypted mail to
any other email client in the word which will know what to do to
decrypt your messages � if it chooses to accept your messages.
If you don't trust this liquid world and only trust the AES for your
symmetric cipher, then nothing changes. You just send all your messages
flagged as AES messages or even refuse to read any messages not flagged
AES. In a Darwinian world, people who do choose the best algorithms
will thrive; these may very well turn out to be the ones who choose the
AES and not, say, your ciphers or mine. On the other hand, if we
artificially restrict the free competition of algorithms, then in the
end we shall all end using sub-par algorithms.
My basic point is that if *you* own the information you are sending you
might as well define how *you* want to protect it. In other words if
you own information you should be able to structure it any way you
like. I do believe in standards as a way to facilitate communication -
but not as a way to limit how communication will take place. I don't
think there are good technical reasons for restricting the structure of
the communication - after all if you want to talk to a hardwired high
speed link then you may just respect *its* protocols. OTOH I think
there are many security and economic advantages for not imposing one
micro-standard to everybody.
I see some relation to the way a capitalistic society works: as long as
you don't use an illegal method you can manage your properties any way
you like. In this system of free competition, the ones who invent or
choose the most effective methods thrive and drive the rest of the
economy. I think that in the information society of the future we
should also be careful to motivate rather than restrict the free
competition of methods for managing information: the algorithms.
I do see the need for the AES or maybe for a few widely respected
ciphers. I do think that we need good and standardized security
primitives. What we don't need is a high level inflexible standard that
restricts us to use only one or one out of a few given primitives.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Unbiased One to One Compression
Reply-To: [EMAIL PROTECTED]
Date: Tue, 26 Oct 1999 22:35:09 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>,
: [EMAIL PROTECTED] wrote:
:> You're saying you think that any attempt on my part to explain my
:> understanding of the workings or security benefits of a certain type
:> of compression designed specifically for compression before encryption
:> would be OFF TOPIC in this forum?!??
:>
:> Compression *is* a component of cryptography. Get with it.
: No actually you are wrong. Compression is part of the cryptosystem not
: the cipher or use of the cipher. This is sci.crypt not alt.security.
: You get with it.
No, /actually/ I am right. Cryptography is the science of secret writing.
Things that help with security *are* part of the science of concealing the
meanings of messages from attackers.
This is "sci.cryptography", *not* "sci.pure-block-and-stream-cyphers".
: If you have metrics by which you can say 'this compression' makes 'this
: system' more secure then by all means share it.
Of couse I don't. All my points on this thread relate to methods of
demonstrating /insecurity/, not methods of demonstrating /security/.
Lack of demonstrable insecurity is *not* security - but it helps ;-)
: No more speculation please.
Who's speculating?
I'm trying to get across the security benefits offererd by a particular
property of compression routines.
No speculation need be involved in such a venture, and I have tried to
avoid speculating unnecessarily on matters relating to the main thesis.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Wrong numbers are never engaged.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: There could be *some* truth to it
Reply-To: [EMAIL PROTECTED]
Date: Tue, 26 Oct 1999 22:46:02 GMT
Anton Stiglic <[EMAIL PROTECTED]> wrote:
:> Quantum cryptography transmits the key to the one-time pad down the
:> connection, where it can in principle be intercepted by an eavsdropper.
:> They can recover the key, and *know* that they have recovered t correctly
:> from details transmitted over an insecure (e.g. telephone) line.
:>
:> The chances of this happening is very small - but finite and will /always/
:> be non-zero.
:>
:> If the attacker has the key in her posession, the OTP in question is no
:> longer absolutely secure.
:>
:> *That's* what I'm talking about.
: O.k., will you agree with the fact that one has to seperate the encryption
: phase with the key-exchange phase?
Separate in what sense? The latter logically has to preceede the former,
if that's what you mean.
: In the classic case, key exchange could be done, by example, using a
: Diffie-Hellman (DH) protocol. If One-TP is used with DH, then there
: is a non zero probability of a chance that Oscar could guess the key
: and verify it (he verifies it using the info passed during DH,
: very simply done).
No problems yet.
: This has nothing to do with the fact that if all he knows is the ciphertext
: of the One-TP, he can't verify if the key is good.
Yes, not without knowing the plaintext, anyway ;-)
: The same thing applies in the quantum case.
No it does not.
: The quantum key-exchange is independant of the encryption
: stage.
Yes.
: If the attacker has no info about the quantum key-exchange, he can't
: verify if a guessed key works for the one-time pad.
Your mistake. The attacker /can/ find out information about the key
exchange - *if* he is lucky. If he polarises all his filters the right
way he can getall the bits of the key (and some extra). By bugging the
telephone call between the parties he can verify that his polarisations
were accurate and learn which of the bits sent are to be used for
encrypting the main message. He has the key, and confirmation that his
key is correct.
This is not the first time I've tried to explain this to you. If you
doubt the conclusion, /please/ try to pin down where you think my mistake
lies, so I don't have to go through this tedious explanation again.
: The advantage of quantum key-exchange, do, is that it is unconditionaly
: secure [...]
Nope. It is less secure than a OTP to eavsdroppers.
: (it's not based on any problem like factoring, discret log, or such...)
Indeed not. The insecurity happens because of chance events.
: it does have a probability of error (which can be made exponentialy small).
...which is *never* zero. If this chance event crops up, the arracker can
read the message, know he has it correct *and* remian undetected.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Hard work has never killed anyone - but why chance it.
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: The Perils of Protocol Negotiation
Date: 26 Oct 1999 18:57:02 +0100
I've found this debate interesting in that I can see the intuitive
appeal of the idea that negotiating a cipher should be
straightforward, and I can believe the practical experience that says
it won't be. I think the world would benefit from a proper essay on
the perils of protocol negotiation, with lots of real world examples
showing how it can go awry. Is such an essay already out there, or
could Vernon or someone else with the experience be tempted to write
it?
cheers,
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E
Date: Tue, 26 Oct 1999 23:47:55 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote, in part:
>Face it your site is just a bunch of snake oil. Ok answer this
>question. Why do you use keys for symmetric style ciphers > 128 bits?
Why not? Note that even the AES ciphers all allow for keys of 256 and
192 bits in addition to 128 bits.
I'm no fan of "Original Absolute Privacy", but that doesn't seem to be
the most probing question to ask.
Of course, keys for symmetric style ciphers > 1024 bits need some
explaining.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Browsers Random Number Generator
Date: 26 Oct 1999 17:37:31 -0700
In article <7v4f19$4cq$[EMAIL PROTECTED]>,
Vernon Schryver <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>
>> ...
>>Jeff Weinstein posted source for the core of the Netscape RNG code
>>to cyherpunks a few months after the big Netscape RNG flap.
>>Yea, that was a long time ago, but that's probably the closest
>>that you're going to get to looking at the source without an NDA.
>>You can probably find his post on an archive somewhere.
>
>Why a non-disclosure agreement for Netscape?
Just a guess, based on the way that companies work.
The RNG code wasn't in the first release of Mozilla, which is
what I had sitting around here to look at. I'm assuming that since
the legal situation hasn't changed, it's still not in there.
> What about the 128-bit SSL
>that Tim Hudson that he added to the open source Mozilla of a few versions
>ago?
That's not the "native" code that Netscape uses.
>Don't you think that if the new encryption rules are not more creative
>uses of the truth, the California Mozilla people will add SSL to the main
>Mozilla source?
Yep. When they're out (they're not out yet) and understood by
Mozilla and if they say something about source code (I bet they
won't, it would undermine the feds position in the Bernstein case).
Then maybe we'll see SSL in the Mozilla source. I'm not betting on it. :-)
> When I asked him some time ago about 128-bit encryption
>in Mozilla, Brendan Eich said the problem was the Feds.
Of course.
------------------------------
From: [EMAIL PROTECTED] (Donald Welsh)
Subject: Re: frequency of prime numbers?
Date: Wed, 27 Oct 1999 01:02:56 GMT
On Thu, 21 Oct 1999 17:41:00 -0400, Jerry Leichter
<[EMAIL PROTECTED]> wrote:
>I don't recall ever seeing a name for a system with your "at least one"
>postulate. If its models don't correspond to some geometrical object
>that's otherwise interesting, it's unlikely to get a name. It's easy to
>come up with axiomatic systems, but most don't describe anything
>interesting, and even of the ones that *do* describe something
>interesting, many don't have specific names.
"At least one" corresponds to the usual "exists" quantifier. I asked
because the statement "there exists at least one line such that ...",
is the exact negation of "there is no line such that ..." (i.e. the
axiom for spherical geometry). Also, "there are infinitely many"
implies "there exists at least one".
>(Note that from the time of
>the ancient Greeks to the late 19th century, mathematicians were
>convinced that the parallel postulate was really a theorem - they just
>couldn't figure out how to prove it.)
Indeed, that's why we're discussing it, as an example of an unprovable
statement.
>E ('s truth) is independent of G. Saying "E is true in G" is about as
>meaningful as saying "E is true in Ypsilanti" - they simply have nothing
>to do with each other. This is obvious for the second case; it's much
>harder to see in the first only because the symbols and terminology we
>use in G is the same as that we use in E.
Right. For E, substitute "unprovable statement"; for G, substitute
"formal axiomatic system". Using what definition of "true" is an
unprovable statement "true"?
------------------------------
From: [EMAIL PROTECTED]
Subject: Random dot stereograms
Date: Wed, 27 Oct 1999 01:07:56 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> "Quantum cryptographic systems take advantage of
> Heisenberg's uncertainty principle, according to
> which measuring a quantum system in general
> disturbs it and yields incomplete information
> about its state before the measurement. Eavesdropping
> on a quantum communication channel therefore
> causes an unavoidable disturbance, alerting
> the legitimate users."
>
> But this is plain wrong as an argument for complete security -
What happens when you steal a pixel from a random dot stereogram ?
I don't think the whole 3-d "interference" picture collapses and
you become aware of the theft.
http://pionet.net/~k0brd/stereo/
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: This compression argument must end now
Date: Wed, 27 Oct 1999 03:49:50 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In that case they are also counter-examples to your notion that
popular
> cyphers have no known breaks.
Things like a Vinegere cipher provide the ying to yang. You cannot say
something is strong, without first stating what is weak. [note: I am
talking relatively here. I am not asserting the cipher is unbreakable].
> : Just use a high compression ratio or suitable compression
algorithm...
>
> What, rather than thinking about the possible consequences and
discussing
> the matter in a scientific forum?
What I don't get is if the compression ratio is higher won't the
plaintext to the cipher be less biased/skewed?
> : Yeah but prove you need to keep your info infinitely secure with a
> : symmetric cipher.
>
> I beg your pardon?
Prove to me that breaking the cipher is the only way to get the
information. Prove to me that the info contained within is worth
attacking. These are all valid questions.
> If the cyphers are not completely secure, adding security to your
messages
> really helps.
We are not making a bomb shelter here. Added security tends to be a
last ditch effort.
> ``While investigating the PKZIP stream cipher I found that the
plaintext
> characteristics of a compression file built using that extremely-
popular
> program are anything BUT unpredictable. In fact, I was able to
modify
> the "known plaintext attack" against that stream cipher to achieve
> breaks in some cases without knowing -anything- about the plaintext
> except that it was, say, a compressed TXT file, or an EXE or DLL.
This is obviously a lie. If you don't need to know the contents what
good does knowing the fileextension provide. Obviously they are
looking for some plaintext characteristic. [Guessing the plaintext
falls into the same attack as knowing the plaintext].
> [For those of you familiar with that attack: I could not reduce the
> list of key2 candidates to the small number that a large amount of
known
> plaintext would enable you to do... but I could and did reduce the
list
> enough to obtain some practical breaks. The cipher's reliance upon
> CRC32 as a rotor-table was also a poor choice.]''
This I cannot argue. Do you have an online ref to this?
> : But even adaptive huffman coding is not asymtotically optimal for
the
> : first series of symbols.
>
> I never claimed otherwise. I'm saying one-on-one demonstrably helps
> eliminate a potential security problem if added to an existing
compression
> algorithm in some manner.
>
> I have no strong views about Huffman coding being especially
wonderful as
> a compressor - rather the reverse.
Well at least something worthwhile comes out of this.
> : Take the ASCII model. When I use a random IV and CBC I am not
> : guaranteed to be encrypting ASCII text blocks.
>
> So what? You think this somehow means that cryptanalysis is no longer
> possible???
Most likely not.
> : Sorry to burst your bubble, but PKZIP is not a compression
algorithm.
>
> Call it what you will. If you can find a single, non-trivial
compression
> algorithm included within the popular PKZIP compression package, it
will
> be very suprising.
So what?
> :> Most *recognise* that they don't know how strong their cyphers are.
>
> : You should phrase that to 'they cannot prove their ciphers are
strong,
> : but can conjecture with a body of evidence their strengths'.
>
> Should I? I'm quite happy with it the way I wrote it.
Because my way of saying it tends to lend a positive tone to the work
they try to contribute.
> : Most good research papers have nothing todo with marketting.
>
> Most good research papers do not wind up asserting that a cypher is
> strong.
Not true. Many papers discuss why their design should be viewed as
more difficult to attack or break.
> My ideas (about compression?) may be "broken tomorrow"? That would be
> rather strange. What exactly are you trying to say?
I am saying that even your one-to-one model could become invalidated
(just like strong primes in RSA).
> : That's why I would rather lead away from speculation to analysis
> : and research.
>
> What speculation has there been?
That one-to-one compression is any better then regular joeblow
compression.
> : DES for example is still strong today [minus the short key] because
> : people who thought about what they were doing wrote it.
>
> Well good design certainly seems to have helped historically. Of
course
> that's no good reasopn to believe adding security is without merit.
What security are you adding? If the cipher is unbroken you will have
a hard time reading the message whether compressed or not.
> : If all ciphers will be broken, why invent them?
>
> Why, they have obvious utility!
>
> It matters little that cyphers will be broken some day, if - for
today -
> reading them is very, very expensive in practice.
Can we say hypocrite? You admit that current cipher usages are strong
[or highly resistant] yet state that we shouldn't use them because some
day they may be broken. Then you state it's ok, because right now it's
hard...
> : Why research them?
>
> I'm sure you are asking all these basic questions rhetorically...
Bingo.
> : I would rather be more realistic.
>
> More realistic - than *what*?
Oh never mind.
> : People haven't broken Blowfish for example because we lack good
metrics
> : to attack the sboxes. RC5 because the of the non-isomorphism
between
> : xor-rotate-add operations. etc...
>
> Pinning strength down isn't /terribly/ easy, but yes, sort of.
Um I know for a fact that removing the sboxes from blowfish would make
it a good candidate for attacks. etc...
>
> : It's true that they good be done, but a body of evidence suggests
otherwise.
>
> ..."could be done"? Most certainly.
>
> *What* "body of evidence" suggests that they will resist the efforts
of
> cryptanalysts indefinitely??
Again you are being hypocritical. I am suggesting that their
work 'suggests they are strong for the time being'. I am saying
because lots of people have attacked DES et al. that we can with some
degree of confidence recongnize strong ciphers from the weak.
> : Actually the attack on PKZIP's encryption can be done on 13 known
> : plaintext bytes. Whether compressed or not. [...]
>
> I think the idea was that regularities in the compressed text supplied
> these bytes. The claim was made that the break was achived with no
> knowledge of the plaintext at all (beyond the fact that it was
> compressed text). All plaintext was extracted from regularities in
the
> compression.
Actually the attack needed 13 known bytes. You have to KNOW them. I
suppose if it were a bmp they would be easily guessable...
> : It's computationally hard to get anything usefull out of a CRC32
> : from a 1mbit message. Sorry thems the facts.
>
> Really?
>
> Perhaps you should talk to the guy who said he used regularities in
the
> compressed file - including those in the the CRC32s - to break the
cypher
> without any knowledge of the plaintext - except for the fact that it
was
> text, then.
You are telling me they can tell the contents of a 1mbit file from a
32bit crc? That's a laugh. Why not just send the crcs of audio and
save on time and bandwidth :)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
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: Wed, 27 Oct 1999 03:53:28 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> Tom St Denis <[EMAIL PROTECTED]> wrote, in part:
>
> >Face it your site is just a bunch of snake oil. Ok answer this
> >question. Why do you use keys for symmetric style ciphers > 128
bits?
>
> Why not? Note that even the AES ciphers all allow for keys of 256 and
> 192 bits in addition to 128 bits.
I would question the need for >128 bit keys. I use 160 bit keys in
peekboo because sha outputs 160-bits and it seems like the thing todo.
I don't recognize a major benefit over say 80 bit keys. (unless of
course there is some major hardware going on, but then I would have to
question it seriously...)
> I'm no fan of "Original Absolute Privacy", but that doesn't seem to be
> the most probing question to ask.
>
> Of course, keys for symmetric style ciphers > 1024 bits need some
> explaining.
Um that was my point :). I think one of his ciphers uses 10kbit+
keys. Um why? Even 80 bit keys are hard to attack. Heck even 64 bit
keys (rc5 challenge) are hard to attack. It's sounds big and important
thats why. Why not use blowfish with 32kbit keys? hehehe
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
