Cryptography-Digest Digest #180, Volume #9 Wed, 3 Mar 99 14:13:04 EST
Contents:
Re: AES2 papers now available at NIST (Robert Harley)
Re: KL-7 Cipher machine (John Hairell)
Re: Computational Complexity (Michael Sierchio)
Re: sci.crypt.randomness (wtshaw)
Blowfish, Snake Oil, and the Osterich Algorithm :-) (Craig Inglis)
How can decrypt this file? (Elmar)
Re: Testing Algorithms (Medical Electronics Lab)
Re: Analysis (wtshaw)
Re: Testing Algorithms (Guenther Brunthaler)
----------------------------------------------------------------------------
From: Robert Harley <[EMAIL PROTECTED]>
Subject: Re: AES2 papers now available at NIST
Date: 03 Mar 1999 17:03:33 +0100
Henry Lewsal <[EMAIL PROTECTED]> wrote:
>After reading the AES papers related to smart cards, it seems
>that none of the candidates were designed to be resistant to
>timing attacks and power analysis attacks.
I don't know about power analysis but it is easy to make DFC resistant
to timing attacks. I did it before but it costs a few cycles. Just
apply the following 'diff' to the rf() function in the Appendix of the
"DFC Update" AES2 paper and Bob's your uncle:
< if (!t) return CP;
< b += 13UL; return CP;
---
> b += 13UL*(t != 0UL);
> return CP;
Just to prove the point, I've appended the compiled output for the
dfc() function on Alpha at the end. No branches in sight. Same with
all combinations of compiler and optimisation flags that I've tried.
Also, on Louis Granboulan's timing table the footnote to the 393-cycle
Pentium Pro implementation mentions:
>This implementation can be made totally branchless and
>data-independent at a cost of 40 cycles (protection against timing
>attacks).
That was done by Terje Mathisen.
---
I just saw the AES2 paper called "The DFC Cipher: an attack on
careless implementations" by Ian Harvey. It seems to be arguing that
codes with broken implementations are broken.
It starts off by observing that implementations that aren't protected
against timing attacks may be subject to timing attacks.
This is vacuously true and not specific to DFC.
It mentions:
>High-level languages such as C do not have an "add with carry"
>operation, so carries need to be implemented with some form of branch.
No. See the C implementation already mentioned.
>The following "bug attack" scenario becomes a possibility:
>[...If your implementation has a bug then it's broken...]
This is vacuously true and not specific to DFC.
>Alternatively an attacker may be able to tamper with an implementation
>[...if an attacker can change your implementation he can break it...]
This is vacuously true and not specific to DFC.
>Conclusion
>
>While not weakening the theoretical basis of the DFC cipher [...]
It sure doesn't!
>it may be impossible to produce a set of standard test vectors which
>validate all parts of the design [...].
You should certainly test all code-paths. This is vacuously true and
not specific to DFC.
However the author is suggesting that it "may be impossible" to test
the rare code-path in DFC.
*** This seems to be the only actual conceivably-valid point. ***
---
However it is false since it is trivial to produce test-vectors that
exercise the rare code-path.
The rare code-path is entered when b < v, where b is a random 64-bit
number and v is small (fits in a byte). However b is calculated as:
rk.lo+"some other stuff". You can freely choose the rk.lo value used
in the first round so that b is any value you like.
Just to prove the point, allow me to demonstrate an example. Pick a
test-vector such as the first one in the C implementation already
mentioned. In the key, set ek[0].lo to zero and stick a printf() in
the round function:
b += l; v += b < l;
> printf("-b = %lu\n", -b);
v *= 13UL;
t = b < v; b -= v;
Run it. It prints:
-b = 16263440665651997398
Now set ek[0].lo to that value and you're done.
---
To be sure of that, you can put a bogus assertion in the rare path:
if (!t) return CP;
> assert(0);
b += 13UL; return CP;
and run it:
-b = 0
rf: Assertion `0' failed.
I think that pretty much demolishes the entire paper.
However power analysis, as discussed in the Daemen and Rijmen paper
for instance, is another matter entirely and I'm not qualified to talk
about it so I won't.
Bye,
Rob.
PS: The average timings of the best DFC implementations I've seen so far are:
Pentium: 609 cycles
StrongARM: 555
Pentium Pro: 392
Alpha 21164: 310
Alpha 21264: 231
and no, there are no bugs in the rare code-paths! =:-)
==============================================================================
Output for dfc() by gcc-2.8.1 -O3, verbatim:
ldq $1,0($19)
ldq $2,8($19)
bis $16,$16,$0
bis $17,$17,$6
lda $8,29850
lda $23,$C33
bis $18,$18,$7
ldah $8,-5276($8)
bis $1,$1,$5
umulh $5,$18,$3
mulq $5,$18,$5
ornot $31,$3,$3
addq $2,182,$7
srl $3,61,$2
cmpule $7,181,$1
s4addq $3,$7,$4
addq $1,$2,$1
cmpult $4,$7,$2
s8addq $3,$4,$7
addq $1,$2,$1
srl $3,62,$2
cmpult $7,$4,$4
addq $7,$3,$7
addq $1,$2,$1
cmpult $7,$3,$3
addq $1,$4,$1
addq $7,$5,$7
addq $1,$3,$1
cmpult $7,$5,$5
addq $1,$5,$1
s4subq $1,$1,$2
s4addq $2,$1,$1
cmpult $7,$1,$2
subq $7,$1,$7
addq $7,13,$28
cmovne $2,$28,$7
lda $22,rt.10
srl $7,58,$1
s4addq $1,$22,$1
ldl $3,0($1)
zapnot $8,15,$8
ldq $1,16($19)
ldq $23,0($23)
srl $7,32,$4
xor $3,$7,$3
ldq $2,24($19)
sll $3,32,$3
xor $4,$8,$4
addq $3,$23,$3
addq $4,$3,$4
bis $1,$1,$5
xor $6,$4,$6
umulh $5,$6,$3
mulq $5,$6,$5
ornot $31,$3,$3
addq $2,182,$7
srl $3,61,$2
cmpule $7,181,$1
s4addq $3,$7,$4
addq $1,$2,$1
cmpult $4,$7,$2
s8addq $3,$4,$7
addq $1,$2,$1
srl $3,62,$2
cmpult $7,$4,$4
addq $7,$3,$7
addq $1,$2,$1
cmpult $7,$3,$3
addq $1,$4,$1
addq $7,$5,$7
addq $1,$3,$1
cmpult $7,$5,$5
addq $1,$5,$1
s4subq $1,$1,$2
s4addq $2,$1,$1
cmpult $7,$1,$2
subq $7,$1,$7
addq $7,13,$28
cmovne $2,$28,$7
srl $7,58,$1
s4addq $1,$22,$1
ldl $1,0($1)
ldq $2,32($19)
srl $7,32,$4
xor $1,$7,$1
ldq $3,40($19)
sll $1,32,$1
xor $4,$8,$4
addq $1,$23,$1
addq $4,$1,$4
bis $2,$2,$5
xor $18,$4,$18
umulh $5,$18,$4
mulq $5,$18,$5
ornot $31,$4,$4
addq $3,182,$7
srl $4,61,$2
cmpule $7,181,$1
s4addq $4,$7,$3
addq $1,$2,$1
cmpult $3,$7,$2
s8addq $4,$3,$7
addq $1,$2,$1
srl $4,62,$2
cmpult $7,$3,$3
addq $7,$4,$7
addq $1,$2,$1
cmpult $7,$4,$4
addq $1,$3,$1
addq $7,$5,$7
addq $1,$4,$1
cmpult $7,$5,$5
addq $1,$5,$1
s4subq $1,$1,$2
s4addq $2,$1,$1
cmpult $7,$1,$2
subq $7,$1,$7
addq $7,13,$28
cmovne $2,$28,$7
srl $7,58,$1
s4addq $1,$22,$1
ldl $1,0($1)
ldq $2,48($19)
srl $7,32,$4
xor $1,$7,$1
ldq $3,56($19)
sll $1,32,$1
xor $4,$8,$4
addq $1,$23,$1
addq $4,$1,$4
bis $2,$2,$5
xor $6,$4,$6
umulh $5,$6,$4
mulq $5,$6,$5
ornot $31,$4,$4
addq $3,182,$7
srl $4,61,$2
cmpule $7,181,$1
s4addq $4,$7,$3
addq $1,$2,$1
cmpult $3,$7,$2
s8addq $4,$3,$7
addq $1,$2,$1
srl $4,62,$2
cmpult $7,$3,$3
addq $7,$4,$7
addq $1,$2,$1
cmpult $7,$4,$4
addq $1,$3,$1
addq $7,$5,$7
addq $1,$4,$1
cmpult $7,$5,$5
addq $1,$5,$1
s4subq $1,$1,$2
s4addq $2,$1,$1
cmpult $7,$1,$2
subq $7,$1,$7
addq $7,13,$28
cmovne $2,$28,$7
srl $7,58,$1
s4addq $1,$22,$1
ldl $1,0($1)
ldq $2,64($19)
srl $7,32,$4
xor $1,$7,$1
ldq $3,72($19)
sll $1,32,$1
xor $4,$8,$4
addq $1,$23,$1
addq $4,$1,$4
bis $2,$2,$5
xor $18,$4,$18
umulh $5,$18,$4
mulq $5,$18,$5
ornot $31,$4,$4
addq $3,182,$7
srl $4,61,$2
cmpule $7,181,$1
s4addq $4,$7,$3
addq $1,$2,$1
cmpult $3,$7,$2
s8addq $4,$3,$7
addq $1,$2,$1
srl $4,62,$2
cmpult $7,$3,$3
addq $7,$4,$7
addq $1,$2,$1
cmpult $7,$4,$4
addq $1,$3,$1
addq $7,$5,$7
addq $1,$4,$1
cmpult $7,$5,$5
addq $1,$5,$1
s4subq $1,$1,$2
s4addq $2,$1,$1
cmpult $7,$1,$2
subq $7,$1,$7
addq $7,13,$28
cmovne $2,$28,$7
srl $7,58,$1
s4addq $1,$22,$1
ldl $1,0($1)
ldq $2,80($19)
srl $7,32,$4
xor $1,$7,$1
ldq $3,88($19)
sll $1,32,$1
xor $4,$8,$4
addq $1,$23,$1
addq $4,$1,$4
bis $2,$2,$5
xor $6,$4,$6
umulh $5,$6,$4
mulq $5,$6,$5
ornot $31,$4,$4
addq $3,182,$7
srl $4,61,$2
cmpule $7,181,$1
s4addq $4,$7,$3
addq $1,$2,$1
cmpult $3,$7,$2
s8addq $4,$3,$7
addq $1,$2,$1
srl $4,62,$2
cmpult $7,$3,$3
addq $7,$4,$7
addq $1,$2,$1
cmpult $7,$4,$4
addq $1,$3,$1
addq $7,$5,$7
addq $1,$4,$1
cmpult $7,$5,$5
addq $1,$5,$1
s4subq $1,$1,$2
s4addq $2,$1,$1
cmpult $7,$1,$2
subq $7,$1,$7
addq $7,13,$28
cmovne $2,$28,$7
srl $7,58,$1
s4addq $1,$22,$1
ldl $1,0($1)
ldq $2,96($19)
srl $7,32,$4
xor $1,$7,$1
ldq $3,104($19)
sll $1,32,$1
xor $4,$8,$4
addq $1,$23,$1
addq $4,$1,$4
bis $2,$2,$5
xor $18,$4,$18
umulh $5,$18,$4
mulq $5,$18,$5
ornot $31,$4,$4
addq $3,182,$7
srl $4,61,$2
cmpule $7,181,$1
s4addq $4,$7,$3
addq $1,$2,$1
cmpult $3,$7,$2
s8addq $4,$3,$7
addq $1,$2,$1
srl $4,62,$2
cmpult $7,$3,$3
addq $7,$4,$7
addq $1,$2,$1
cmpult $7,$4,$4
addq $1,$3,$1
addq $7,$5,$7
addq $1,$4,$1
cmpult $7,$5,$5
addq $1,$5,$1
s4subq $1,$1,$2
s4addq $2,$1,$1
cmpult $7,$1,$2
subq $7,$1,$7
addq $7,13,$28
cmovne $2,$28,$7
srl $7,58,$1
s4addq $1,$22,$1
ldl $1,0($1)
ldq $2,112($19)
srl $7,32,$4
xor $1,$7,$1
ldq $3,120($19)
sll $1,32,$1
xor $4,$8,$4
addq $1,$23,$1
addq $4,$1,$4
bis $2,$2,$5
xor $6,$4,$6
umulh $5,$6,$4
mulq $5,$6,$5
ornot $31,$4,$4
addq $3,182,$7
srl $4,61,$2
cmpule $7,181,$1
s4addq $4,$7,$3
addq $1,$2,$1
cmpult $3,$7,$2
s8addq $4,$3,$7
addq $1,$2,$1
srl $4,62,$2
cmpult $7,$3,$3
addq $7,$4,$7
addq $1,$2,$1
cmpult $7,$4,$4
addq $1,$3,$1
addq $7,$5,$7
addq $1,$4,$1
cmpult $7,$5,$5
addq $1,$5,$1
s4subq $1,$1,$2
s4addq $2,$1,$1
cmpult $7,$1,$2
subq $7,$1,$7
addq $7,13,$28
cmovne $2,$28,$7
srl $7,58,$1
s4addq $1,$22,$1
ldl $1,0($1)
srl $7,32,$2
xor $1,$7,$1
sll $1,32,$1
xor $2,$8,$2
addq $1,$23,$1
addq $2,$1,$2
xor $18,$2,$18
bis $6,$6,$25
stq $18,0($0)
bis $18,$18,$24
stq $25,8($0)
ret $31,($26),1
==============================================================================
------------------------------
From: [EMAIL PROTECTED] (John Hairell)
Subject: Re: KL-7 Cipher machine
Date: 3 Mar 1999 16:33:31 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
>
>[EMAIL PROTECTED] (RREYNARD) wrote, in part:
>
>>I have a photo of the KL-7 Cipher machine that shows a switch on the lower left
>>hand portion of the machine next to the 'typewriter' keyboard. Does anyone know
>>what that switch does or how is it used in the operation of the KL-7?
>
>As far as anyone who knows the answer is concerned, they probably
>would be unwilling to answer the question - the machine hasn't been
>declassified yet. My suspicion is, though, that it's the switch that
>picks "enciphering" or "deciphering" mode.
>
>Actually, there's a KL-7 on display at an Air Force museum -
>
>http://www.afca.scott.af.mil/pa/public/vcphoto5.htm
>
>the photo is clearer than the one at the Haida web site, but there is
>no labelling on the knob.
>
>John Savard (teneerf is spelled backwards)
>http://members.xoom.com/quadibloc/index.html
Actually, several current US military crypto systems have unclassified
operator's manuals. What the operator does with the switches, i.e.
zeroize, initialize, etc isn't necessarily secret, only what goes on
inside the box itself.
John Hairell ([EMAIL PROTECTED])
------------------------------
From: Michael Sierchio <[EMAIL PROTECTED]>
Subject: Re: Computational Complexity
Date: Wed, 03 Mar 1999 08:23:46 -0800
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]>,
> Raul <[EMAIL PROTECTED]> wrote:
> > Does anyone know a good book to learn about Computational Complexity,
> > Algorithmic Complexity, Complexity Classes (P, NP, NP-complete,...),
> > etc...?
> >
> The bible on the subject is:
>
> M. Garey & D. Johnson
> Computers and Intactibility, A Guide to the Theory of Np-Completeness
> W.H. Freeman & Co.
And you must have missed R. Knauer's innumerable posts on Li and Vitanyi's
book, which has an interesting approach to complexity, incl. resource-bounded
complexity:
Ming Li & Paul Vitanyi
An Introduction to Kolmogorov Complexity and Its Applications, 2nd ed.
Springer-Verlag, NY
ISBN 0-387-94868-6
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: sci.crypt.randomness
Date: Wed, 03 Mar 1999 10:34:41 -0600
In article <[EMAIL PROTECTED]>, Somniac <[EMAIL PROTECTED]> wrote:
>
> If randomness enthusiasts want to form a new group, I will
> join it too. I would visit sci.crypt.randomness and contribute.
> If anyone else wants to start it, please sign on now.
Perhaps, those who are looking for real randomness wait on the formation
of such a group to happen without their influence, which speaks to the
real odds against there being real randomness.
This hints about one workable definition of randomness, that which occurs
according to a pattern about which you have no real understandinge, which
in my case is how to form a group dedicated to randomness.
Delving into the situation sufficiently would cause me to understand the
method, which I should blindly ask be done by someone else who is
experienced at that sort of thing; obscurity be the root of lots of
so-called random events, not to forget apathy about wanting to understand
all related mechanics involved. In this case, if the group happens, fine,
and I'll add it to my list, if not, fine, and I'll have a shorter list.
The above random comments were sponsored by Maxwell's Daemon, who seeks to
bring biased order out of utter chaos.
--
A much too common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
From: Craig Inglis <[EMAIL PROTECTED]>
Subject: Blowfish, Snake Oil, and the Osterich Algorithm :-)
Date: Wed, 03 Mar 1999 16:15:49 +0000
Hi there,
Im a newbie at this cryptography game (in fact, Im just a developer with
a passing interest :-), but having done a little research into whats
currently available (3DES,RSA,Blowfish etc) I settled on proposing Bruce
Schneider's excellent Blowfish algorithm (primarily because its 'patent
free' rather than 'better' than anyone elses algorithm, which I couldnt
begin to judge) for encrypting sensitive data in the project I am
involved in.
So, off I go to the next project meeting wanting to talk about
encryption, a subject which seems to bring blank stares from even the
most animated development staff (must be the reputation for 'too much
maths, not enough 3D graphics'). After a short while of me speaking and
noone listening, I was set straight by another developer who pointed out
that the company had already standardised on a proprietary encryption
standard called "the Osterich Algorithm". Not wanting to look stupid, I
left it there and went on to discuss other matters.
So, I scanned the 'net and emailed the guy from the meeting for details
of how this encryption algorithm works and how to implement it, and I
got the following reply...
The Osterich Algorithm...
1) Stick head in sand
2) Hope nothing bad happens
Well, what can I say, you just have to laugh :-)
I just hope marketing doesnt stick details of our advanced "Osterich
encryption" and "ticking box testing" in any sales literature.
I blame whoever started this move away from nice safe
three-letter-acronyms like DES, RSA, etc...
who was that?
ttfn
PG.
------------------------------
From: [EMAIL PROTECTED] (Elmar)
Subject: How can decrypt this file?
Date: Wed, 03 Mar 1999 18:38:12 GMT
Reply-To: [EMAIL PROTECTED]
Hi!
Could you please help me?
Can you please tell me, what's in this file and what does it say after
decrypted. Which program has been used?
The url is http://www.formfactory.com/unknown.txt
The original filename was: unknown.txt.$#!
Please email it to [EMAIL PROTECTED]
Thaaaaaaaaank you very much :))
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Testing Algorithms
Date: Wed, 03 Mar 1999 12:28:58 -0600
Herman Rubin wrote:
> It is technological, but technology is limited by physics. Even in
> liquid Helium, there is a "zero-point" energy level, and the noise
> from this must be overcome. I believe we are approaching physical
> limits; can we make a storage device smaller than a molecule? The
> energy needed to switch from one state to another cannot be made too
> low, or there will be spontaneous switching; this is a problem
> already in high density read-write storage devices.
We can suppose that Rydberg states are possible. then we have storage
the size of single atoms, and each atom may have many states. This
is not really achievable with todays technology, but it's the upper
limit that physics allows us to imagine. If it were possible to
get 16 Rydberg states (and keep them stable!!!!!) then we have 4 bits
per atom. That should make the calculations interesting.
> I am not sure what comes from the uncertainty principle applied to
> the energy-time situation; the product of the uncertainties in energy
> and time is also at least the normalized Planck constant. There have
> been estimates due to quantum uncertainty; I believe that these are
> far too low, because of the energy problems of maintaining stability,
> and the size of the devices needed.
Agreed. But let's assume we only need to change the state of an
electron in an outer shell, the energy needed is on the order of
milli electron volts. Totally impossible to do (today) but let's
use it again as a physical limit.
> The size limitations I am thinking of are on the order of those of a
> single molecule, or the interatomic distances in a crystal. These
> are in "hailing distance", a factor of not too high a power of 10,
> of what we now have. The "present rate" of increase of speed will
> hit this in less than a century. I can see DNA-like molecules
> enabling the production of such sized units, and these are now in
> the foreseeable future.
And going down to the single atom with multiple states is again
a factor of 10. That's only 3 doubling times or 4.5 years.
> Even just using the quantum limitations does not get too far. To do
> better than this, there will have to be stable "sub-quantum" states.
Which is dreamable, but it still doesn't help much. 2^256 is too
big to comprehend in the real world. The fact that computers are
in their infancy compared to most other technologies is the only
reason things are still accelerating. We will hit real physical
limits one of these days. And when we do, 2^256 will *still* be
too big to deal with.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Analysis
Date: Wed, 03 Mar 1999 10:51:56 -0600
In article <7bjg4f$26i$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> I posted my algorithm a couple of days ago, but I really need some feedback.
> I appreciate those who have responded already. I would like to what people
> think about it's weakness's and strengths. I already have a feel for it, but
> I don't want to be foolish. Here is how my algorithm works:
>
> 1) Take a key of 65536 bits (8KB) Key1 is the first 4KB, key2 is the second
> 4KB
> 2) Calculate an Adler (Mark, Adler) of the first 4KB using a modulus of 4093.
> Call this L
> 3) Calculate an Adler of the second 4KB using a modulus of 4093, call this S.
>
> 4) Get a symbol. To encrypt/decrypt you XOR it with Key1[L] XOR Key2[S]. 5)
> Calculate new L and S values. (See the source please). Basically I sum up
> different values around L, S and c (plaintext). 6) Loop as required.
A stream cipher....
>
> I think the strength is in finding new S and L values. I would like to try
> using an Adler to calculate the new L and S values instead, so they are
> order/ value dependant.
A data dependent stream cipher...
> As is I think it is pretty strong. It's weaknesses
> come from having to find a good 8KB file for a key. Although using
> photos/sounds would suffice.
>
Keys can be made from anything. I would assume that a picture of a blank
blue screen would be a bad one, or a pure tone. Text is much more
variable; getting bits equal to the number of characters could allow for
langauge redundancies to be fairly well suppressed. Or, back to your
preferences, one of a carpet square has been suggested, or a recording of
white noise; text is easier to get.
--
A much too common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
From: [EMAIL PROTECTED] (Guenther Brunthaler)
Subject: Re: Testing Algorithms
Date: Wed, 03 Mar 1999 19:02:20 GMT
On 22 Feb 1999 10:42:56 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>The fact that doomsayers have been predicting physical limits to the
>maximum speed of computers for 20 years now, and the successive violation
>of these physical "limits" has become routine.
I absolutely do agree.
It MAY be incorrect to project Moore's Law on the years to come, but
actually nobody can be sure.
Quantum computers may just be one of many alternatives to the hardware
concepts used today, and so nobody can be sure whether it is correct
to use just the number of paricles in the universe as an upper limit
to the computing power that may be possible.
In addition, no-one actually KNOWS the exact dimensions and structure
of the universe, so any limiting formulas based on such assumptions
are also nothing but assumptions.
I once had projected Moore's Law to the assumed time the universe has
left until the next big bang (provided this theory describes the
truth), and came to a minimum (symmetrical) key size of just about 4
gigabytes.
Of course, some will argue that no-one will ever spend even a fraction
of the necessary effort on cracking my messages - and they will very
likely be right.
However, I *WANT* my messages to be secure, no matter how important
they are or not - I simply don't want to care after encrypting, who
may or may not crack it.
And so I will only be pleased as soon as I will be VERY confident,
that not even GOD himself will be able to crack my message!!!
(Interesting question: How to assess the computing power of GOD,
provided he, she or it exists? But even if god does not yet exist, I'm
confident god will eventually be created as the end-product of
evolving artificial intelligences - so to say a computer as large as
the universe itself. He's not gonna have a white beard then very
likely, however! :-)
Greetings,
Guenther
--
Note: the 'From'-address shown in the header is an Anti-Spam
fake-address. Please remove 'nospam.' from the address in order
to get my real email address.
In order to get my public RSA PGP-key, send mail with blank body
to: [EMAIL PROTECTED]
Subject: get 0x2D2F0683
Key ID: 2D2F0683, 1024 bit, created 1993/02/05
Fingerprint: 11 71 47 2F AF 2F CD F4 E6 78 D5 E5 3E DD 07 B5
------------------------------
** 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
******************************
