Cryptography-Digest Digest #952, Volume #8 Sat, 23 Jan 99 04:13:03 EST
Contents:
Re: Help: Which secret key cipher? (Darren New)
Re: Crack in Export Laws?? (Paul Rubin)
Invitation (was: *** Where Does The Randomness Come From ?!? ***) (Ron Cecchini)
Re: french law about cryptography (Paul Rubin)
Re: Help: Which secret key cipher? ("Trevor Jackson, III")
Re: ScramDisk - password size - high ASCII ("Sam Simpson")
Encryption and mailinglists (Jan Garefelt)
Re: Metaphysics Of Randomness ("Douglas A. Gwyn")
Re: Help: Which secret key cipher? (Terry Ritter)
Re: sci.crypt intelligence test. ([EMAIL PROTECTED])
Re: S-box cycles ([EMAIL PROTECTED])
Re: Multiple key cipher bit strength? (wtshaw)
hardRandNumbGen (".���`�..���`�..���`�..���`�..���`�..���`�.")
----------------------------------------------------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: Help: Which secret key cipher?
Date: Sat, 23 Jan 1999 01:43:10 GMT
> > I think a more interesting question is whether it's possible to build a
> > physical environment that makes tampering impossible. I.e., unless I
> > personally courier it, how do I know the courier didn't copy the pad? Is
> > there secure envelope technology that would make it prohitively
> > expensive to access the DVD and put it back without someone else
> > noticing?
>
> You can probably make copying arbitrarily hard by spending lots of money on
> it,
I think the question I should have asked is, can you make it arbitrarily
harder/more expensive to copy it than it is to wrap it up in the first
place. Phrased that way, I think the answer is clearly "no", in that if
I have the thing, I can do whatever I want to get at the DVD disk, then
just make a new DVD disk and wrap it up exactly the same way you did for
the same cost.
> but an alternate path to security is to reduce the set of *people* who
> have to be trusted (couriers of whatever) to the minimum by amking the best
> use of the few who are most trusted. Data density help here.
Right. I was thinking if you only trusted yourself and the recipient,
you just both press disks, meet in the middle, and exchange disks, then
XOR the two when you got home. As long as both disks aren't comprimised,
you'd be OK.
--
Darren New / Senior Software Architect / MessageMedia, Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
"You could even do it in C++, though that should only be done
by folks who think that self-flagellation is for the effete."
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Crack in Export Laws??
Date: Sat, 23 Jan 1999 01:31:02 GMT
In article <[EMAIL PROTECTED]>, Kazak, Boris <[EMAIL PROTECTED]> wrote:
>Paul Rubin wrote:
>>
>> This is called Server Gated Cryptography. It's present in
>> Netscape Navigator 4.x and MSIE 4.x browsers and there's a
>> patch for MSIE 3.x to support it. In order to enable it,
>> your web server needs a special certificate (an SGC certificate)
>> which at the moment is only available from Verisign (Global ID).
>--------------
>However, technically it seems equivalent to just sending a cookie
>and configuring the browser remotely. I would not be surprised if
>the exact procedure will be hacked, listed and posted on the Web
>for everybody's use. Especially now, when the source code of
>Netscape products is opened.
No, you CANNOT configure an exportable browser to do 128-bit
cryptography unless you do something like reverse engineer and
patch the binary (as in www.fortify.net). SGC is only enabled if
the browser gets a digitally signed certificate from the server
enabling it.
>> Global ID's are available only to US corporations and overseas
>> companies and banks under certain circumstances. See the
>> Global ID page in the web server security section of www.verisign.com
>> for more info. Basically, you're allowed to get these certificates
>> and enable strong cryptography in exportable browsers only in
>> applications that the US goverment approves of--and that's been
>> the case all along. It's just a little more streamlined now.
>------------------------------
>But then apparently it is the first step. USA banks have lots of foreign
>customers, and they don't want to lose this hefty supplement to their
>business. The pressure to allow strong cryptography in exportable
>browsers can only increase with time. They want their overseas clients
>to be able to access their accounts on-line.
Yes, US (and other) banks are allowed to do this. This is one of the
US government approved uses of SGC. Is it part of the reason SGC
exists. The point is that the government exercises regulatory control
over the bank or has international agreements with the country where
the bank is. If the government wants to examine your banking data, it
doesn't need to decrypt your SSL communications with your bank. It
just asks the bank for the info and the bank gives it to them. So
banks are allowed to use SGC.
>> Interestingly, I've been hearing from some server vendors that
>> they can't get Global ID's without a crypto export license--even to
>> ship servers to domestic US customers, even if the servers will
>> connect only to domestic US clients, so no exporting is involved.
>> What a pain!
>---------------------------
>Server vendors should ally themselves with the banks, this union will
>be VERY powerful...
It's more an issue of the certificate vendors (really there's just one).
The big server vendors are M$ and Netscape and Verisign offers SGC
certificates for both of them. If you want to use any other brand of
server, you're out of luck, for now.
------------------------------
From: [EMAIL PROTECTED] (Ron Cecchini)
Subject: Invitation (was: *** Where Does The Randomness Come From ?!? ***)
Date: Fri, 22 Jan 1999 23:15:40 -0500
The following is being posted to the groups:
sci.physics.particle
sci.physics.relativity
sci.physics
sci.astro
talk.origins
sci.skeptic
sci.logic
sci.crypt
This one-time "spam" is an invitation to join this thread in
sci.philosophy.meta.
It's an attempt to organize a discussion which necessarily draws from
many disciplines. There's nothing new about that or any of this really.
However, this type of discussion often pops up in various groups where
the people may have expertise in one area but not another, and i thought
it would be very interesting to try to get a wide sampling of people in
on the fray!
Nathan Urban suggested sci.philosophy.meta, and it seems like a perfect
spot to organize this thread, which right now is going on in 8 or 9 groups.
[ Note to sci.crypt -
Actually, the thread never made it to your group.
However, someone pointed me to you guys & i see you have an interesting
thread going on regarding "The Metaphysics of Randomness" which i think
is very appropriate. ]
Tempers are sure to be lost <raises hand>, but i promise to try to keep
it under control. Also, the subject is sure to take different twists &
turns, and while i'd like to keep it as just one thread (makes it easier!),
the extremely low volume in sci.philosophy.meta might allow for this.
...
The topic of the thread is a *scientific* discussion attempting to reconcile
Determinism and Randomness.
i made the original post only a day or so ago, so it should still be on your
servers, or do a DejaNews search at some point in the near future.
i hope you join.
thanx
ron
------------------------------
Crossposted-To: talk.politics.crypto
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: french law about cryptography
Date: Sat, 23 Jan 1999 03:23:16 GMT
In article <783ddh$qph$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>19 jan 1999. the french prime minister announced that the gouvernement
>will allow the key size up to 128bytes.
>
>the original text in french:
>http://www.premier-ministre.gouv.fr/PM/D190199.HTM
It's also in English at:
http://www.premier-ministre.gouv.fr/GB/INFO/FICHE1GB.HTM
------------------------------
Date: Fri, 22 Jan 1999 20:57:17 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Help: Which secret key cipher?
Darren New wrote:
> > > I think a more interesting question is whether it's possible to build a
> > > physical environment that makes tampering impossible. I.e., unless I
> > > personally courier it, how do I know the courier didn't copy the pad? Is
> > > there secure envelope technology that would make it prohitively
> > > expensive to access the DVD and put it back without someone else
> > > noticing?
> >
> > You can probably make copying arbitrarily hard by spending lots of money on
> > it,
>
> I think the question I should have asked is, can you make it arbitrarily
> harder/more expensive to copy it than it is to wrap it up in the first
> place. Phrased that way, I think the answer is clearly "no", in that if
> I have the thing, I can do whatever I want to get at the DVD disk, then
> just make a new DVD disk and wrap it up exactly the same way you did for
> the same cost.
>
> > but an alternate path to security is to reduce the set of *people* who
> > have to be trusted (couriers of whatever) to the minimum by amking the best
> > use of the few who are most trusted. Data density help here.
>
> Right. I was thinking if you only trusted yourself and the recipient,
> you just both press disks, meet in the middle, and exchange disks, then
> XOR the two when you got home. As long as both disks aren't comprimised,
> you'd be OK.
Agreed. The hard problems appear when you have to use a third party to create
and/or distribute the key material.
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: ScramDisk - password size - high ASCII
Date: Tue, 12 Jan 1999 11:50:01 -0000
Indeed I did.
I must have got carried away with resistance against brute force etc :-)
There is currently a group working on a Linux port - I shall speak to the
group and see how they are coming along and report back.
Thanks,
Sam Simpson
Comms Analyst
-- http://www.hertreg.ac.uk/ss/ for ScramDisk hard-drive encryption & Delphi
Crypto Components. PGP Keys available at the same site.
Denning wrote in message <[EMAIL PROTECTED]>...
>
>
>[EMAIL PROTECTED] wrote:
>
>Your reply, as good as it was, did completely gloss over the Linux port
question.
>Is it possible that ScramDisk will be ported to Linux?
>
------------------------------
From: [EMAIL PROTECTED] (Jan Garefelt)
Subject: Encryption and mailinglists
Date: 22 Jan 1999 22:26:59 +0100
Has anything been written on the subject of encryption in conjunction
with mailing lists?
I am interested in theoretical papers as well as in actual
implementations using S/MIME, PGP or any crypto package flavour.
Thank you
/Jan Garefelt
--
Jan Garefelt [EMAIL PROTECTED]
(You know what part to remove to get my mail address!)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Metaphysics Of Randomness
Date: Sat, 23 Jan 1999 03:55:35 GMT
"R. Knauer" wrote:
> On Fri, 22 Jan 1999 11:40:16 -0500, Dorina Lanza <[EMAIL PROTECTED]>
> wrote:
> >Next you will posit that the key has become "entangled" with both
> >the plaintext and the cipher text such that no one should ever use
> >any of them again.
> No, the decryption process untangles them.
If you follow up my earlier hint, you see that the number in itself has
no special (random/nonrandom) property, but only in relation to the
context within which it "occurs". The same number might be nonrandom
with respect to one ciphertext (for which it is the key) but random
with respect to another ciphertext (for which it has no particular
relationship). Thus the whole idea of an absolute "registry" of
(states of) numbers is fallacious. If you wanted to maintain such a
registry you'd need to include along with the number an indication of
the context for which it has special significance.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Help: Which secret key cipher?
Date: Sat, 23 Jan 1999 05:15:24 GMT
On Fri, 22 Jan 1999 20:31:45 -0500, in <[EMAIL PROTECTED]>,
in sci.crypt "Trevor Jackson, III" <[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>
>> [major snip]
>> We don't remember one-time pads.
>
>True. We shred/burn/stir-ashes or whatever. I do not recommend keeping OTP CDs
>around at all. I'd recommend magnetic media that can be erased after each chunk is
>used.
This prevents compromise *after* use, but what possible compromise
*before*? If we transport a huge amount of keying material we
necessarily keep a lot around for a long while. And the longer we
keep it, the more chance of compromise there is.
And if we do not somehow "start anew" frequently, any earlier
surreptitious compromise can bleed us dry.
>[...]
>I shouldn't have snipped so much because there no reason NOT to encrypt an OTP. A
>hierarchy of pads is easy to envision. Assume a master key in some heavily guarded
>repository and message keys masked by the master. This would provide some internal
>security in the organizations using the system.
But if we talk about encrypting an OTP with a master OTP, then,
surely, we cannot use the master more than once (or it would not *be*
an OTP). And if we cannot expand the amount of keying material in
this way, it is hard to see how we could have a hierarchy.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto
Subject: Re: sci.crypt intelligence test.
Date: Sat, 23 Jan 1999 07:56:29 GMT
> >> Windows GUI version of Ciphile Software's Original Absolute Privacy -
> >> Level3 encryption software available very soon.
> >> (This process is patent pending.)
>
> Is that the slithering of well-greased ophidians I hear?
>
God that's funny
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: S-box cycles
Date: Sat, 23 Jan 1999 07:41:30 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Terry Ritter) wrote:
>
> On 22 Jan 1999 23:50:45 GMT, in <78b2sm$n5r$[EMAIL PROTECTED]>, in
> sci.crypt [EMAIL PROTECTED] wrote:
>
> >I have what I think is a simple question:
> >
> >How important, in terms of cryptographic strength, is whether or not
> >an S-box's cycle length is equal to its size?
>
> The only evidence of which I am aware is that an S-box should *not*
> have just a single cycle.
>
> ---
> Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
> Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
>
>
I think it is best to have a random S-box be a single cycle.
However the case can be made for 2 or 3 cycles being best.
Since certain festals types of block ciphers can be attacked
by Paul Onion like methods that use the cycle length information.
So the anwser my depend on how and where the S-box is used.
But remember if one has a single cycle 8 bit S box. It can contain
the exact amount of information as a multicycle 16 bit S box.
but no set of 2 8 bit s boxes can represent a single cycle 16
bit S box. Another thing to think about is that if you increase
the number of cycles to a maximum like for the 8 bit S box it
would be 256 cycles. You end up with the identity transform
which even some one with no brains like Hamilton would condsider
weak. I take that back he usually disagrees with what I say so
he might even say it's not weak.
David A. Scott
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Multiple key cipher bit strength?
Date: Sat, 23 Jan 1999 01:14:09 -0600
In article <78acto$5ue$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> Hi, I'm looking for a general way to calculate the effective bit strength of a
> multiple decryption key cipher (ie if the key space is 128 bits and has 3 keys
> that can decrypt the data, what is the effective strength?)
The ideal is to be able to add key lengths. Depending on the algorithm,
this might not be really true. For many cipheres just encrypting with
three different keys in the same way might just give the strength of one
key, if you could find it. A combination of keys with different roles in
the algorithm can be effective, or it might mean that there are many
equivalent combinations of keys, all dependent on the algorithm itself
>
> My exact situation is this:
>
> I'm trying to implement a secure cache that will contain cached resources
> (multiple keys). In order to get access to a resource, you must know its
> exact name, which will be a long random string. I guess what I'm wondering
> is, if I use names that are 128 bits long, and I have 1000 entries in the
> cache, how difficult would it be to find *ANY* data just by brute force.
1000 entries is close to 1024, which could be written as 10 bits. The
average of finding any of the data is 128 bits, less the 10, or 118. A
search might be effective on the first try, or if lots of the keys were
bunched together, one might get lucky and hit one in the cluster, and
solve others not too different.
> Basically I'm looking for a general equation which I can calculate the
> general bit strength.
>
Lots of others are looking for something similar. All we have is relative
strengths, and they are not anything too quantitative as so much depends
on the nature of the algorithms.
Given a certain algorithm, you might be able to compare different sized
keys. Looking at scalable algorithms is useful because you can study the
strength of a small keylength, then, scale it up to a level you might
select.
--
A much to common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
From: ".���`�..���`�..���`�..���`�..���`�..���`�." <[EMAIL PROTECTED]>
Subject: hardRandNumbGen
Date: Fri, 22 Jan 1999 23:24:52 -1000
hardRandNumbGen
Those who seek to capture random numbers in their natural
habitats often are faced with two difficult paths: to wait
quietly for the small whispers of thermal noise or to
become immersed in the dazzling thrashes of large signal
sources. Both ways may lead to success, or to a failure
so desperate, that every adversary may be seen as a
stalker in the night. The story you are about to read is
true: "The Hardware Random Number Generator!"
Our story starts in the late 1940's with a Bell Labs
researcher in his Ivory Tower setting. Dusting off an old
book on physics, a young researcher reads about noise from
resistors:
"Thermal noise is produced as a result of thermally
excited random motion of free electrons in a conducting
medium, such as a resistor".
This is the old wisdom of Kirchhoff and Kelvin. Randomness
may be gathered from an RMS voltage of about 4kTRB, where
B is the bandwidth, R is the resistance, T is temperature,
and k is Boltzman's constant. Faced with adversaries, the
researcher knows he must use small resistors which are more
immune to remote interference. But if 300 ohms are used,
the voltage will only be two microvolts! An amplifier with
a gain of a million will be needed to make the noise useable
for his secret cryptographic purposes. Then the amplifier
itself will become susceptible to outside influences.
Millions of people are depending on his team to find a better
source of random numbers, when he has an inspiration. Like
a collection of atoms whose motion so hard to predict, if
he can use variable oscillators, or gyrators, as he likes to
call them, then their combined signals would be hard to predict.
Small variations in conditions would change the "large signal"
outputs from his circuits, which he could sample at regular
intervals. That was the beginning. Today, my friends, we are
ready to receive the benefits of Large Signal Random Sources.
No longer will we wait, with a hope and a prayer, that the
microvolt sources of randomness will not fall victum to the
beamed manipulations of deviant hackers, NO, digital large
signals have brought us immunity from such a fate.
But it is not just the hacker who would mug our chaotic joy,
it is the very regularity of our clock cycles and the very
power of our conforming buses which threaten to impart a
hideous regularity to our nonces, our IVs, our keys. The
heartbeat of a computer is its clock, and a powerful hammerblow
it is to any mere analog circuit which would dare to reside
on our motherboards. This is why we cannot use sensitive
amplifiers to boost the whispers of thermal noise. This is why
Large Signal Sources are our refuge, our bounty, our provider
of Hardware Random Number Generators. Oscillators, I tell you,
OSCILLATORS, they are our main hope, and the pride modern
civilization. I cannot exaggerate too much, the importance of
avoiding the mistakes of past designers, who, through wishful
thinking, risked it all, and lost, to the whims of a tiny hiss.
So go now, brash young designers of tomorrows crytosystems, go
to your keyboards and your mice, and always remember: It is
better to have thrashed and lost some quality, than to never
have thrashed at all.
.���`�..���`�..���`�..���`�..���`�..���`�. 1999/1/22
------------------------------
** 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
******************************
