Cryptography-Digest Digest #228, Volume #9 Fri, 12 Mar 99 19:13:03 EST
Contents:
Re: DES => problems with decryption - des.h (0/1) (Mycroft)
Re: DIE HARD and Crypto Grade RNGs. (R. Knauer)
Re: CD Cipher (John Savard)
Re: Crypto transmission in noisy ambient (John Savard)
Re: CD Cipher (R. Knauer)
Re: CD Cipher (R. Knauer)
Re: Crypto transmission in noisy ambient (wtshaw)
Re: Really Nonlinear Cipher Idea (wtshaw)
SHA algorithm (iLLusIOn)
Re: Certicom Benchmark (Medical Electronics Lab)
Re: Finite Field with Hard Division? (Guenther Brunthaler)
Re: SHA algorithm (Jim Gillogly)
Re: Quantum Computation and Cryptography (Bill Unruh)
Re: Are there free RSA Software lib's ? (Bill Unruh)
Re: Are there free RSA Software lib's ? (Bill Unruh)
Re: Are there free RSA Software lib's ? (Bill Unruh)
Re: Does RC4 have the same problems as OTP? (Bill Unruh)
----------------------------------------------------------------------------
From: Mycroft <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.forth
Subject: Re: DES => problems with decryption - des.h (0/1)
Date: Fri, 12 Mar 1999 13:00:50 -0600
Jim Gillogly wrote:
> Moh wrote:
> > Still the whole process does not function at all
> > and I am really desperate now :-(
>
> What you need is more test data to see where the problem is coming
> in. I suggest you get one of the numerous public domain DES
> implementations and decorate it with some printfs to compare with
> the comparable data in your own program.
>
> Debugging 101 -- welcome to computing!
When I implemented a DES function in Forth I found the book
"The standard data encyption algorithm" by Harry Katzan Jr.
to be an invaluable tool. It implements DES in APL. But the
good part is that it has a complete trace of one run of a DES
encryption/decryption. It gives you a trace of the bitwise output
from each function. Forth was nice from this respect because
I could easily check each function step easily. The same can
probably be said for APL, though I've never used that language.
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: Fri, 12 Mar 1999 20:15:41 GMT
Reply-To: [EMAIL PROTECTED]
On 12 Mar 1999 14:09:29 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>why does a triangle have only three sides?
Could it be the prefix "tri" perhaps?
Naw.
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: CD Cipher
Date: Fri, 12 Mar 1999 20:14:06 GMT
[EMAIL PROTECTED] (R. Knauer) wrote, in part:
>According to the authors, this is the best of two worlds, since it
>prevents both block cipher attacks and stream cipher attacks. As they
>point out, block cipher attacks work because they use only one key,
>which is no longer the case here. Stream cipher attacks work because
>of additive mixing, which is no longer the case here.
I think it's a good idea, although I'd still want to use a strong stream
cipher and a strong block cipher: but it is true that an idea good enough
to result in a strong cipher even if those components are weak is,
therefore, a good idea.
I remember discussing something like this a while back, in posts entitled
"My Large-Key Brainstorm", so, naturally, I'm biased in favor of the idea.
John Savard (teneerf is spelled backwards)
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Crypto transmission in noisy ambient
Date: Fri, 12 Mar 1999 20:20:25 GMT
"F. Arndt" <[EMAIL PROTECTED]> wrote, in part:
>but are there clever ways of making the
>process distinctly more efficient for a given bit error rate (BER)?
Two ways:
1) Divide the message into many short blocks (after encryption), and use
error-correcting codes on each one, so that errorless transmission is
usually achieved, and small blocks of ciphertext only get retransmitted if
necessary.
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.
John Savard (teneerf is spelled backwards)
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: CD Cipher
Date: Fri, 12 Mar 1999 20:37:20 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 12 Mar 1999 20:14:06 GMT, [EMAIL PROTECTED]
(John Savard) wrote:
>I remember discussing something like this a while back, in posts entitled
>"My Large-Key Brainstorm", so, naturally, I'm biased in favor of the idea.
Well... don't keep us in such suspense. What is it?
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] (R. Knauer)
Subject: Re: CD Cipher
Date: Fri, 12 Mar 1999 21:04:57 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 12 Mar 1999 20:14:06 GMT, [EMAIL PROTECTED]
(John Savard) wrote:
I undoubtedly butchered the authors' presentation of the actual system
as they intended. Here is the exact text:
+++++
The cooperatively distributed ciphering system consists of s
components: s conventional block ciphers of the same block length, and
a control device which is a sequence generator with internal memory,
SG for short, which produces sequences over the alphabet Zs =
{0,1,...,s}.
Let K0, ..., Ks-1 be the keys respectively; E0(K0, . ), ...,
Es-1(Ks-1, . ) the encryption transformations by the specified keys;
D0(K0, . ), ..., Ds-1(Ks-1, . ) the decryption transformations
specified by the keys respectively. Let Ksg be the key of the sequence
generator, z_i be the output character of the SG at time i. The key of
the CD Cipher system is K = (Ksg, K0, ..., Ks-1). At each time unit
only one of the block ciphers is active, i.e., doing the encryption
(respectively decryption). So we have
Ci = Ez_i(Kz_i, Mi),
where Mi and Ci are the ith plaintext and ciphertext block. Similarly,
the decription is defined by
Mi = Dz_i(Kz_i, Ci).
In this CD Cipher system the SG determines the action of each
component block cipher, and it is possible for the encryption
algorithms E0, ..., Es-1 to be the same, but in this case the keys K0,
...., Ks-1 should be pairwise different.
+++++
The authors go on to discuss the security of the system, which they
rate as very strong. Later they discuss the two block system I alluded
to earlier.
+++++
It is important that the two block ciphers should have many
similarities, just like "twins". This indicates that using only a
two-key cooperation within one well-designed algorithm seems better,
but in this approach one has to guarantee that the two keys do not
specify the same encryption transformation; otherwise there is no
cooperation within the system.
+++++
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] (wtshaw)
Subject: Re: Crypto transmission in noisy ambient
Date: Fri, 12 Mar 1999 16:17:50 -0600
In article <[EMAIL PROTECTED]>, "F. Arndt"
<[EMAIL PROTECTED]> wrote:
> A low-power but strongly encrypted (RSA or ElGamal) exchange in the
> presence of noise AND interference, such as often prevails in wireless
> comm, would seem to be problematical. The conventional approach of
> retransmitting until check-sums or CRC are satisfied is probably
> standard operating procedure, but are there clever ways of making the
> process distinctly more efficient for a given bit error rate (BER)?
The ancient means of getting a message through a noisy link are redundancy
(repetition), and lower baud rate (doing things slower). Central is the
notion of Bandwidth, where a narrower signal is more easily filtered, and
in the case where I was doing so, more easily tracked with something like
a phase-locked loop filter.
Begin with a passive filter to handle overloading pulses, add simple
boosting, prefer two or three stages of darlingtons, add a couple of
stages of active filters, then to something appropriate, even as simple as
a LM567 circuit, probably something more sophistocated like an XR or
contemporary part. Key is to make the PPL circuit sluggish enough to lose
the noise. Don't forget to chase this whole thing with a clean, but
softened readjustment stage to put a glitchless at TTL levels.
I was quite successful in transmitting bidirection telemetry at 300 baud
through a 30-35 dB bidirectional lossy phone line, plus subaudible and
other versions. Regardless of what area of specturm, the principles are
the same, but pick out a pointed hat, to help complete the best design.
Hint, commercial specifications of parts are often incomplete and
inadequate.
Now, do your error checking.
--
Security efforts for an insecure platform are apt to be about as effective as
waterwings on a snake.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Really Nonlinear Cipher Idea
Date: Fri, 12 Mar 1999 15:55:57 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
>
> The ciphertext *does* include everything needed to reconstruct the "unique
> path", but protected by the key to the f-function.
>
Hiding instuctions in ciphertext is both doable and a good idea. The
means of doing such are apt to grow in number. Accepting that something
cannot be done is the easiest path to excuse one from the opportunity to
try to do it.
--
Security efforts for an insecure platform are apt to be about as effective as
waterwings on a snake.
------------------------------
Date: 12 Mar 1999 22:58:10 -0000
From: iLLusIOn <Use-Author-Address-Header@[127.1]>
Subject: SHA algorithm
=====BEGIN PGP SIGNED MESSAGE=====
Hi,
in the book Applied Cryptography, Bruce Schneier describes the SHA
algorithm like that:
"First the message is padded to make it a multiple of 512 bits long.
Padding is exactly the same as in MD5: First append a one, then as
many zeros as necessary to make it 64 bits short of a multiple of
512, and finally a 64 bit representation of the length of the message
before padding."
what I don't understand is what I should do if the message is 488 bits
for example. The space left (512 - 488 bits) is not enough to store the
64 bits which represent the original message length.
How do messages with such a size get padded to 512 bits?
TIA!
//iLLusIOn
~~~
This PGP signature only certifies the sender and date of the message.
It implies no approval from the administrators of nym.alias.net.
Date: Fri Mar 12 22:58:08 1999 GMT
From: [EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: 2.6.2
iQEVAwUBNumcAk5NDhYLYPHNAQHPjgf/XjjFUJtb9D7qUrJMsIx9M0fUW48FoS3T
S94TNBHIQJWeWYMsH2l31N3B6wzqmd/2HOyxpJcoN3XnqKdtqau2RkxnrHHPUuKU
duveEUjbQfk4JmBYJU1Vu3qbq562Scu5XV/Tfm5/D1HI3pYGfdk/vnJnIWnaTSXn
wjov2pnc5GVT7hsbn5+O3zJDuJqji4yD/P4IQS+CWA1V5cB7Ux8QGiyJHu4ZaRLa
nVU6WhG5m6Z9rOFr2mNJHdqxzIQODpV8Unl5p1RIzghqlgjawfM8SvVMPBUVqWfM
Co5vPG30SsoLWhxorD3wmUixdgq+uridIKJ6HRcqmY9qF0jhGbU05Q==
=hOiR
=====END PGP SIGNATURE=====
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Certicom Benchmark
Date: Fri, 12 Mar 1999 16:55:09 -0600
Michael Scott wrote:
> Key generation 1024-bit DH - 91.67ms (14ms)
> Shared secret 1024-bit DH - 108.33ms (17ms)
> Key generation 2048-bit DH - 611.67ms (65ms)
> Shared secret 2048-bit DH - 728.33ms (80ms)
>
> As you can see the differences are highly significant. It is suggested in
> the text that standard DH benefits from the use of the Pentium Pro
> co-processor. It doesn't, and I didn't use it.
What we have to do is compare the same machines with similar
code. All the comparisons should show ECDH to be faster simply
because the field size is smaller.
>
> When I commented on these benchmarks before, I was surprised that even
> someone as knowledgable as our own patient, persistent and truthful Dr, mike
> was apparently happy to take them at face value. But to do so would in my
> opinion be a mistake.
I agree. Let's to a real test, on the same machine run the two
codes side by side. Anything else won't mean much.
> For a well-balanced comparison see Michael Weiner's article "Performance
> comparison of Public Key Cryptosystems" in RSA labs Cryptobytes, Vol. 4, No.
> 1, 1998 from www.rsa.com
> After a thoughtful analysis he gives some results (also from a Pentium
> 200MHz) which indicate that certain EC methods are about 50% faster when
> comparing DSA (1024-bits) with ECDSA (168 bits). He states that DH and ECDH
> are comparable speed-wise - which flatly contradicts Certicom's claims. He
> also makes the interesting observation that software implementations of
> Elliptic curves over GF(2^m) appear to be slower than those over GF(p), but
> accepts that reports differ on this.
I find it hard to believe, but I've been wrong before. GF(2^m) is
so much simpler than GF(p) in terms of basic operations that it ought
to be faster.
I'll be happy to help you set up a test between the two on your machine.
Send me e-mail at [EMAIL PROTECTED] and we can put some code
together that will do a nice test for posting up here.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Guenther Brunthaler)
Subject: Re: Finite Field with Hard Division?
Date: Fri, 12 Mar 1999 20:31:14 GMT
On Thu, 11 Mar 1999 04:31:02 GMT, [EMAIL PROTECTED] (Peter L.
Montgomery) wrote:
> If the field has q elements, then x^q = x for all x in the field.
>The inverse of any nonzero x is x^(q-2). You can get this with
>O(log(q)) multiplications, regardless of the method used to
>encode field elements.
Am I doing something wrong? This statement only seems to be true ONLY
for field sizes 1, 2, 3, 5, 7 and 11. (But to be honest, I just tested
all field sizes up to about 30)
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
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: SHA algorithm
Date: Fri, 12 Mar 1999 15:41:48 -0800
Reply-To: [EMAIL PROTECTED]
iLLusIOn wrote:
> Padding is exactly the same as in MD5: First append a one, then as
> many zeros as necessary to make it 64 bits short of a multiple of
> 512, and finally a 64 bit representation of the length of the message
> before padding."
>
> what I don't understand is what I should do if the message is 488 bits
> for example. The space left (512 - 488 bits) is not enough to store the
> 64 bits which represent the original message length.
> How do messages with such a size get padded to 512 bits?
Pad out that first block with the initial 1 bit and then 0's all the
way to 512 bits, then the next block with 0's to 512-64=448 bits, then
add your 64-bit count at the end of the second block. That's the first
point at which you can stop 64 bits short of a multiple of 512.
--
Jim Gillogly
Trewesday, 20 Rethe S.R. 1999, 23:37
12.19.6.0.5, 13 Chicchan 18 Kayab, Fifth Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Quantum Computation and Cryptography
Date: 12 Mar 1999 23:44:57 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (R. Knauer) writes:
>>I have heard plenty of
>>statements that such NAND gates are possible, that equations have
Nand gates cannot be reversible. You can create a gate with two output
channels which is reversible. But nothing which takes two inputs and
produces one output can ever be reversible.
With a nand gate, you have three input states which go to the same
output. Thus you would need the second output to have three possible
states-- it could not be a binary output.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Are there free RSA Software lib's ?
Date: 12 Mar 1999 23:58:30 GMT
In <[EMAIL PROTECTED]> Rosenegger Josef <[EMAIL PROTECTED]>
writes:
>i've to implement data encryption (Public-Key cryptography) in our companies software.
>I'm going to use RSA cryptography. Question is, are the RSA sources free for
>companies usage?
No. RSADSI's sources are copyright and are not useable in a commercial
environment. In Germany there are no patent issues, but if your company
has any US arm, it is patented in the USA. The PGP implimentation of rSA
is also for non-commercial use. But I think there are non-US
implimentations which are free.
>I heard, it's not allowed to use RSA lib's for data encryption outside US. Is this
>true?
False. You need a license to export them from the USA. But if they are
already exproted, you need to settle the copyright issues. If those are
settled, you need to settle whether or not all the countries your
company opertes in allow the use of crypto. If that is OK, away you go.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Are there free RSA Software lib's ?
Date: 13 Mar 1999 00:01:49 GMT
In <7c0vea$au8$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>> Can I check , whether the codes are rewritten?
>Well if they are outside of the states they probably are legal. Check with
>the FTP admin to see how they got there.
No. There are still copyright issues which are valid all over the world.
RSAREF the RSADSI implimentation is free for use only in a
non-commercial setting. There are other implimentations however.
>You should still credit RSA labs for the use of their algorithm.
It is NOT their algorithm. The patent is owned by MIT. RSADSI is only
the licensor of that patent. The inventors are Rivest Shamir and
Adelman.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Are there free RSA Software lib's ?
Date: 13 Mar 1999 00:04:04 GMT
In <[EMAIL PROTECTED]> Rosenegger Josef <[EMAIL PROTECTED]>
writes:
>Now I red a few notes concerning the RSA patents.
>My conclusion: 1.) I'm allowed to implement the RSA algorithms
>exported from the US, in our products, also for commercial use, but
No. Those implimentations are copyrighted.
> 2.) Our partners in the US arn't
>allowed to import this new products without licence from RSA Data Security
>Inc.
>Is this right?
Yes, this is.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Does RC4 have the same problems as OTP?
Date: 13 Mar 1999 00:08:48 GMT
In <7c3ao6$c8t$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>I read that if you use the same key to encrypt two messages that you can
>weaken the RC4 security? Is that true?
Yes. RC4 is a deterministic random stream generator which is XORed with
the text. With two texts and the same RC4, an XOR of the outputs
produces an XOR of the clear texts ( which generally are highly
redundant)
------------------------------
** 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
******************************
