Cryptography-Digest Digest #511, Volume #9 Thu, 6 May 99 23:13:03 EDT
Contents:
Re: Thought question: why do public ciphers use only simple ops like shift and XOR?
(Terry Ritter)
Re: Little Irish girl's algorithm? (Emmanuel BRESSON)
Re: Discrete Logarithm Question ("Vedat Hallac")
Re: The simplest to understand and as secure as it gets. (SCOTT19U.ZIP_GUY)
Re: The simplest to understand and as secure as it gets. ([EMAIL PROTECTED])
Re: The simplest to understand and as secure as it gets. ([EMAIL PROTECTED])
Re: AES (William Hugh Murray)
Re: Pentium3 serial number is based on who you [server/exterior] claimed to be
(Vernon Schryver)
Re: The simplest to understand and as secure as it gets. (David Hamilton)
Re: Fast random number generator (John Savard)
Re: Crypto export limits ruled unconstitutional (David A Molnar)
Re: Random permutation ([EMAIL PROTECTED])
Kiwi source code released internationally (Sam E. Trenholme)
----------------------------------------------------------------------------
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 20:18:59 GMT
On Thu, 06 May 1999 19:03:51 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (John Savard) wrote:
>[EMAIL PROTECTED] (Terry Ritter) wrote, in part:
>
>>We would surely prefer to have both strength and independent messages.
>>But since we cannot know strength, we must look to the consequences of
>>weakness: If we have a plethora of ciphers and use new ones for each
>>message, each cipher break exposes one message. If we just use one
>>cipher, a cipher break potentially exposes all messages over all time.
>
>>Breaking the cipher in a one-cipher system will expose future use of
>>that cipher. But breaking the current cipher in a many-cipher system
>>exposes only the current message and not future messages. Which do we
>>prefer?
>
>Since we can know weakness, those who are objecting to your scheme do
>so on the basis that it makes the use of some weak ciphers more
>likely, or even a virtual certainty.
The two classic methods of protecting something are: "give each secret
egg a separate basket," and "put all your eggs in one basket and WATCH
THAT BASKET!" While this last approach is good advice in some fields,
in cryptography we *have* no way to watch the basket. We do not know
when our eggs have been broken and our secrets taken. So even if we
diligently try to follow this advice, we find we cannot.
That leaves us with the many-baskets approach, the many-cipher system.
Surely we don't expect any real system which necessarily includes
people to keep all secrets for all time. There will be exposures; we
would like to minimize those. By choosing the many-cipher approach,
we specifically accept losing some eggs in preference to losing them
all. In the classic case, each of the smaller baskets is necessarily
a lesser basket. But that is not the case here, if we use the big
basket as a part of a three-level "basket" composed of three different
ciphers.
The counter argument is that we can build a better basket if we only
build one. But in cryptography we still *cannot* WATCH the basket, no
matter how good we think it is. "Use the best basket you can find and
forget about it" is not one of the classic methods. Why?
>[...]
>How can we use more than one cipher, and yet not wind up with a chain,
>as strong as its weakest link, with many links? _That_ is the question
>that needs to be answered, and multiple encipherment is an important
>part of the answer.
Multi-ciphering *is* the answer to that particular question. We can
see multi-ciphering as a chain of ciphers, but then we have a strange
analogy, for that chain is as strong as the *strongest* link. In
fact, just putting a link in that chain makes the link stronger than
it was on its own.
>Despite finding the objections to have some validiity, I also have to
>agree with you that just settling on one cipher that "everybody", or,
>more specifically, those who are respected and competent, thinks is
>strong is not a valid answer either. Even the experts do get
>surprised. Your objection to the conventional way of doing things is
>valid too.
Thank you.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
Date: Thu, 06 May 1999 19:13:42 -0400
From: Emmanuel BRESSON <[EMAIL PROTECTED]>
Subject: Re: Little Irish girl's algorithm?
Well, We can think this was a good (?) joke, since no paper has been released
until now....
Emmanuel
Dan wrote:
> A little while back, the media had a fieldday when a young woman from Ireland
> invented a public key algorithm that was supposed to be up to 10 times faster
> than RSA. Does anyone know what happened to this? Was there a paper
> ever released on the algorithm? Was it dis-proven? Is it currently undergoing
> cryptographic testing?
> Just curious,
> Dan
------------------------------
From: "Vedat Hallac" <[EMAIL PROTECTED]>
Subject: Re: Discrete Logarithm Question
Date: Fri, 7 May 1999 09:15:19 +1000
>I do not think tis case occurs frequently, since phi(N)=(p-1)(q-1)=
n-q-p+1,
>you should have phi(N)>p+q almost everytime...
>Bye,
> Emmanuel
That was the first impression I had. However, Phi(N) is lcm(p-1, q-1), which
is (p-1)*(q-1) only when p-1 and q-1 are coprime. If they have a very large
common factor, then phi might get quite small compared to (p-1)*(q-1). But I
am not really sure whether it can get below p+q or not. It seems having
Phi(N) > p+q is not an unreasonable assumption, though.
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The simplest to understand and as secure as it gets.
Date: Fri, 07 May 1999 00:40:31 GMT
In article <7gt82a$rna$[EMAIL PROTECTED]>,
[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.
>
> Well the compression does provide for nice diffusion, however any artifacts in
> your compression (literals for example) will constitute plaintext. BTW, how
> well is your encryption on say a file that does not compress well? That's why
> compression/encryption are separate deities...
>
> Tom
>
Well Tom I feel my encryption works well on any file. However
my compression methods are more for those that are stuck with weak
runt key methods that the NSA can most likely break such as whatever
gets selected by the AES process. If the file does not compress very
well and if using the method of a forward compression pass and the
reverse compression pass. The file would grow in length. From an
entropy point of view the average entopy per bit would be worse
since files longer. However if one tended to use files that are
very close with only a few changes. I think certain weaknesses would
be diffused and "partial plain text attacks" would be hard to mount
However if the enemy can mount "choosen whole file plain text attacks"
then there is no protection what so ever. And if encyption could be
broken the compression would add little. However if one is just using
low entropy files that compress this would not occur unless the enemy
can trick you into using very speacial whole length binary files for
you to encrypt. I hope this anwsers your question
David A. Scott
--
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]
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The simplest to understand and as secure as it gets.
Date: Thu, 06 May 1999 23:19:41 GMT
> 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.
Well the compression does provide for nice diffusion, however any artifacts in
your compression (literals for example) will constitute plaintext. BTW, how
well is your encryption on say a file that does not compress well? That's why
compression/encryption are separate deities...
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The simplest to understand and as secure as it gets.
Date: Thu, 06 May 1999 23:17:02 GMT
>
> Why should I prove how I think. Besides only a true OTP is
> proven secure. But you may lack the knowledge to know that.
That's not very nice. Ok smart@#! why is your routine secure? Why would it
hinder an attack. Why would I care?
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: William Hugh Murray <[EMAIL PROTECTED]>
Subject: Re: AES
Date: Thu, 06 May 1999 23:47:38 GMT
This is a multi-part message in MIME format.
==============AA628054C29A7C879F30D1A4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
wtshaw wrote:
> 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
Moderately useful? After more than twenty years, the cost of attack as
a function of the cost of encryption is exactly where it was when DES
was announced. I would suggest that that is a very useful cipher. I
would suggest that that is a timeless cipher. Until that ratio begins
to fall, I can continue to make good use of that cipher.
I certainly can not use it in the way that it was used twenty years ago
but there are, just as certainly, useful applications and safe modes.
It will be a long time before we will know a fraction as much about an
AES candidate as we know about DES.
William Hugh Murray
New Canaan, Connecticut
==============AA628054C29A7C879F30D1A4
Content-Type: text/x-vcard; charset=us-ascii;
name="whmurray.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for William Hugh Murray
Content-Disposition: attachment;
filename="whmurray.vcf"
begin:vcard
n:Murray;William Hugh
tel;fax:800-690-7952
tel;home:203-966-4769
tel;work:203-966-4769
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:[EMAIL PROTECTED]
fn:William Hugh Murray
end:vcard
==============AA628054C29A7C879F30D1A4==
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Crossposted-To: alt.security
Subject: Re: Pentium3 serial number is based on who you [server/exterior] claimed to be
Date: 6 May 1999 16:02:20 -0600
In article <[EMAIL PROTECTED]>,
Artur <[EMAIL PROTECTED]> wrote:
>To get the other side of the story you can wisit:
>http://www.privacy.org/bigbrotherinside/
Well, I guess so, if you consider the other side of intentionally
misleading nonsenese to be dishonest foolishness. That is what passes
for balanced reporting in the mass media.
] Ethernet IDs are not widely available and are not intended for
] identification. Ethernet identities are used for routing computers
] connected to networks via Ethernet and are not collected or used
] for identification purposes. Currently, most users connect to the
] Internet via modems and serial ports so Ethernet IDs are not used
] or disclosed. Many computers simply do not include Ethernet cards.
] For those that do, users can also buy inexpensive new Ethernet
] cards without changing the processor or buying a new computer.
] Other identifiers are not widespread. Other identifiers available
] include other hardware items, and software registration codes. But
] none of the hardware items are likely to be available on a majority
] of consumers' computers, and browser manufacturers are unlikely to
] transmit license numbers with every web page request, so these are
] not likely candidates to become the "social security number'' of
] a PC. The PSN was designed to be widely used as an identifier.
So because Intel made the political mistake of calling it a "license
plate," it will be used as one, but alternatives won't be, and their
current widespread uses to violate privacy don't matter?
I guess that cookies now do what both the Intel salescritters and their
opposing political critters claim for the PIII is just an inconvenient
fact for those selling silicon or hysteria.
That Ethernet IDs are rare and useless must come as welcome news to the
guy arrested for the Melisa virus, since that means it's all been a bad
dream for him. That more AMD than Intel CPU's were used in some recent
period is just something to be ignored, as is the fact that the
10,000,000's of non-PIII's now on the net are not going to be magically
disappear next year, no matter how many PIII's are also in use.
Then there is the globally unique Windows 95/98 or Word or Office serial
number in the WIN32 registery, at least on systems where the stuff was
not installed from a "borrowed" CDROM. Do you suppose an ActiveX agent
could look at what you can see if you use regedit.exe to peer at
\HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\ProductId?
(Yes, people install new version of Windows, but they buy new computers
at least as often--how else do they get those PIII's? For more handy
serial numbers, use regedit to search for "OEM" or "productid".)
WIN32 has a cool feature that allows a program to lurk invisibly, recording
all keystrokes and mouse movements before passing them on to the intended
applications. Consider what a 50 line WIN32 C program can do by hashing
30 minutes of mouse and key events into a random number that is more likely
to be unique in the real world than the PIII serial number, and then
stashing it in the WIN32 registery to be sent to any HTTP server that
asks. Or maybe we should assume that PGP does not generate unique keys.
A positive note on the foolishness is that the privacy.org nonsense is
2.5 months old, so perhaps they've moved on to something else. Wasn't
the arrest for the Melissa virus after Feb 22, when the silly privacy.org
page says it was last changed?
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (David Hamilton)
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The simplest to understand and as secure as it gets.
Date: Thu, 06 May 1999 21:17:53 GMT
=====BEGIN PGP SIGNED MESSAGE=====
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
(snip)
> Actually I think scott19u.zip is stronger.
>Get it free executable and source code visit my site.
>
>David A. Scott
Actually, PGP is stronger; see message-ID <[EMAIL PROTECTED]>
in the thread 'Re: Encryption Basics' posted in sci.crypt on 19th December
for details.
David Hamilton. Only I give the right to read what I write and PGP allows me
to make that choice. Use PGP now.
I have revoked 2048 bit RSA key ID 0x40F703B9. Please do not use. Do use:-
2048bit rsa ID=0xFA412179 Fp=08DE A9CB D8D8 B282 FA14 58F6 69CE D32D
4096bit dh ID=0xA07AEA5E Fp=28BA 9E4C CA47 09C3 7B8A CE14 36F3 3560 A07A EA5E
Both keys dated 1998/04/08 with sole UserID=<[EMAIL PROTECTED]>
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: Signed with 2048 bit RSA key
iQEVAwUBNzIESco1RmX6QSF5AQH3Hwf9E48/e/E3VX4GUz2UVBMGp0bDuXUsFbJq
x+VA1KYiZ+MT1s4w40STbDhgbBa7MGl+0R2v80M57w5lnKBoIGl+1umEANGxS763
bXSss+fLAF23+Le09GFIg6lAs3tAfLWXqjY4vLQ2Sh+XolSqnSc1RYv1wfh0nHzA
7xzc8gW552i1uIdXiK2WfoZR6BSZKgG52XHCnB66DQra5Kvw6i34xCJLtHs5I/i4
d9bNC3GQlj8jXgspvvEfACcwj/3tvrRvzlEexRCtLvo5yxg7qn/pgNCb1bmcP5AD
5rUfrN231UtQ5maKr5DWCsk1Sqyf0zpfBAkyhnU2ap4Ka0J/TZO2jA==
=tVoG
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Fast random number generator
Date: Thu, 06 May 1999 21:40:55 GMT
[EMAIL PROTECTED] (Terry Ritter) wrote, in part:
>In particular, an appropriate way to develop a random value of
>arbitrary range is to first mask the random value by the next higher
>power of 2 less one, and then reject any value beyond the desired
>range.
That certainly is an improvement on simply rejecting values.
For my Quadibloc II and III cipher designs, though, I considered and
consciously rejected any strategy of that type, as I did not want even
a small probability that key setup might take an unusually long time.
Instead, I chose my rather elaborate method in order to reduce any
bias in the resulting permutations to a very small level, while still
both confining myself strictly to simple byte operations and
maintaining a strict upper limit to the time of the process.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Crossposted-To: comp.dcom.vpn
Subject: Re: Crypto export limits ruled unconstitutional
Date: 7 May 1999 02:03:43 GMT
In sci.crypt SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
> I don't think it will stand up in the appeal process. Since
> it is obvious that the Clinton bunch cares nothing about the
> Bill of Rights and the Judges are appointed by Presidents for
> political reasons. Even though the case is obvious and one should
Not all the justices of the Supreme Court are Clinton appointees.
Some are from the Bush and Reagan years, too. Then again, this
may not inspire confidence either, considering Bush's former
position with the CIA.
The larger point is that Justices often surprise the presidents
who appoint them. There's a quote to the effect that Earl Warren
was supposed to be a nice, quiet influence on the bench -- when
in fact his Court ended up creating a revolution. or contributing
anyway.
Are the texts of these decisions available anywhere?
-David
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Random permutation
Date: Thu, 06 May 1999 22:10:56 GMT
Mok-Kong Shen wrote:
> 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?
If efficient means we want to use the fewest calls to our
random number generator, use the same idea as we used to generated
a uniform choice in [0..n) given a uniform and independent bit
source. Suppose rand16() returns a random choice from [0..15].
endRange = 1
randInRange = 0
while true
while endRange < 16!
endRange = endRange * 16
randInRange = randInRange * 16 + rand16()
if randInRange < 16!
return randInRange
else
endRange = endRange - 16!
randInRange = randInRange - 16!
This returns a uniform choice from [0, 16!-1], which
we cam map one-to-one to the possible permuations. It's
optimal in the expected number of calls to rand16().
--Bryan
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Sam E. Trenholme)
Subject: Kiwi source code released internationally
Date: 6 May 1999 18:39:08 -0700
In light of today's 9th circuit decision, and in light of the fact I am
under the juradistion of the 9th circuit court (both me and the server the
code is on are in the SF bay area), I have released the source code to my
'kiwi' spam-protection package to the international community.
Look here:
http://www.samiam.org/crypto
It uses a weak (32-bit block) version of the Blowfish algorithm.
- Sam (Ironically enough, my current Usenet feed stops me from using
Kiwi-enabled addresses)
------------------------------
** 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
******************************
