Cryptography-Digest Digest #509, Volume #9 Thu, 6 May 99 18:13:03 EDT
Contents:
Re: Thought question: why do public ciphers use only simple ops like shift and XOR?
(Terry Ritter)
Re: Random permutation (Robert Scott)
Re: The simplest to understand and as secure as it gets. (wtshaw)
Re: The simplest to understand and as secure as it gets. ("Dr Braddock")
Re: AES (wtshaw)
Re: Obvious flaws in cipher design (John Savard)
Re: Obvious flaws in cipher design (wtshaw)
Re: Thought question: why do public ciphers use only simple ops like shift and XOR?
(Terry Ritter)
Re: Roulettes (John Savard)
Re: Shamir's TWINKLE Factoring Machine (Medical Electronics Lab)
Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO (Mok-Kong Shen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Thought question: why do public ciphers use only simple ops like shift
and XOR?
Date: Wed, 05 May 1999 04:42:17 GMT
On 4 May 1999 20:31:05 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (D. J. Bernstein) wrote:
>[...]
>``The risk of catastrophic permanent failure is vastly more significant
>than an occasional transient exposure,'' you say. That seems to be true
>for some applications. But then you claim that your system can't have
>``catastrophes.'' I don't believe you.
Next time show the quote. As far as I can recall I made no claim that
the many-cipher system "could not have catastrophes." I would say
that *any* broken cipher is a catastrophe for the user, although they
would rarely know about it.
But the many-cipher system does automatically limit the extent of such
a catastrophe to a single message or so, whereas the single-cipher
system remains broken for message after message until the system
itself is replaced. I guess we could call this a catastrophic
difference.
In the original context, the many-cipher system simply does not
support a catastrophe of the same extent as the single-cipher system.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Robert Scott)
Subject: Re: Random permutation
Reply-To: [EMAIL PROTECTED]
Date: Thu, 06 May 1999 18:53:09 GMT
>
>> A problem raised in another thread is whether it is possible e.g.
>> to generate a random permutation of [0, 15], given only a random
>> generator for [0, 15] and no generator for [0, 14], etc. One way I
>> can think of is quite trivial: One obtains successive outputs from
>> the generator and discards duplicates until one gets 16 numbers.
>>
>> Question: Are there more efficient ways of achieving the same goal?
Starting with A[i] = i for i=0...15,
for(i=0; i<n; i++)
Interchange the value of A[i] and A[r(i)]
where r(i) is a random number from 0...15. Make n at least 16.
Bob Scott
Ann Arbor, Michigan (email: rscott (at) wwnet (dot) net )
(My automatic return address is intentionally invalid.)
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The simplest to understand and as secure as it gets.
Date: Thu, 06 May 1999 13:12:12 -0600
In article <7gsc1g$10g$[EMAIL PROTECTED]>, SCOTT19U.ZIP_GUY
<[EMAIL PROTECTED]> wrote:
>
> Even though Terry Ritter may not aprove of this or puriest.
> I think I can show by example how much better mine is than the
> encryption used in your software. But I don't think you have the
> courage to take me up on a contest structured like the current gloat
> contest I am running. I encrypt a file with out using the extra
> bells and whistles so that the length does not change and only
> the core encryption is used. Take a look and see if your stuff
> could ever be tested in such a competation. Since the AES stuff
> that will be forced on us can't do a meaningful contest like this
> I doubt it your is good enough.
>
I would venture to guess that Terry, myself, and a few others would like
to see more structure in evaluating and testing a number of maverick
ciphers, those that for one reason or another do not please the normal
herd of lemmings. While the answer some would give is present these
things at Crypto `N something, variety still is the spice of life.
There are lots of options for semi-formality that might attract some
attention for taking up interesting ciphers beyond the domain of the
entrenched, not that I would necessarilly discount the tradition ways of
finding a little truth in spite of themselves.
--
What's HOT: Honesty, Openness, Truth
What's Not: FUD--fear, uncertainty, doubt
------------------------------
From: "Dr Braddock" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The simplest to understand and as secure as it gets.
Date: Thu, 6 May 1999 19:43:56 +0100
How do I get a hold of scott19u.zip outside the usa? Is there a site in the
Netherlands for example?
Regards
Dr Braddock
SCOTT19U.ZIP_GUY wrote in message <7gsbnh$j9$[EMAIL PROTECTED]>...
|In article <7gs6mp$rlk$[EMAIL PROTECTED]>,
| [EMAIL PROTECTED] wrote:
|>
|> > > Original Absolute Privacy - Level3 Version 4.0 Windows GUI -
SHAREWARE
|> > >
|> > > http://www.ciphile.com
|> > >
|> > >
|> >
|> > Actually I think scott19u.zip is stronger.
|> > Get it free executable and source code visit my site.
|>
|> Really? Prove it.
|>
|
| Why should I prove how I think. Besides only a true OTP is
|proven secure. But you may lack the knowledge to know that.
|
|David A. Scott
|
|P.S. Mine as a bigger key than yours!!
|--
|http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
|http://members.xoom.com/ecil/index.htm
|NOTE EMAIL address is for SPAMERS
|to email me use address on WEB PAGE
|
|-----------== Posted via Deja News, The Discussion Network ==----------
|http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: AES
Date: Thu, 06 May 1999 13:23:18 -0600
In article <7gpp0s$7g9$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Patrick Juola) wrote:
>
> On the other hand, most people -- or at least most intelligent readers
> of sci.crypt -- can probably distinguish between semantic quibbles and
> genuine issues of fact. For example, one would need to be a raving
> lunatic to disagree with the statement that DES (and by extension
> 3DES) have survived several decades of civilian, unclassified,
> cryptanalysis with most of its strength intact. By comparison,
> Merkle-Hellman knapsacks lasted less than five years. In a
> practical sense, then, we know that DES is much stronger than
> the basic knapsack, even if this difference isn't formalizable
> in ZFC set theory or its extensions.
>
The important thing is distinguishing these is to openly recognize whether
you are trying weigh ideas or merely slap down the ones you don't like; to
make a point, I sometimes may do some of the later, but it is not without
good reason from my point of view.
DES has proven to be in these days, still a moderately useful cipher, some
semifirm ground; now the problem is to extract from it what is more solid
and what is more liquid: I maintain that the lessons of DES are not fully
learned, and we may still harvest something good out of it if we can trim
away at the rotten parts, which I am expressly trying to do to the
complaints of the multitudes.
--
What's HOT: Honesty, Openness, Truth
What's Not: FUD--fear, uncertainty, doubt
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Obvious flaws in cipher design
Date: Thu, 06 May 1999 18:25:18 GMT
[EMAIL PROTECTED] (Lincoln Yeoh) wrote, in part:
>On Sat, 1 May 1999 12:32:36 +0200, [EMAIL PROTECTED] (Jaime
>Suarez) wrote:
>>Could you explain this more? If users passwords are a few characters long and
>>I hash them to 128 or 160 bits, why am I reducing the size of the effective
>>key?
>Given a good cryptographic hash there is a high probability that you
>aren't.
>Anyway what you should do is salt the passwords and hash em (possibly
>recursively based on salt). That makes precalculated bruteforcing harder.
If you're using a password to generate a key, the legitimate recipient
of your message needs to be able to read the message, knowing only the
password.
Of course, just as salt is stored along with the scrambled password in
a password file, it can be transmitted in the clear along with a
message. And doing _something_ like that is essential, so that
multiple messages sent with the same password (or, rather, pass
phrase) aren't all sent with the same key.
On further reflection, perhaps salting a pass phrase _is_ the best way
of doing this, compared to the classical methods (in addition to the
IV, use a random key sent in the clear to encrypt the key after
hashing) that came naturally to my mind. Because, as you correctly
point out, putting the salt in from the beginning is effective in
hampering phrase searches...
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Obvious flaws in cipher design
Date: Thu, 06 May 1999 13:48:00 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> On Sat, 1 May 1999 12:32:36 +0200, [EMAIL PROTECTED] (Jaime
> Suarez) wrote:
>
> >On Wed, 28 Apr 1999 00:12:41
> >GMT, SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
> >>
....
> >>
> >> Actually Hashing is a bad idea since it usually reduces
> >>the size of the effective key.
> >>
> >
> >Could you explain this more? If users passwords are a few characters long and
> >I hash them to 128 or 160 bits, why am I reducing the size of the effective
> >key?
>
> Given a good cryptographic hash there is a high probability that you
> aren't.
I would not call anything good if it promises to deliver more information
than you put into it.
>
> Anyway what you should do is salt the passwords and hash em (possibly
> recursively based on salt). That makes precalculated bruteforcing harder.
The salt becomes part of the password, means putting that much information
into it.
>
> Based on my flawed intuition, hashing would make the bit distribution more
> unpredictable, and if there are any flaws in the encryption algorithm, that
> might make it harder to exploit.
Over-simplistic statements about making something more obscure are apt to
lead only to simple obscurity, probably easily countered. Flaws in an
encryption algorithm are usually known as bugs unless meant to be there;
some flaws are fatal, even to normal processing.
--
What's HOT: Honesty, Openness, Truth
What's Not: FUD--fear, uncertainty, doubt
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Thought question: why do public ciphers use only simple ops like shift
and XOR?
Date: Thu, 06 May 1999 19:19:53 GMT
On 5 May 1999 17:50:22 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (D. J. Bernstein) wrote:
>Terry Ritter <[EMAIL PROTECTED]> wrote:
>> In the original context, the many-cipher system simply does not
>> support a catastrophe of the same extent as the single-cipher system.
>
>I don't believe you.
>
>Once again: What do you do when the attacker notices that most of the
>amateur designs incorporated into your system are vulnerable to simple,
>easily automated differential attacks?
I am having trouble understanding the connection between the quote,
the assertion ("I don't believe you"), and the question.
With respect to the assertion, a direct refutation is that when the
one-cipher system fails, it does so absolutely and forever until it is
replaced, and that replacement may not be soon because the failure
will be concealed. When the many-cipher system fails, it does so for
the duration of one (1) message, and then conditionally *may* fail for
another message *if* the next cipher is also weak. Even if the
probability of this is high (which I do not accept), it is still less
than one, which is the probability that the broken one-cipher system
is weak. So in this case the many-cipher system is an improvement,
however slight. If you continue to disbelieve, you will have to be
somewhat more forthcoming about what you think the issue is.
With respect to the question, I note the odd "have you stopped beating
your wife" form in which it is posed. The question assumes what I do
not accept: 1) that amateur designs *are* incorporated into "my"
system, 2) that "most" designs in the system would be vulnerable to
*any* one attack strategy. Because the question assumes what I deny,
it is a meaningless question for me and the correct response is that
there is no response.
With respect to my interpretation of the concept behind the question,
the answer is that the "fix package" I proposed has always included
the possibility of "cascade" or "multi-ciphering." Each cipher in a
stack of ciphers is inherently less vulnerable than when used alone,
since no one of those ciphers can be independently attacked by defined
plaintext or known plaintext. Avoiding such serious attacks would
seem to be a significant advantage.
Let's compare the two situations: On the one hand there is the
one-cipher system, using a cipher we might call "prime." On the other
hand there is a many-cipher system, using a changing stack of
different ciphers. Now suppose we force one of the ciphers in that
stack to be "prime," the very same cipher we use in the one-cipher
system:
All of the resulting dynamically created cipher stacks which contain
prime are at least as strong as prime. And if prime falls in the
one-cipher system, it may be protected by the cipher stack of the
many-cipher system and not fall; in this case the many-cipher system
is clearly the stronger of the two.
But if prime falls, *and* the whole stack falls, both systems are
insecure -- for one (1) message. The one-cipher system, of course,
remains insecure until the system is replaced. The many-cipher system
introduces two different ciphers in the cipher stack for the next
message which *may* (or probably will) recover security. While
somewhat less than a provable claim of strength (which does not exist
for a cipher system anyway), it is clearly far more than we have in
the one-cipher system.
In the one-cipher system, if prime falls, the system remains a
security disaster (the user does not know prime has been broken of
course) until the system is replaced. In the many cipher system, if
at least one of the other ciphers in the stack is strong, the
many-cipher system is secure, making it the superior design.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Roulettes
Date: Thu, 06 May 1999 16:26:56 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote, in part:
>The German lottery provides at the kiosks little roulettes with balls
>in them to ease the customers' task of choosing the numbers on the
>lottery tickets. Wouldn't similar devices be good for choosing keys
>for encryption?
I know that in Canada, for lotteries, a simple device of this
description is common for picking random number combinations:
For Lotto 6/49, in which the object is to choose six numbers which
will be drawn from among the numbers 1 to 49, one has a chamber with
grooves below it, covered with a flat clear plastic plate. Within the
chanber are six white balls and 43 black balls. The grooves are
designed to hold all 49 balls with no space left over, in an orderly
array. The plastic plate is printed with the numbers from 1 to 49, in
black ink, over the grooves, at the positions where the balls would
remain at rest in the grooves.
One picks up the device, orients it so that the grooves are above the
chamber, and shakes it. Then, one moves the device into a groove-down
position, and shakes it less strongly until all the balls are in the
grooves. The six numbers that are visible because a white ball is
behind them are the proposed random selection.
Since this type of device chooses several numbers together, no two
identical, and with no ordering among them, the kind of random object
it produces is somewhat inconvenient to use as a key for encryption
without complicated post-processing. There is no easy way to turn a
six-number combination into a single number from 0 to 13.2 million.
Of course, one can simply apply hashing, using the device as a source
of entropy; but as the numbers are manually generated, one would like
to have a high degree of efficiency.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Shamir's TWINKLE Factoring Machine
Date: Thu, 06 May 1999 12:24:30 -0500
DJohn37050 wrote:
>
> The NSA representatives at ANSI X9F1 and at IEEE P1363 (these have been a few
> different people) have consistently said that they like elliptic curve crypto.
> Also, remember that the DSA was designed by NSA.
Is that because it's deep fun math or because it's good crypto?
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO
Date: Thu, 06 May 1999 19:54:51 +0200
SCOTT19U.ZIP_GUY wrote:
> Again for your PEE BRAIN no I PLAN to incorporate compression
> in my encryption programs. The cyptro stuff is not on my site
> (YOU SHOULD KNOW THIS BY NOW) But your to stupid to think. The
> crypto is obtained by either going to pointers at the protected
> north american crypto site. Or I have pointers to the Norway search
> engines so others can find it in the FREE part of the world. Scott19u
> is not available out side of the US cliton curtain yet.
I have more than once said I can't access crypto code from US. If
you have put your crypto code elsewhere and on your own site
there is only non-crypto stuff, then you can tell me that much
earlier with a single line, and not wait so long after we have
spent much time needlessly on that point!!
> Yes it is clear cut. But why the hell should I explain a method to
> you about doing it on 32 bit boundaries. When your to stupid to see
> how it works for 8bit boudaries. Again I say look at eamples and look
> at the code. It is all there for the 8 bit case. If you can't follow
> a simple 8 bit case no way in HELL could you follow a 32bit case.
I have downloaded your ah2.zip. I haven't yet examined the code which
consists of your modification of a program by H. Burch. But I have
run h2com.exe and got two messages for two files. These are
as follows:
nice ending no flag BYTE and ended on byte boundary
case 1 added 0's to file byte or if LASTONE add pad byte
I am very surprised by this. What does 'flag BYTE' mean? It can,
as far as I can think of, only be a special byte signaling the end of
information and so is equivalent to the function of my EOF. In other
words, you do add something to the proper compression stuff. But you
repeatedly claimed that EOF would assist the analyst in his work
(which I think is not true) and yet you yourself add something!! Why
wouldn't your 'flag BYTE' assist the analyst in the same way as my
EOF?? Both are automatically introduced by the system and both are
automatically removed on decompression. What is the functional
difference between my EOF and your 'flag BYTE'???
M. K. Shen
------------------------------
** 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
******************************
