Cryptography-Digest Digest #246, Volume #9 Wed, 17 Mar 99 15:13:04 EST
Contents:
Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED (Mark Currie)
Re: Crypto transmission in noisy ambient (Mark Currie)
Re: a5 (Andrew Haley)
Re: One-Time-Pad program for Win85/98 or DOS (Patrick Juola)
Re: DIE HARD and Crypto Grade RNGs. (Patrick Juola)
Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED (Doug Stell)
CUNY CRYTOGRAPHY SEMINAR (MikeAt1140)
? Random et BigInteger (Gallicus)
TESTINTONLY (sb5309)
Re: PGP Protocol question (Jim Gillogly)
Re: a5 ("Maciej Maciejonek")
Re: PGP Protocol question (Medical Electronics Lab)
Re: a-8d~0.2844.5k:-89y (JimB417)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mark Currie)
Subject: Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED
Date: 17 Mar 1999 10:24:32 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>And, because of this concern, I expressed some doubt that, as some books
>have claimed, that the STU-III or other current advanced encryption
>equipment would operate without key material in the manner of a copy of
>PGP. But I noted that one could still use public-key techniques, even if
>one doesn't fully trust them, as one leg of a 'triad', to use a term from
>nuclear defense terminology. And so, I will summarize a point I tried to
>make in another post some time ago:
>
>Key hidden in hardware - compromised through reverse-engineering of
>captured hardware.
>
>Key loaded by personnel - vulnerable through suborning of personnel.
>
>Key generated and used via public-key mechanisms - vulnerable through
>mathematical advances.
>
>If you're handling military secrets, use all three mechanisms - each one
>with a key big enough so that if one of the three keys only remains
>secure, your communications are secure. If the 'big boys' _aren't_ doing
>this, they should start thinking about it.
It is probably wise to combine secret cryptography techniques with public key
ones, however, do you not then create problems with key management. Now you
have to maintain a secret key management system with all its limitations that
the public key systems were supposed to cure. Quite often the real security
problems with secret key systems were in fact in the management thereof. Unless
the concurrent secret key management system provides relatively the same
security level as the public key one, then it may end up only being an extra
nuisance factor for a serious attacker.
I guess that where the big boys are concerned however, they can afford the
overhead of providing a strong secret key management system as well.
Mark Currie
------------------------------
From: [EMAIL PROTECTED] (Mark Currie)
Subject: Re: Crypto transmission in noisy ambient
Date: 17 Mar 1999 10:41:49 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
>
[snip]
>2) Use a pure stream cipher with no error-propagation, with a message
>format (i.e. uncompressed text) that can still be read in case of error.
[snip]
This can be a very useful method. However, another problem that tends to
occur in a noisy comms environment is "bit slip/gain". i.e. when the data is
reconstructed, it has shifted by one or more bits. On a stream cipher, this is
disasterous since you loose key stream synch permanently. There are however
techniques that can be applied to correct for this such as bit-wide cipher
feedback or inserting synch characters in the data stream. However, these
techniques obviously propagate errors, and may only be useful where the data
itself is error tolerant such as voice, graphics, etc.
Mark Currie
------------------------------
From: [EMAIL PROTECTED] (Andrew Haley)
Subject: Re: a5
Date: 17 Mar 1999 11:30:32 GMT
Maciej Maciejonek ([EMAIL PROTECTED]) wrote:
: Anybody knows any facts about cipher a5 (a3,a8).
It's not a very good cipher.
: I'm interested in algorithm of this cipher, becouse I'm considering
: its implementation in hardware ( Altera environment )
Search for the following news artile on http://www.dejanews.com
From: [EMAIL PROTECTED] (Ross Anderson)
Newsgroups: sci.crypt,alt.security,uk.telecom
Subject: A5 (Was: HACKING DIGITAL PHONES)
Date: 17 Jun 1994 13:43:28 GMT
Andrew.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Crossposted-To: alt.security,alt.privacy
Subject: Re: One-Time-Pad program for Win85/98 or DOS
Date: 17 Mar 1999 08:25:36 -0500
In article <7cnkt1$2bme$[EMAIL PROTECTED]>,
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.
>
>Equiprobability from your above definition requires equidistribution. You
>can have unpredictable sequinces of numbers where some numbers occur less
>commonly than others.
>
>For example
>
>1 2 1 1 3 2 3 4 3 2 4 1 2 1 9 1 2 1 2 3
>
>The sequence have a larger tendency for numbers closer to 1 than numbers
>closer to 9 (the range being 1 to 9 in the above example).
>
>There are infinitely many possible combinations for such sequences of
>numbers despite the fact that some numbers occure less often than others.
>
>If your definition for Randomness used the classical definition - an
>unpredictable sequence of numbers - then it doesn't need to be equilly
>distributed.
But a biased OTP is breakable -- sometimes easily so, depending
on the degree of bias. The equiprobability is a necessity if you
want a completely secure OTP.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: 17 Mar 1999 08:29:02 -0500
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>Patrick Juola wrote:
>>
>> In article <[EMAIL PROTECTED]>,
>> mok-kong shen <[EMAIL PROTECTED]> wrote:
>>
>> >The problem I see is the following: One defines a quantity which
>> >one can never really compute and then theorize in the 'world' in which
>> >this quantity is (assumed to be) computable/manipulable and then 'map'
>> >the results thus obtained into our real world. I personally doubt that
>> >this is a genuinely valid scientific approach.
>>
>> Depends on whether or not you find a method of manipulating something
>> close to Kolmogorov complexity -- and of finding something close to
>> Kolmogorov complexity. As it happens, we've got something "close to"
>> Kolmogorov complexity for some applications -- it's called, for instance,
>> Lempel-Ziv complexity (or maybe Ziv-Lempel). And if you look at the
>> theorems closely enough, you can get meaningful (over)estimates of
>> the Kolmogorov complexity of some sequences generated by some kinds of
>> sources.
>>
>> If you want an example of that in Real Life, check out my paper in the
>> most recent Journal of Quantitative Linguistics, or my paper in the
>> proceedings of CogSci-98, both of which are applications of K-complexity
>> estimates in AI. Chater and Hahn have an interesting application in
>> psychology, published in SimCat 97, IIRC.
>>
>> Formally speaking, we can't measure momentum, either -- but we find
>> our approximations to momentum to be sufficiently good that physicists
>> and engineers use it in their computations.
>>
>> As I said, if you don't like what K-complexity does for you, don't use it.
>> Some of us find it extremely useful in some applications.
>
>If you have some quantity that one can at least determine approximately
>(to some arbitrarily good degree) even if not 'exactly' like the
>momentum you mentioned, then it is practical and certainly o.k. But
>there is NO method (algorithm) at all to determine the Kolmogorov
>complexity.
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.
Secondly, we *can* measure Kolmogorov complexity to arbitrary degrees
of precision for some types of strings.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED
Date: Wed, 17 Mar 1999 15:21:25 GMT
On 17 Mar 1999 10:24:32 GMT, [EMAIL PROTECTED] (Mark Currie) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>It is probably wise to combine secret cryptography techniques with public key
>ones, however, do you not then create problems with key management. Now you
>have to maintain a secret key management system with all its limitations that
>the public key systems were supposed to cure.
Actually the public key system provides the key management for the
secret key system, thereby, creating a hybrid system. That's what
algorithms like Diffie-Hellman and KEA are specifically intended to
do. There are better, more secure schemes also.
> Quite often the real security problems with secret key systems were in fact
>in the management thereof.
True. Secret key systems are subject to compromises in the key
handling, e.g., John Walker. Again, that's what public key systems and
Benign Fill techniques are specifically intended to eliminate. The
idea is to make keying material valueless to the adversary.
True. Secret key systems also require huge amounts of key material and
management overhead. Public key support in key management reduces this
substantially.
>I guess that where the big boys are concerned however, they can afford the
>overhead of providing a strong secret key management system as well.
Actually, they can't afford it in terms of cost, complexity, speed or
security. In the Type 2 systems (FORTEZZA), they have even gone to
decentralized public key management to reduce the burden. Remember
that KEA is the Type 2 key management algorithm, declassified and made
public last June by the big boys, purely for financial reasons.
------------------------------
From: [EMAIL PROTECTED] (MikeAt1140)
Subject: CUNY CRYTOGRAPHY SEMINAR
Date: 17 Mar 1999 16:38:24 GMT
CUNY CRYTOGRAPHY SEMINAR
Date/Time: Friday March 26, 2 PM
Room: 1223 Graduate School (but may be changed if so note posted)
Speaker: James Reeds
,AT&T Research Labs
Topic: Three Renaissance puzzles with a cryptographic flavor
The late 15th century Voynich manuscript is written in an unknown
cipher script that has resisted all attempts at reading for 80
years. But maybe it's really not a cipher at all but a hoax, or a
madman's scribbles, or written in an invented language, or a
written equivalent of glossolallia. The Book of Soyga, studied by
John Dee (1527-1608), is a 16th century magic treatise with a
hidden mathematical surprise. And Book 3 of the 1500 Steganogra-
phia by Johannes Trithemius (1462-1516) contains recently
discovered hidden cipher messages. In this informal talk Jim
Reeds will describe some of his work on these puzzles.
-- Jim Reeds, AT&T Labs - Research Shannon Laboratory, Room C229,
Building 103 180 Park Avenue, Florham Park, NJ 07932-0971, USA
[EMAIL PROTECTED], phone: +1 973 360 8414, fax: +1 973 360
8178
Professor Michael Anshel
Department of Computer Sciences R8/206
The City College of New York
New York,New York 10031
------------------------------
From: [EMAIL PROTECTED] (Gallicus)
Crossposted-To: fr.comp.lang.java
Subject: ? Random et BigInteger
Date: Wed, 17 Mar 1999 17:15:44 GMT
Je me distrais en ce moment en programmant en Java 1.2 un problème
d'empilement de jetons (knapsack). J'ai besoin d'obtenir une liste de
nombres entiers aléatoires tels que :
le premier soit entre 3 et 10, par exemple 5
le deuxième entre (3 +5) et 20, par exemple 12
le troisième entre (3+12) et 40, par exemple 22
le quatrième entre (3+22) et 80 etc...
Je n'ai aucun problème si je travaille avec des entiers de type long.
Mais je souhaite travailler avec des entiers de type BigInteger car d'une
part je compte pousser la maquette vers des nombres supèrieurs à 2^64, et
d'autre part je veux pouvoir bénéficeier des méthodes d'arithmétique
modulaire de cette classe.
J'ai beau lire la doc de javal.math.BigInteger, je ne parviens pas à
obtenir un BigInteger aléatoire, et encore moins un BigInteger aléatoire
situé entre une limite inférieure et une limite supérieure.
Merci d'avance de bien vouloir me mettre sur la voie.
Gallicus.
------------------------------
From: sb5309 <[EMAIL PROTECTED]>
Subject: TESTINTONLY
Date: Thu, 18 Mar 1999 01:21:29 +0800
Reply-To: [EMAIL PROTECTED]
TEST
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: PGP Protocol question
Date: Wed, 17 Mar 1999 10:05:00 -0800
Reply-To: [EMAIL PROTECTED]
I didn't understand what the problem is, so I thought I'd try it
off-line rather than go through multiple iterations on the newsgroup.
Jeffrey Haas wrote:
> 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.
Right.
> 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.
>
> 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.
Yes, this is what standard PGP does.
>
> 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?
No problem.
> If this is a case of RTFM, please point out the particular TFM. :-)
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.
--
Jim Gillogly
25 Rethe S.R. 1999, 17:58
12.19.6.0.10, 5 Oc 3 Cumku, First Lord of Night
------------------------------
From: "Maciej Maciejonek" <[EMAIL PROTECTED]>
Subject: Re: a5
Date: Wed, 17 Mar 1999 18:26:12 +0100
Meybe You give me more detail information about this algorithm
Andrew Haley napisa³(a) w wiadomo¶ci: <7co3oo$533$[EMAIL PROTECTED]>...
>Maciej Maciejonek ([EMAIL PROTECTED]) wrote:
>: Anybody knows any facts about cipher a5 (a3,a8).
>
>It's not a very good cipher.
>
>: I'm interested in algorithm of this cipher, becouse I'm considering
>: its implementation in hardware ( Altera environment )
>
>Search for the following news artile on http://www.dejanews.com
>
>From: [EMAIL PROTECTED] (Ross Anderson)
>Newsgroups: sci.crypt,alt.security,uk.telecom
>Subject: A5 (Was: HACKING DIGITAL PHONES)
>Date: 17 Jun 1994 13:43:28 GMT
>
>Andrew.
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: PGP Protocol question
Date: Wed, 17 Mar 1999 12:36:19 -0600
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.
But PGP doesn't do that. It only ecrypts one session key for each
recipient and then attaches all the encrypted session keys to the
document.
>
> 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.
PGP already does this.
> 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. :-)
I think it explains this in the PGP docs. Certainly that's
how it was in version 2.6, I haven't really kept up with all
the additions since. I can't imagine they'd change it tho.
Patience, persistence, truth,
Dr. mike
fillerfillerfillerfillerfillerfillerfillerfillerfillerfillerfiller
fillerfillerfillerfillerfillerfillerfillerfillerfillerfillerfiller
fillerfillerfillerfillerfillerfillerfillerfillerfillerfillerfiller
fillerfillerfillerfillerfillerfillerfillerfillerfillerfillerfiller
fillerfillerfillerfillerfillerfillerfillerfillerfillerfillerfiller
fillerfillerfillerfillerfillerfillerfillerfillerfillerfillerfiller
fillerfillerfillerfillerfillerfillerfillerfillerfillerfillerfiller
fillerfillerfillerfillerfillerfillerfillerfillerfillerfillerfiller
------------------------------
From: [EMAIL PROTECTED] (JimB417)
Subject: Re: a-8d~0.2844.5k:-89y
Date: 17 Mar 1999 19:31:21 GMT
Keith wrote:
>/Somebody/ has WWWWWWAAAAAAAAAAYYYYYYYYYYY too much time on their
>hands. Besides, isn't a major part of "faith" in trusting that God
>exists even without 'proof.' I'm not sure who this guy is trying to
>convince.... us or himself. I didn't realize that boring people to
>death was a way to convice them that Jesus Christ is Lord..... hrmph,
>maybe I'm Wrong....
>
>Keith "Firm believer, even without the 'devidence'" D.
This newsgroup sci.crypt is not the place for religious ranting and ravings.
Please confine the discussion to cryptography topics, thank you.
------------------------------
** 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
******************************
