Cryptography-Digest Digest #542, Volume #10 Wed, 10 Nov 99 23:13:03 EST
Contents:
Re: Compression: A ? for David Scott (Tom)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
([EMAIL PROTECTED])
Re: Lenstra on key sizes (SCOTT19U.ZIP_GUY)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Patrick Juola)
Re: Research suggestion? (Peter Pearson)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Tom)
Subject: Re: Compression: A ? for David Scott
Date: Wed, 10 Nov 1999 05:49:26 GMT
Reply-To: [EMAIL PROTECTED]
Those were the conclusions I drew as well. The brute force attack
should really drops out too, as the compression is deterministic, but
it seems a moot point.
I'd thought it was an issue with conventional compression having an
output format that could somehow provide for a type of known plaintext
attack, but that doesn't seem to be the case.
Was hoping for more!
On Wed, 10 Nov 1999 17:08:40 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:
>Okay, here is my take on "one-on-one" compression:
>
>It is designed to foil the test for plaintext in a brute-force
>key search attack; if properly designed, many incorrect
>decryptions+decompressions should produce pseudo-plaintext.
>However, one should already not be using a cryptosystem that is
>appreciably susceptible to such an attack. That explains why
>there hasn't been a lot of professional interest in the idea.
>But it's an interesting research topic.
>
>Any practical encryption algorithm that might be cryptanalyzed
>by some means better than brute-force key search would be more
>resistant to cryptanalysis if the plaintext were compressed
>before encryption, so long as the compression does not
>*concentrate* its added information (e.g. in a header).
>You might as well use "one-on-one" compression, but it has
>no special advantage over some other schemes in this context.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Thu, 11 Nov 1999 01:27:24 GMT
Terry Ritter wrote:
[EMAIL PROTECTED] wrote:
[...]
> >One more time: secret is not the issue. Authenticated
> >is the issue.
>
> Well, in cryptography, there are various kinds of authentication:
Glad you're seeing that.
[...]
> >One side can certainly make a random
> >choice, but your method calls for them to agree, and
> >thus the choice must be influenced by messages between
> >them. You have simply assumed the choice would be
> >random, without ever presenting how they ensure it
> >will be random when an attacker may modify the messages
> >that influence the choice.
>
> First of all, the "random" selection I propose is exactly the same
> sort of thing which produces message keys (or "session keys," if they
> are used for multiple messages), which are used in almost every
> serious cipher system. Normally, the public-key component transfers
> the message key, which is then used in a secret-key system. This is
> very well known technology, and the issues are also well known, so
> there should be little need to repeat these well known details.
Many or most serious systems use session keys where
each key is chosen by one side, thus requiring no
negotiation. In systems that negotiate choice of
cipher the "well known details" are well known for
their difficulty; failure to authenticate the cipher
negotiation was a mistake in SSL.
Over and over you've stated that the negotiation is
secret, protected by a cipher. When did you note
the need for authentication or name a MAC or
signature? Now you say it's just like other cipher
systems, such as public key ciphers. Ciphers provide
poor authentication, and public key ciphers don't
really provide any authentication at all. It is
not the case that your claim of secrecy, protected
by a cipher implies authentication. In fact it
implies that you missed the attack.
> Next, it is true that messages must be sent between the ends to
> coordinate cipher changes. But these messages are -- once again --
> sent *under cipher*. By "under cipher," I mean that I require that a
> cipher already have been established and be in effect. Whatever
> cipher system has been established will authenticate received messages
> in some way (often with a hash of the plaintext), and thus will detect
> "any" attempt by an attacker to "modify the messages."
Now you're starting to get it. This authentication
was completely missing from your suggestion before
others pointed out the problem. Yes, it can be fixed,
but the actual protocol design is not the simple
exercise you had thought.
> >Whether an authentication code be compromised is
> >beyond the scope of the protocol. The point is the
> >need for authentication and its absence from your
> >proposal.
>
> If you are describing a need for message authentication, I wholly
> agree.
So thank people for pointing out that you needed it in
your negotiation phase, and stop pretending that you had
it there already.
> This should be a part of any cipher, and is in fact a part of
> all of my commercial ciphers. This is very well known technology.
The cipher agility of your actual systems is far behind
the state of the art. You claim to be long-time advocate
of standard protocols with interchangeable cipher, and that
the design of such protocols is easy. Your commercial
ciphers contradict such claims.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Lenstra on key sizes
Date: Thu, 11 Nov 1999 02:30:32 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Bill
McGonigle) wrote:
>In article
><[EMAIL PROTECTED]>,
>Justin <[EMAIL PROTECTED]> wrote:
>
>> What's the point of the AES process? Say one gets picked. Five years
>> from now a discovery is made that makes attacks on any key size practical
>> for any moderately funded organization. Now you have a large number of
>> companies and governments with lots of encrypted data, all of which can be
>> simply decrypted because everyone is using the vulnerable algorithm.
>>
>> Why not have a pool of algorithms and revise it every year?
>
>That sort of defeats the purpose of a standard. i.e. if it's changing
>every year. There are lots of crypto algorithms to choose from, but AES
>is an easy choice for people that don't know how to make their own choices
>(and not everyone needs to be a cryptographer).
>
>Also, the AES process has been more than a year already. You don't want
>to rush these things.
>
>Still, it might make sense to have a "backup-AES" contest running every
>few years, comparing the current standard, and evolving a new one. So
>when/if AES gets broken there the world isn't screwed for two years or
>so.
>
>Also, eventually AES may be obsolete, so why wait until it is to have
>another contest? If I were running a continual contest, I'd probably have
>two categories: one based on the current technology (e.g. difficulty of
>factoring) and another based on a different technology (e.g. elliptical
>curves) in case the theory is succesfully attacked instead of the
>algorithm.
>
>Like someone else said, the odds are very low, but if there are any it's
>worth thinking about. Cryptographers get paid to be paranoid.
>
No cryptographers that work in the public domain get pain to hold
the hands of coprate CEO's so that they falsely belive there stuff is secure.
Main stream crypto people do not want you to have secure encryption
or they would be out of a job. The NSA would not allow them to get all
the PR that they get. The NSA needs to have the public bindly follow
a chosen few so that it can keep readin your mail.
Take my product scott19u.zip Wagner and Mr BS have repeatedly called
it weak and Snake Oil. But I have constructed contests that can't be done
with there weak crypto.
Yet mine is called SNAKE OIL. I thiink the main reason is that I don't
kiss ass very well with the crypto gods. Yes I am finally listed on
Gutmans page under snake oil. But few there supply the source code.
It makes me wonder just how phony the crypto gods stuff is when mine
is called snake oil. Yet I supply the source code. And have contests they
can't do becasue of inherint weaknesses in there short keyed methods.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: 10 Nov 1999 16:38:40 -0500
In article <[EMAIL PROTECTED]>,
james d. hunter <[EMAIL PROTECTED]> wrote:
>Dave Seaman wrote:
>>
>> In article <[EMAIL PROTECTED]>,
>> james d. hunter <[EMAIL PROTECTED]> wrote:
>>
>> > What is the difference between a random number and a number
>> > that is random in the _statistical_ sense? I assume that
>> > you are thinking of a random theory of numbers, such
>> > as set theory or category theory.
>>
>> A number is random in the _statistical_ sense if it passes all the
>> statistical tests for randomness. For example, each possible n-digit
>> block of digits should occur once in every 10^n digits, in the long run.
>> In other words, it's a normal number, base 10.
>
> But, the statistical tests for randomness are subject to the
> whims of the statistitians.
For a sufficiently personal definition of "whim," I suppose so.
-kitten
------------------------------
From: Peter Pearson <[EMAIL PROTECTED]>
Subject: Re: Research suggestion?
Date: Wed, 10 Nov 1999 18:11:59 -0800
Rick Decker wrote:
>
> I have a student (senior double major in math, cs) who's interested in
> doing a thesis in crypto. Problem is that I'm trained as a topological
> graph theorist cum computer scientist and don't know much more about
> the subject than what I need to teach it in my algorithms course.
>
> Anyone have a suggestion for a research project that would be suitable
> for a semester-length project? My student is pretty quick, but the
> project need not lead to original results-- a new interpretation or
> tweak of an existing result would be satisfactory. The thesis is
> nominally in cs, but need not include a programming component.
I have had occasion to try to build a cryptosystem
around a graph-theory problem, and lamented the apparent
lack of practical guidance on how to construct a
graph-theory problem of a known level of difficulty.
Give or take a few bits, cryptographers generally agree
that an x-bit integer factorization problem is as hard as
a y-bit discrete log problem or a z-bit elliptic-curve
discrete-log problem or a w-bit block-cipher key search;
but if I want a vertex cover problem of that same level
of difficulty, or a graph isomorphism problem of that
same level of difficulty, what do I have to do?
- Peter
------------------------------
** 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
******************************
