Cryptography-Digest Digest #247, Volume #9 Thu, 18 Mar 99 04:13:03 EST
Contents:
RC6 - Hardware Impementation (Piotr Mroczkowski)
Re: Site Change (Paul Rubin)
Re: One-Time-Pad program for Win85/98 or DOS (Jim Dunnett)
Re: factorisation problem (Don Leclair)
Re: My Algorithm ([EMAIL PROTECTED])
Re: One-Time-Pad program for Win85/98 or DOS (R. Knauer)
Re: Site Change (John Savard)
Re: DIE HARD and Crypto Grade RNGs. (Christopher)
Partial key exposure ("Anthony Lineham")
Re: PGP Protocol question ([EMAIL PROTECTED])
Re: PGP Protocol question (Jeffrey Haas)
Site Change (John Savard)
Re: Partial key exposure (David A Molnar)
Re: RC4 file encryptor (please take a look) (Bryan Olson)
Re: PGP Protocol question (EO)
Re: DIE HARD and Crypto Grade RNGs. (Mok-Kong Shen)
----------------------------------------------------------------------------
From: Piotr Mroczkowski <[EMAIL PROTECTED]>
Subject: RC6 - Hardware Impementation
Date: Wed, 17 Mar 1999 19:20:35 +0100
I'm interesting in hardware implementation of RC6 using MAX chip.
If everybody can help me, please send me e-mail:
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Site Change
Date: Wed, 17 Mar 1999 20:36:59 GMT
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
>Perhaps because some of their clients had failed to place a Xoom banner on
>their home pages, as required, there has been a recent change to how their
>service operates. Sites on Xoom will now appear in a frame, with a small
>frame at the top of the screen containing a Xoom banner.
>
>Although there was no advance notice about this (which may well be
>understandable), in general I have no objection to this policy change.
>Unfortunate as it may be, they are providing a free service which costs
>them money to provide - and there is really no comparison between this and,
>say, the GeoCities watermark.
I agree, it's much less annoying than the geocities pop-up and watermark.
Now can you get rid of the blinking Xoom banner that's in the middle of
your page? Thanks.
Btw, you can see your page without the Xoom frame by hitting:
http://members.xoom.com/_XOOM/quadibloc/index.html
instead of
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (Jim Dunnett)
Crossposted-To: alt.security,alt.privacy
Subject: Re: One-Time-Pad program for Win85/98 or DOS
Date: Wed, 17 Mar 1999 21:18:13 GMT
Reply-To: Jim Dunnett
On Wed, 17 Mar 1999 09:13:02 +0200, "Johan Hartzenberg"
<[EMAIL PROTECTED]> wrote:
>Hi
>
>I'm probably going to put my foot in it, but that's the way I learn.
>
>
>>+++++
>>A true random number is one that is produced by a process that is
>>capable of generating all finite sequences equiprobably. That process
>>is called a True Random Number Generator (TRNG) and can never be the
>>reulst of algorithmic calculation. Equiprobable means independent and
>>equidistributed.
>>+++++
>
>
>>which is not good enough for proveably secure cryptosystems such as
>>the OTP if you intend to have high message volume.
>
>
>What you need for a totally secure OTP is a 100% unpredictable block of
>data.
Is that possible? Given a large block of data you're bound to be
able to predict the next number quite a few times.
--
Regards, Jim. | Der Staat wird nicht 'abgeschaft',
olympus%jimdee.prestel.co.uk | er stirbt ab.
dynastic%cwcom.net |
nordland%aol.com | - Friedrich Engels, 1820-1895.
marula%zdnetmail.com |
Pgp key: pgpkeys.mit.edu:11371
------------------------------
From: Don Leclair <[EMAIL PROTECTED]>
Subject: Re: factorisation problem
Date: Wed, 17 Mar 1999 22:47:09 GMT
Hi,
> David Bressoud
> Factorization and Primality Testing, Springer Verlag
>
> Hans Riesel
> Prime Numbers and Computer Methods for Factorization Birkhauser
>
> These books do not discuss the Number Field Sieve, however. For that, you can
> ask me.
The second edition of Riesel's book does cover the basics of the Number Field
Sieve. It has a worked out example for the SNFS factorization of a small
number, although it is difficult to fully understand the example without some
knowledge of number fields and it doesn't explain exactly why NFS is superior
to other sieving methods.
The complete table of contents for Riesel's book is available at
http://www.birkhauser.com/book/riesel/toc.htm
Don Leclair
[EMAIL PROTECTED]
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: My Algorithm
Date: Sat, 06 Mar 1999 01:36:08 GMT
First off, it's not that I am a idiot. I know the basics of crytology. I
just don't have the money to buy books. I wrote the algorithm because I
believe it solves many simple encryption problems. If you don't want to look
at the code, don't. But I believe given it's simplicity it may take an hour
or two at the most. I just want general ideas and impressesions.
Second, if I were to patent it I wouldn't ask for your help. But I don't plan
to patent things. I don't believe in patents (except for allowing free use).
'standard rates' for spending 20 minutes? I just wanted people to glance at
it.
You have a valid point in saying amateurs can't make drugs, but can't amateurs
make radios? computer games? music?. I am not trying to replace DES or
anything from AES, I would just like some people to look at my encryption
algorithm. Maybe it's been written before and it's been cracked....
Thanks,
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Crossposted-To: alt.security,alt.privacy
Subject: Re: One-Time-Pad program for Win85/98 or DOS
Date: Wed, 17 Mar 1999 23:04:53 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 17 Mar 1999 21:18:13 GMT, [EMAIL PROTECTED] (Jim
Dunnett) wrote:
>>What you need for a totally secure OTP is a 100% unpredictable block of
>>data.
>Is that possible? Given a large block of data you're bound to be
>able to predict the next number quite a few times.
Please tell us how you are able to do that.
Bob Knauer
"My choice early in life was either to be a piano-player in a whorehouse
or a politician. And to tell the truth there's hardly any difference."
-- Harry Truman
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Site Change
Date: Wed, 17 Mar 1999 23:21:06 GMT
[EMAIL PROTECTED] (Paul Rubin) wrote, in part:
>Now can you get rid of the blinking Xoom banner that's in the middle of
>your page? Thanks.
I've replaced it by one that doesn't blink. That way, I'll still be in
compliance even if they have technical problems with this current
innovation.
John Savard (teneerf is spelled backwards)
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (Christopher)
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: Wed, 17 Mar 1999 18:35:49 -0500
|:| Secondly, we *can* measure Kolmogorov complexity to arbitrary degrees
|:| of precision for some types of strings.
|:|
|:| -kitten
I haven't studied Kolmogorov complexity in detail, but from what's been
said here it sounds like a measure of an ideal algorithm (for a specific
task.) 'Ideal' because it doesn't rely on the implementation, and is in
the most compact form possible for the task. If that's way off base then
I apologize, but that seems very similar to how different algorithms are
compared for efficiency, where the weight of each instruction changes from
one piece of hardware to another. So there is a mapping. I have a
feeling there's more to the Kolmogorov complexity, because I fail to see
how it would apply to strings in general.
Second, does anyone know where I can find DIEHARD, I found a link the
other day but it was broken. Thanks in advance.
------------------------------
From: "Anthony Lineham" <[EMAIL PROTECTED]>
Subject: Partial key exposure
Date: Thu, 18 Mar 1999 13:29:53 +1300
I'm curious as to what peoples thoughts are on the following situations.
Suppose a key is broken into blocks of 16 bits. Which of the following to
cases would you consider to be the least serious in terms of breach of
security.
1. 6 of the 16 bits (eg bits 0-5) becomes known while the remaining bits
(6-15) remain unknown.
2. The bits are divided into 3 blocks, 2 of 6-bits and 1 of 4-bits, with
2 zeros appended to make 6-bits. Where the zeros are appended to the third
block is not important but is known. The 3 6-bit blocks are XORed together
to give a 6-bit block. The 6-bit result of the XOR becomes known.
>From rough calculations there are 2 to the power of 10 possible 16-bit
blocks that can produce the 6-bit XOR result. (I think this is correct?)
Both situations result in 10-bits of uncertainty, but would you consider one
situation more serious than the other, or both the same. I realise that
this is really an algorithm dependent situation so think of it terms of a
DES-like algorithm.
My intuitive preference is situation (2) as it doesn't explicitly reveal any
of the bits, only the possibilities, while (1) gives away 6 bits with
absolute certainty. Knowledge of these 6 bits might then be used as
somekind of stepping stone to a further attack.
Let me know what you think.
Anthony.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: PGP Protocol question
Date: Wed, 17 Mar 1999 20:59:25 -0600
In <[EMAIL PROTECTED]>, on 03/17/99
at 10:05 AM, Jim Gillogly <[EMAIL PROTECTED]> said:
>Your description at the top was correct, and describes precisely this
>scenario... which is why I don't understand why you see a problem with
>it.
>It is certainly the case that encrypting the session key hundreds of
>times will be a noticeable computation hit, but hopefully not a
>killer.
You also have the added issue of the message size. A standard e-mail/news
post encrypted several hundred recipients will get rather large. It would
probably be best to have the software break up the recipient list into
groups of 10-20 and send out separate messages for each group. If you have
a list that you want the recipient list suppressed than the only thing you
can do is encrypt a separate copy of the message to each individual
recipient. If you are using the PGP SDK you could code it to use the same
session key for each message but you must *not* have multiple public key
encrypted session keys. This is the same issue that needs to be addressed
with BCC's and automated encryption.
--
===============================================================
William H. Geiger III http://www.openpgp.net
Geiger Consulting Cooking With Warp 4.0
Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
Talk About PGP on IRC EFNet Channel: #pgp Nick: whgiii
===============================================================
------------------------------
From: Jeffrey Haas <[EMAIL PROTECTED]>
Subject: Re: PGP Protocol question
Date: 18 Mar 1999 03:40:19 GMT
Jim Gillogly <[EMAIL PROTECTED]> wrote:
> Your description at the top was correct, and describes precisely this
> scenario... which is why I don't understand why you see a problem with
> it.
There is no problem with the methodology that PGP uses. As pointed out
in another followup, piling all of the encrypted session keys in the same
e-mail message can be a bit cumbersome.
The bit I wasn't making terribly clear is this:
PGP normally piles all of the encrypted session keys in the same
PGP message. What I wish to do is generate the session key, and
then have up to N machines generate the encrypted session keys.
These encrypted session keys would then be attached to individual
e-mails. Thus, each individual gets a properly formatted PGP message
with only a single (their) encrypted session key in it.
Another individual pointed out that the primary weakness is the
smallest public key length. The answer is to require a miniumum key
length on the public key.
I picked on PGP because that was a good concrete example. The questions
apply to any mixed system where symmetric encryption is used on the
plaintext and the public key mechanism is used to deliver the session
keys.
To clarify my questions:
Does distributing a given encrypted message with a common session
key to multiple recipients, each with their own public key, via
separate messages rather than a single large message weaken the security?
What order of complexity are the IDEA and RSA ecryption computations?
Is it worth attempting to save the computer cycles by using a common
session key?
(The above may be in _Applied Cryptography_, but my 1st ed. is out and I'm
waiting to collect enough change to order the 2nd ed.)
Application:
I want to hack majordomo or some other mailing list to handle encrypted
mailing lists. I'm trying to see if its worth doing some tricks to
lower the load on the machine.
> Jim Gillogly
--
Jeffrey Haas
[EMAIL PROTECTED] "Place all beliefs in proper receptacle"
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Site Change
Date: Wed, 17 Mar 1999 20:15:10 GMT
As my site had, some time ago, outgrown the 1 Megabyte limit of Edmonton
Freenet, I had moved it to Xoom, which is a service that offers free
hosting to web sites, like GeoCities and other services. (I must give
thanks to David A. Scott for the suggestion.)
Perhaps because some of their clients had failed to place a Xoom banner on
their home pages, as required, there has been a recent change to how their
service operates. Sites on Xoom will now appear in a frame, with a small
frame at the top of the screen containing a Xoom banner.
Although there was no advance notice about this (which may well be
understandable), in general I have no objection to this policy change.
Unfortunate as it may be, they are providing a free service which costs
them money to provide - and there is really no comparison between this and,
say, the GeoCities watermark.
It should be noted, too, that persons visiting the site with a browser that
is not frames-capable _will still see the site_ and not a page saying
"Sorry, your browser can't handle frames". They are to be commended on this
technical achievement.
However, if you visit the site with JavaScript enabled, it is possible you
may encounter JavaScript error messages, such as
top.thePage has no properties
Please notify me by E-mail of any such problems you encounter.
John Savard (teneerf is spelled backwards)
http://members.xoom.com/quadibloc/index.html
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Partial key exposure
Date: 18 Mar 1999 05:48:45 GMT
Anthony Lineham <[EMAIL PROTECTED]> wrote:
> this is really an algorithm dependent situation so think of it terms of a
> DES-like algorithm.
out of curiosity, is the reason you're revealing six bits of each 16-bit
divison of the key tied up with something like the input to an S-box?
The DES S-boxes are 6-to-4 bit transforms, which is why I'm asking.
Although in order for that to be useful, I guess the 6 bits would have to
survive the processing before they get to the S-box.
for DES -
number bits left to right, 1 to 64 (like Applied Crypto 2nd ed),
key permutation -- does not just simply ignore every 8th bit
1st round - 48bit key chosen by shifting 1 to the left
then you want bits 14, 17, 11, 24, 1, 5 , which the compression permute
sends to 1...6,
which means bits 15, 18, 12, 25, 2, 6 of the original key after permutation,
so you want bits 10, 51, 34, 60, 49, 17 of the raw key to get an input
to the first S-box in the firstt, second, ninth, and sixteenth rounds.
rather, the subkey that's XORed with the plaintext to form an input, but
whatever.
why are the key bits only shifted by 1 and 2, by the way? would 3 or more
cause some kind of a repeat I'm not seeing right now?
So to get the input for a single S-box you'd need to give 6 not very
contiguous bits of the key, which isn't what you were talking about.
It looks like in DES if you had the first 6 bits you might get parts
of inputs for at most 6 S-boxes...like in the first round you'll
get a bit in S-boxes 18 / 6
= 3, another bit in S-box 4
a bit in box 1, a bit in box 7, a bit in box 5, and a bit in box 8,
if you have the first six bits. if I read these tables right. It's nice
that none of these end up in the same s-box - I wonder if that holds
true for all contiguous sequences of six key bits.
I'm not sure how useful that is, but it looks like it's possible to
explicitly characterize where you get partial info given some info about
bits. This may be a reason to avoid situation (2) -- there you have
some partial info about all of the bits, just not enough to say with
certainty about any particular ones...but it looks like you can
trace them all down into the S-box inputs and say "well, I know the XOR
of this and that and this is b."
I guess I should really try to find the number of contiguous bits that
cause bits to come through the expansion permutation in the same S-box
input with fairly high probability, but a small enough number to be
at least a bit plausible (six bits of key is maybe pushing it. no one
will give me sixteen...)
So this is actually making me very nervous about (2), but I don't know
enough about how important such partial info is to say how worried I
should be. Certainly I don't know enough to say that full info on
six independent bits is better or worse than partial info on sixteen.
Do people design expansion permutations like this with the expectation
that contiguous bits of key are more likely to be compromised than
arbitrarily chosen ones?
> My intuitive preference is situation (2) as it doesn't explicitly reveal any
> of the bits, only the possibilities, while (1) gives away 6 bits with
> absolute certainty. Knowledge of these 6 bits might then be used as
> somekind of stepping stone to a further attack.
for a brute force attack, (1) certainly means you have that much less
space to search - maybe the difference between feasible and not for
marginal key lengths and certain attackers. 2**56--> 2**50 for example, against
someone with a Beowulf cluster.
for DES, (2) makes me nervous now. but not sure about more than that.
it certainly cuts down the keyspace, but I have to go calculate to
figure out by how much.
Thanks,
-David Molnar
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: RC4 file encryptor (please take a look)
Date: Thu, 18 Mar 1999 00:16:47 -0800
[EMAIL PROTECTED] wrote:
[...]
> Basically I want to have people evaluate the effectiveness of the public_key
> portion.
There is no public/private key pair in the program. Are you
talking about the salt?
--Bryan
------------------------------
Date: 17 Mar 1999 21:03:46 -0000
From: EO <Use-Author-Address-Header@[127.1]>
Subject: Re: PGP Protocol question
=====BEGIN PGP SIGNED MESSAGE=====
Jeffrey Haas wrote ...
>This question has more to do with methodology than algorithms.
>
>To the best of my understanding, when encrypting a given plaintext
>in PGP for multiple recipients, PGP does the following:
>
>[many steps elided]
>Creates a session key
>Encrypts the plaintext with the session key (classical encryption).
>Encrypts the session key with the public key of each recipient.
>Creates a message that has all of the above in it.
>
>Here's what I'm considering:
>If you have mail list software, and you want to send to hundreds
>of recipients their messages to each other encrypted using PGP
>it is computationally expensive to individually encrypt the same
>plaintext with different session keys.
Yes,
>To spread the load, the plaintext could be encrypted with
>the same session key and the session key could, in a distributed
>fashion, be encrypted with each of the subscriber's public keys.
>The maillist software could then assemble a valid PGP message
>for each subscriber from the above components.
Already done that way: the plaintext gets encrypted only
once, it's the session key that gets encrypted multiple
times - once for each recipient. *All* of these encrypted
session keys are attached to the PGP-message, so all the
recipients will recover the same session key.
So the assembled PGP-message looks something like:
I--------------------------------------I
I Session key encrypted to recipient 1 I
I--------------------------------------I
I Session key encrypted to recipient 2 I
I--------------------------------------I
I Session key encrypted to recipient 3 I
I--------------------------------------I
I I
I I
I The interesting stuff - encrypted I
I with the session key I
I I
I I
I--------------------------------------I
>Ignoring the security of the list software's secret key and
>the security of the end-user's private keys (you have to trust
>people to keep their own secret's secure, and thats usually a bad
>assumption), what are the problems with the above scenario?
>If this is a case of RTFM, please point out the particular TFM. :-)
The smallest public key is the weakest link in the chain,
naturally. If you encrypt to a bunch of super-secure 4096-bit
keys, but there's one puny 512-bit RSA key (someone imported
one from 2.6 version, ok?!) the whole message is compromised.
- --EO
~~~
This PGP signature only certifies the sender and date of the message.
It implies no approval from the administrators of nym.alias.net.
Date: Wed Mar 17 21:03:43 1999 GMT
From: [EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: 2.6.2
iQEVAwUBNvAYsU5NDhYLYPHNAQEjXgf+JDzBad13KrPx9aNjn2Nu2yV+CKADIRX6
j1fM+uXZ7dp7xeTREIg4fM/axN1daFjt6wu8fRduvZQVZbrO2vklQYgsZpztm8ip
3fjSxy4w1Jb4XuM1KDStfnJaalHgGnaBQq9a/aJr3/6so5/Wh9UgskySlKkBYp2/
94FE2GCMtMzg1jVTGKWQio/sXftr+5vcTCtDo/cNOQdUxFFigu0iJjXqJnYMdLgw
8yGDcDM7lQAa249a3flLNwXvOXTZ8a/8Asy/EfNqMQER8Hs8L2Tfvsyt9O/OUDwB
esN+Rkt8VI5fJNjkL7ehkIuWVS7qANB0ZlQQ39s3NPzoc0NWXq83Ag==
=06yI
=====END PGP SIGNATURE=====
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: Thu, 18 Mar 1999 09:51:01 +0100
Patrick Juola wrote:
> That is *NOT* true, on at least two counts. First, if you have a
> quantity that you can determine approximately, it needn't be
> determinable to within an arbitrary degree of precision for
> comparisons to be useful -- using a stopwatch, I can only measure
> time to tenths of a second, and yet, it's still a useful instrument.
>
One always need a precision that corresponds to the application.
If that precision can be attained in practice, then it is o.k.
Otherwise it is not o.k.
> Secondly, we *can* measure Kolmogorov complexity to arbitrary degrees
> of precision for some types of strings.
For trivial strings, like all 1's, I am very sure that one can.
But we need a measure for practical sequences, for practical
applications.
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
******************************
