Cryptography-Digest Digest #927, Volume #9 Fri, 23 Jul 99 00:13:03 EDT
Contents:
Current export laws ([EMAIL PROTECTED])
Re: Traffic Analysis (wtshaw)
Re: How Big is a Byte? (wtshaw)
Re: Compression for encryption ("Douglas A. Gwyn")
Re: How Big is a Byte? (was: New Encryption Product!) ("Douglas A. Gwyn")
Re: ElGamal in Applied Cryptography (Doug Stell)
Re: Length of public key in PGP? ([EMAIL PROTECTED])
Re: Length of public key in PGP? ([EMAIL PROTECTED])
Re: How Big is a Byte? (was: New Encryption Product!) ([EMAIL PROTECTED])
White page on Thermal noise (Drew Cutter)
Re: ElGamal in Applied Cryptography ([EMAIL PROTECTED])
Re: Storing encrypted passwords (Dmitri Alperovitch)
Re: another news article on Kryptos (Terry Ritter)
Re: yet more about fibo generators (Terry Ritter)
Re: Q: Does ElGamal require that (p-1)/2 is also prime like DH?
([EMAIL PROTECTED])
Re: How Big is a Byte? ("Douglas A. Gwyn")
Eurocrypt '94 Papers ([EMAIL PROTECTED])
Re: What the hell is XOR? (Stephen C. Gilardi)
Re: Kryptos Beginning of publicatio of solution ("Douglas A. Gwyn")
Re: another news article on Kryptos ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Current export laws
Date: Thu, 22 Jul 1999 17:51:38 -0400
Does anyone know where I can find the current export laws for
cryptography? (It's not like I'm gonna follow them anyway. =] )
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Traffic Analysis
Date: Thu, 22 Jul 1999 17:36:44 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> On Mon, 19 Jul 1999 15:41:36 GMT, Roger Carbol <[EMAIL PROTECTED]> wrote:
>
...
> >Has anyone set up a system (that they can talk about) which regularly
> >sent out a lot of noise? Any interesting phenomena arise?
>
> I believe we call it Usenet ;).
>
> Maybe someone is exchanging top secrets here in some kind of code via lots
> of conversations. Who knows, it may explain some people's speeling
> mistakes...
>
> Instead of sending noise one could send the Usenet newsfeed processed the
> same way as the real messages would be.
>
> I figure "real" noise may be more easily differentiated from real messages.
>
Real noise is sorta like true randomness. Artificial noise is like
randomness created to pass someones standards for randomness. In short,
noise is only a departure for reality as randomness is only a departure
from order. In cryptography, it seems more important to manage noise and
random apperance to assist in misleading, than to seek either as something
you can capture and hold, which you can't. Noise and randomness are both
fought through redundancy.
--
Real Newsreaders do not read/write in html.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte?
Date: Thu, 22 Jul 1999 17:29:06 -0600
In article <[EMAIL PROTECTED]>, Ian
Stirling <[EMAIL PROTECTED]> wrote:
>
> Hence, in base 1, the number
> "11111" is equal to 5, "111 11" is also equal to 5, as is "111011"
11111 is not a base 1 number, but it is equal to 63 in base 2, of course.
Marks, tallys, strokes, all imply a + between each pair of adjacent figures.
>
> Aside: The transputer had a "count ones" instruction, which was very handy
> for decoding spread spectrum transmissions.
>
> Also, "292028280282920" is not a sensible way to represent several numbers,
> as there is no way to discover which is which, there needs to be some
> way to indicate the end of a number. This is obviously not the same as
> zero.
Yes, representations should be appropriate as well as adequate. Being
inadequate is also inapproprate.
The biggest mistake in all of this discussion is the consistent tendency
for some to see all strings of symbols that look like numbers to be so.
In a cryptographic sense, manipulationing these types of characters may or
may not be directly according to a mathematical formula involving them as
values, but as substitutions echoing some permutation or other in
substitution and/or transposition.
I can assure that words in normal usage are simply words, but after
cryptographic processing, they sometimes can look like numbers, whether
they need to be or not. In treating words like numbers, making them have
real numerical values does not mean that their essence was as numbers in
the first place.
So many symbols in such and such order may actually mean something, they
in may mean nothing, or a combination of these. This is one mystery that
cryptography plays with: Nulls are obstacles to be avoided, nonessentials
to the transmission of information, merely noise to be systematically
discarded, but to render confusion in the minds of those not supposed to
receive.
--
Real Newsreaders do not read/write in html.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Compression for encryption
Date: Thu, 22 Jul 1999 16:14:29 GMT
"SCOTT19U.ZIP_GUY" wrote:
> No as a matter of fact most compression routines do not make a
> random file smaller. If any thing they in general make a random file
> longer.
Indeed, it is easy to *prove* that any lossless general compression
technique that makes even one file smaller *must* make at least one
file larger.
------------------------------
Crossposted-To: alt.folklore.computers
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Thu, 22 Jul 1999 16:11:46 GMT
wtshaw wrote:
> It does not matter which system you use as long as you and whoever you
> are communicating with are on the same track.
That's the essential point. Also, the system needs to be consistent.
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: ElGamal in Applied Cryptography
Date: Thu, 22 Jul 1999 23:28:46 GMT
On 22 Jul 1999 19:09:05 -0000, "Jonathan 'Wolf' Rentzsch"
<[EMAIL PROTECTED]> wrote:
> // "The pair, a and b, is the ciphertext. To decrypt a and b compute:
> // M = b/a^x mod p"
> M2 = b / ( exp( a, x ) % p ); // M2 == 1
Here's a common mistake. "/" does not mean divide, as division is not
defined in finite field math.. It really means "multiply by the
multiplicative inverse of..." You must find the inverse a^x mod p
using the Extended Euclidean Algorithm and then use that in a
multiplication. Schneier explains this on page 246.
doug
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Length of public key in PGP?
Date: Thu, 22 Jul 1999 20:03:37 -0400
> Actually, I don't quite know what a session key is exactly nor how it
> works. But I'd be happy to know. :)
Instead of using RSA to encrypt a file (which for a large file can take
FOREVER and a day) you use a hybrid (sp?) system in which you use both RSA
and a symetric algorithm to encrypt the file. For example, let's say you
were encrypting a file to a friend's public key. You would first select a
symetric algorithm (I perfer blowfish b/c of it's 448 keysize and speed).
When you go to encrypt a file, you generate a *RANDOM* key. Being sure to
use a really good random number generator. You then encrypt the file with
the symmetric algorithm using the random key (called a session key). Then
you encrypt the session key to the recipiant's public key. You send the
encrypted session key along with the encrypted text. Decryption is just the
inversion of this process. You decrypt the session key with the user's
private key, and then use the session key with the symetric algorithm to
decrypt the text. A few notes about rsa though:
1) If you ever sign a file with it, allways sign the HASH of a file...never
the file itself.
2) If you decide not to use the hybrid system, be sure to compress the
plain text before encrypting (it's a good idea to encrypt anyway).
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Length of public key in PGP?
Date: Thu, 22 Jul 1999 23:32:19 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> To tell you the truth, I have never thought of that. I have allways
used
> RSA to encrypt session keys that are too small to overflow the limit
(the
> session keys are then used to encrypt the message with a symmetric
> algorithm, such as blowfish or idea).
Why do you want to encrypt the session keys? To make them longer so that
harder to hack out? What not just use a hash function, then?
Actually, I don't quite know what a session key is exactly nor how it
works. But I'd be happy to know. :)
Thanks.
Weedlet
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
From: [EMAIL PROTECTED]
Date: Thu, 22 Jul 1999 22:59:49 GMT
On 1999-07-22 [EMAIL PROTECTED] said:
:> In article <7n58s3$q0s$[EMAIL PROTECTED]>, Finder Keeper
:>wrote: >But zero isn't the first number. It's the zero-th number.
:> It's the zeroth number, but because zero is the number with which
:>we start counting, the zeroth number is the first number of
:>counting, which makes zero the first number.
:These young C programmers and their delusions. Fortran programmers,
:of course, know that 1 is truly the first number.
Whereas Algol programmers are perfectly aware that the first number can
be anything you please.
--
xian the desk lisard time's taught the killing game herself
------------------------------
Date: Thu, 22 Jul 1999 20:30:43 -0400
From: Drew Cutter <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: White page on Thermal noise
Looking for white paper or url on intel use of thermal noise for
hardware base random number generator.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: ElGamal in Applied Cryptography
Date: Fri, 23 Jul 1999 00:36:31 GMT
"Jonathan 'Wolf' Rentzsch"
> I am attempting to implement ElGamal public
key
> encryption,
[...]
> Where am I going wrong?
[...]
> // "The pair, a and b, is the ciphertext. To decrypt a and b
compute:
> // M = b/a^x mod p"
> M2 = b / ( exp( a, x ) % p ); // M2 == 1
The expression in Schneier refers to arithmetic
modulo p. "b/a^x mod p" means b times the inverse
of a^x modulo p. Ordinary division won't work.
I'll do the same computation in Python below
--Bryan
def inverseGcd(u, v):
"""Return x and d such that u*x mod v == d == GCD(u, v)."""
u1, v1 = 1, 0
while v>0:
u, (q, v) = v, divmod(u, v)
u1, v1 = v1, u1 - v1*q
while u1<0: u1 = u1 + v
return u1, u
def inverse(u, v):
"""Returns the mod v inverse of u."""
(result, gcd) = inverseGcd(u, v)
if gcd != 1:
result = None
return result
# Values from Wolf's post
p = 23
g = 4
x = 3
m = 9
k = 5
y = pow(g, x, p)
print "y =", y
a = pow(g, k, p)
print "a =", a
b = pow(y, k, p) * m % p
print "b =", b
m2 = b * inverse(pow(a, x, p), p) % p
print "m2 =", m2
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Dmitri Alperovitch)
Subject: Re: Storing encrypted passwords
Date: Fri, 23 Jul 1999 00:59:08 GMT
>I develop commercial software, but I know
>very little about encryption. I need to
>provide ftp services within my App, and I would
>like to store login information in a secure
>fashion. The following criteria is absolutely
>necessary:
>[1] Adhere to US export laws.
>[2] Do not violate patents/copyrights.
>[3] Still provide reasonable security.
I really don't see how it's possible to encrypt a password
that is needed to be later decrypted by the program in a "secure
fashion". If the program can somehow do it, then the algorithm
can be reversed. (so if you decide to store the keys somewhere
in the program or elsewhere, you can't call that 100% secure)
The only thing that you can do is store a hash (like MD5)
of the password, but that only works for a situation where you
need to check the password against the one that the user enters.
Regards,
Dmitri
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: another news article on Kryptos
Date: Fri, 23 Jul 1999 01:12:36 GMT
On Wed, 21 Jul 1999 14:30:41 GMT, in <[EMAIL PROTECTED]>, in
sci.crypt "Doug Gwyn (ISTD/CNS) <gwyn>" <[EMAIL PROTECTED]> wrote:
>[...]
>But "switching algorithms" under control of a key is itself
>a fixed algorithm, just more complex than its components.
Note that this statement is not true if the algorithm set keeps
expanding, because then the algorithm is certainly *not* fixed.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: yet more about fibo generators
Date: Fri, 23 Jul 1999 01:12:41 GMT
On Thu, 22 Jul 1999 12:11:22 GMT, in <7n71p4$pld$[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Terry Ritter) wrote:
>>
>> On Wed, 21 Jul 1999 21:37:28 GMT, in <7n5eim$919$[EMAIL PROTECTED]>, in
>> sci.crypt [EMAIL PROTECTED] wrote:
>>
>> >Getting loads of information about the generators ( :( ) I decided to
>> >look into it myself. I found some interesting information though...
>> >
>> >The period of Additive Generators is the same as LFSR generators.
>>
>> False. See, for example:
>>
>> http://www.io.com/~ritter/ARTS/CRNG2ART.HTM#Sect7.2.4
>
>Yeah but doesn't each bit have it's own period?
Yeah, so?
>> Additive RNG periods actually have been known for well over a decade:
>>
>> 114. Marsaglia, G. and L. Tsay. 1985. Matrices and the Structure of
>> Random Number Sequences. Linear Algebra and its Applications. 67:
>> 147-156.
>
>For the entire word output yes because we assume the period of the
>msb. But my point is that other bits have other periods...
Additive RNG's differ from conventional LFSR's largely in having
multiple bits per element. Saying "Additive RNG" pretty much implies
the use of multi-bit quantities. The correct expression for Additive
RNG length reduces to LFSR length for one bit widths. And, knowing
that carries can only affect bits to the left, that value obviously
remains correct even when more bits are added to the left. That does
not make "The period of Additive Generators is the same as LFSR
generators" a true statement.
>> If you cannot find this information in your favorite crypto books,
>> perhaps you should complain to the authors.
>
>Or in my case move to another city :)
How does that reveal to the authors that their work is deficient? How
does that teach you to judge the quality of a work, as opposed to
hype?
>>
>> For one thing, you are missing an explicit definition of what you
>> imagine "dense LFSR generators" to be.
>>
>> If you mean "LFSR's having many feedback taps," they are no stronger
>> than LFSR's with few taps. Both are linear mechanisms and if we know
>> the taps, their unknown state can be computed when we have that same
>> amount of known plaintext (or, of course, more).
>
>Then why are spare generators (See the PIKE paper) feared? If dense
>generators are no better that will make life much simpler.
Since I don't fear them, asking me why they are feared is not
particularly useful. Maybe you need to ask the authors of the
reference you cite.
There can be reasons to use more than the typical trinomial (and I
have often advocated 9-nomials), but those reasons do not include
making the recovery of internal state more complex.
>> I have long advocated and used a nonlinear filtering system after the
>> RNG proper. The particular design I use I call a "jitterizer." One
>> description is available in:
>
>Question: Is the give/take register a counter or fixed?
Answer: No.
>Question: Is this generator quick?
Sure.
>My simple 'delay[rnga()] += rngb()'
>(delay is a array of 256 bytes, rnga and rngb are additive generators
>with two taps).
But your "delay" seems to be the old MacLaren-Marsaglia (Knuth II
Algorithm M) thing which is known to be weak. Who cares if it is
simple?
My jitterizer scheme skips or drops out parts of the sequence -- the
skipped data are simply not present, and are thus not available to
analysis -- and then provides a random offset for each contiguous
sub-sequence which remains. And that is *not* known to be weak.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Q: Does ElGamal require that (p-1)/2 is also prime like DH?
Date: Fri, 23 Jul 1999 01:02:29 GMT
Hartmut Schroeder wrote:
> Hi,
> while reading "Applied Cryptography" it is mentioned that
> ElGamal and Diffie-Hellman are based on the same mathematical Problem.
True. It's now widely referred to as "the Diffie-Hellman
problem".
> It is also said that prime p you choose for Diffie-Hellman
> has also to be a prime when you compute (p-1)/2.
That's a recent addition not found in the original
papers of D-H and ElGamal. You want to use a base
that is a generator for a subgroup of order (p-1)/2.
This resists the Pohlig Hellman discrete log
algorithm and an active attack (which I think is
also due to Pohlig and Hellman).
> It would take a while to find great Primes that meet this criteria.
Yes, but still quite practical, and you only have to
do it once. If it takes too long in your application,
you can consider using the same p for multiple parties,
or relaxing the prime (p-1)/2 criteria to (p-1)/(2r)
is prime for some small r (in the millions seems fine
and such numbers are about as fast to find as raw
primes).
> The Book seem nothing to say in the ElGamal Section that this
> is also true for prime p when using ElGamal.
You want a p-1 that has a large prime factor, and use
a generator of that order. That will resist the P-H
discreet log algorithm, and the active attack doesn't
apply against a signature algorithm.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte?
Date: Fri, 23 Jul 1999 02:44:08 GMT
Ian Stirling wrote:
> Hence, in base 1, the number
> "11111" is equal to 5, "111 11" is also equal to 5, as is "111011"
In base one, if the notation is to be perfectly consistent with that
used for higher (integer) bases, the only available digit is "0",
and thus the only value expressible is precisely zero. However, you
can adjust the rules for this borderline case and use tally marks,
so long as you're prepared to use an empty string to represent zero.
Strictly speaking, this is cheating.
------------------------------
From: [EMAIL PROTECTED]
Subject: Eurocrypt '94 Papers
Date: Fri, 23 Jul 1999 02:19:05 GMT
I've spent the past hour or so trying to find a paper from Eurocrypt '94
online. If anyone knows where I can find L. Chen and T.P. Pedersen's
"New Group Signature Schemes" paper online, please let me know.
Also, if you know of any other papers/site online about group
signatures, please let me know.
Thanks in advance,
Coda
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Stephen C. Gilardi)
Subject: Re: What the hell is XOR?
Date: 22 Jul 1999 20:32:07 PDT
John Savard <[EMAIL PROTECTED]> wrote:
> Well, XOR is just the binary version of "false addition". 0+0=0,
> 0+1=1+0=1, and 1+1=0 instead of two (10 in binary).
I sometimes find it useful to think of an XOR operation as a "Controlled
Inverter".
Consider a black box called a "Controlled Inverter" with two binary
inputs and a binary output.
+-----+
DATA_IN ----| |
| |---- DATA_OUT
INVERT ----| |
+-----+
The inputs are DATA_IN and INVERT, and the output is DATA_OUT. Here are
the specifications for the black box's operation:
If INVERT is 0, DATA_OUT is the same as DATA_IN.
If INVERT is 1, DATA_OUT is the inverse of DATA_IN.
Here's the truth table for that:
DATA_IN INVERT DATA_OUT
0 0 0
0 1 1
1 0 1
1 1 0
That's the same as the truth table for "C = A XOR B" where A is DATA_IN,
B is INVERT, and C is DATA_OUT.
The black box in question has exactly the same function as an XOR gate.
An XOR gate (or an XOR operation) is a controlled inverter.
Thinking of it as a controlled inverter makes it easy to see why it is
its own inverse.
Repeating the operation twice sequentially (with the same value of
INVERT) either inverts the input twice (resulting in an output the same
as the input) or inverts the input 0 times (resulting in an output the
same as the input).
--Steve
--
Stephen C. Gilardi
SQ Software
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Kryptos Beginning of publicatio of solution
Date: Fri, 23 Jul 1999 02:49:15 GMT
collomb wrote:
> The decoding of KRYPTOS step by step ...
For Chrissake, the bulk of Kryptos has been *independently* solved
by three separate parties working without communicating with one
another, and they all got the same, highly coherent messages, which
employ known classical methods of encryption and no "judgment calls",
for the answer, and this is easily verified. If you get a different
answer, then yours is malarkey.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: another news article on Kryptos
Date: Fri, 23 Jul 1999 03:00:04 GMT
Terry Ritter wrote:
> Note that this statement is not true if the algorithm set keeps
> expanding, because then the algorithm is certainly *not* fixed.
If you can actually implement it, it certainly is.
------------------------------
** 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
******************************
