Cryptography-Digest Digest #722, Volume #9 Tue, 15 Jun 99 08:13:03 EDT
Contents:
Re: Message for DSCOTT(was:SLIDE ATTACK FAILS) (Boris Kazak)
Re: IDEA in "aplied cryptography" BRUCE SCHNEIER (Boris Kazak)
Re: Export restrictions question (Bill Unruh)
Re: IDEA in "aplied cryptography" BRUCE SCHNEIER (wtshaw)
Re: encrypt using ASCII 33 to 126 only? (wtshaw)
Re: Cracking DES ([EMAIL PROTECTED])
Re: Is there a short digest for short messages? Continued... (Francois Grieu)
Re: encrypt using ASCII 33 to 126 only? ("Douglas A. Gwyn")
Re: DES and BPANN ("Douglas A. Gwyn")
Cryptonomicon Errata in Neal Stephenson's new fiction: (C T Skinner)
Re: Generating Large Primes for ElGamal (Karel Wouters)
Re: DES ([EMAIL PROTECTED])
Re: DES ([EMAIL PROTECTED])
Re: DES ([EMAIL PROTECTED])
Re: huffman code length (Mok-Kong Shen)
Re: DES ([EMAIL PROTECTED])
Re: DES ([EMAIL PROTECTED])
Re: DES ([EMAIL PROTECTED])
Re: DES ([EMAIL PROTECTED])
DH with composite modulous based on P (Peter Gunn)
----------------------------------------------------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Subject: Re: Message for DSCOTT(was:SLIDE ATTACK FAILS)
Date: Mon, 14 Jun 1999 20:40:27 -0400
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
> (****************)
> So I think you should go download some papers and actually *READ*
> them. You declare yourself so smart yet you know so little.
>
> Tom
> --
> PGP key is at:
> 'http://mypage.goplay.com/tomstdenis/key.pgp'.
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
===================
This message is for David Scott.
This message is intentionally left unencrypted.
�� ������ ����� ������,
��� �����, ������� -
��������, ��� ����� � ��������� � ��� -
��� �� ������ ����� ����� ������.
������ �� ��������, ��������� ������ ��.
�������� �����, �� �� ���� ��������,
� �����. � �������, � ������� -
�� ��� � ����� � ����� � ���!
"�������, ��������� ��������� -
�� ����� ������� - ���� �� � ������ ��������?
������, �� �� �������, � �� ���� �ģ� ���ң�
� ��� ������ ������ �� ���������" -
"��, �� - �� ������ �������� -
��� ��-�� ��� � ���� �������,
��� � ������ ��� �����
���� ������� � ������� �������.
������ �� ������� ������ -
"�� ������, ����� ��� ������,
��� ���� �� �����"
I hope you will have no problems reading this. BNK
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Subject: Re: IDEA in "aplied cryptography" BRUCE SCHNEIER
Date: Mon, 14 Jun 1999 20:53:15 -0400
Reply-To: [EMAIL PROTECTED]
chciago wrote:
>
> hey, i wanted to implement the IDEA-algorythm by the sources in bruce
> schneiers book....
>
> is there a fault in this codes, or am i only too silly, to copy code
> from a book, but : "it doesn't work"
>
> or where can I find sources of IDEA which are working, I only want to
> use it for myself, not in a commercial way..
==================
Try <www.rpini.com> and browse their CryptoCD online.
The site is in Switzerland.
Best wishes BNK
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Export restrictions question
Date: 15 Jun 1999 04:59:52 GMT
In <7k1nbd$cpl$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>Can anyone provide some clarification for the encryption export
>restrictions. Let's say my key length is 64 bits (8 bytes). However
>all I'm doing is performing an XOR on each 8-byte block in the file from
>beginning to end. It is obviously not any of the fancy algorithms.
>Does that require export approval?
Under the regulations, all cryptography, even ROT 13 requires a license
to export it. All. Some gets that license more easily, some can be given
that license in general rather than having to get a separate license for
each and every export, but all need it.
Of course if the Bernstein case is upheld the regulations will be
replaced by others just as silly and you will still need a license.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: IDEA in "aplied cryptography" BRUCE SCHNEIER
Date: Tue, 15 Jun 1999 00:03:04 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> [EMAIL PROTECTED] (James Pate Williams, Jr.) wrote, in part:
>
> >if you are a citizen of the United
> >States of America currently residing in the U.S.
>
> Not to keep criticizing you for being helpful, but I doubt the United
> States has annexed Germany any time lately...
>
Details...details....
--
Weathermen prosphesize and insurance companies predict, while both pretend to be doing
the other to get an audience.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: encrypt using ASCII 33 to 126 only?
Date: Tue, 15 Jun 1999 00:00:59 -0600
In article <[EMAIL PROTECTED]>, "Kenneth
N Macpherson" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I am trying to find code (vb) that will take a string (all chars in range 33
> to 126 ASCII) and encrypt it again using chars in range 33 to 126.
>
> Reason for range is so users can type in the encrypted string from the
> keyboard.
>
> Although 127 is a keyboard char (deleteI think) it is not easily displayed!
> ;-) .
>
I.ve spent considerable time on this area, themes, variations, many more
weird tangents than I would likely admit. My advice is to not use quite
all the characters in actual ciphertext so that you have some control
characters. Consider that you might want to handle spaces and certain
other formatting in printable characters.
I suggest that a 90 character set is handy without formating and beginning
with 33. The simplest algorithm would be ROT45. This paragraph in ROT45
is:
v FH::8FG G;4G 4 f] 6;4E46G8E F8G <F ;4A7L J<G;BHG 9BE@4G<A: 4A7 58:<AA<A:
J<G; ``[ ';8 F<@C?8FG 4?:BE<G;@ JBH?7 58 %"'ab[ ';<F C4E4:E4C; <A %"'ab
<Fg
Of course, you could just invert the same character set for the same
plaintext and get:
R (&446(' '3:' : bk 83:):8'6) (6' 2( 3:-7" $2'3,&' 5,).:'2-4 :-7 9642--2-4
$2'3 hhm G36 (2.+/6(' :/4,)2'3. $,&/7 96 ILGgfm G32( +:):4):+3 2- ILGgf
2(a
Of course, you could do Caesars in the same set too. Different character
sets are no real obstacle to making simple to complex crypto; you do run
across some rather interesting problems making some of them work well.
There are many possible more complicated algorithms that can be made from
sets approximating that size.
--
Weathermen prosphesize and insurance companies predict, while both pretend to be doing
the other to get an audience.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cracking DES
Date: Tue, 15 Jun 1999 04:54:31 GMT
Terry Ritter wrote:
>
> David Wagner wrote:
> >[...]
> >> And if 5% of the traffic can expose everything, why is it that
anyone
> >> ever bothers to send the other 95%?
> >
> >Oh, come on, I think this question is disingenous.
>
> I strongly disagree:
Of course the question is disingenuous, but it you want an
obvious answer, maybe they're sending the same info to
different people.
> Most of us communicate to some end, but communication has costs in
> time, effort, and resources. If our goal is to share information, we
> simply must ask why we would make this costly effort 20 times more
> often than necessary. The implication that we do just that simply
> does not make sense. That is *not* a disingenuous argument, it is
> common sense and economics.
It's a simple falsehood. You've done real engineering projects
right? Notice the distribution of the documents and how many
revisions they went through?
> What you suggest simply cannot be done, no matter how expert the
> analysts and how much time is spent. There is more to writing than a
> plot, and there is usually more to a plot than one can find from a
> random sample of 5%, unless one is very lucky.
The book example is nonsense. Get 20 copies; problem solved.
A million copies of a book are 99.9999% redundant.
> I see the claim as nonsense on its face, so I certainly would not
> expect to see any result in the "other" direction. Anyone who wants
> us to believe that 95% of the text we labor to create and pay to send
> is no more than useless redundancy carries the weight of proof on
> *their* shoulders. Obviously.
As usual, you attribute to your opposition an assertion you
yourself made up.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Francois Grieu)
Subject: Re: Is there a short digest for short messages? Continued...
Date: Tue, 15 Jun 1999 07:54:23 +0200
Joe wrote:
> The original problem is (..) software authorization.
(..)
> I'm going to use (..) a secret key (..) shared between signer and verifier
It will be difficult to hide the secret key from a determined hacker,
which could then proceed to massively distribute/sell (the results of)
a program revealing the signature for all users. In theory,
the problem could be solved by using asymetyric cryptography, at
the expense of a much longer signature (at least 500 bits for RSA/Rabin,
still a lot with elliptic curve crypto).
But this precaution is probably useless, since a determined hacker can
about as easily remove the copy protection altogether.
Francois Grieu
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: encrypt using ASCII 33 to 126 only?
Date: Tue, 15 Jun 1999 07:56:21 GMT
Kenneth N Macpherson wrote:
> I am trying to find code (vb) that will take a string (all chars in range 33
> to 126 ASCII) and encrypt it again using chars in range 33 to 126.
You can encrypt with *any* algorithm, then convert the binary result
to characters in that range (e.g. if the result is in octets, split
each octet into two 4-bit nybbles and add 64 to each of them).
Decryption is, of course, just the inverse process: subtract 64
from each character and take them pairwise: c0*16+c1 to create the
ciphertext to go into the corresponding decryption algorithm.
The main drawback to the above is that it produces a "ciphertext"
that is twice as long as necessary.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: DES and BPANN
Date: Tue, 15 Jun 1999 08:08:37 GMT
"James Pate Williams, Jr." wrote:
> Does anyone know of the usage of a backpropagation with momentum
> artificial neural network (BPANN) to learn the DES function given a
> few training examples that consist of known plaintext - ciphertext
> pairs. ... If you would like to have a copy of C++ BPANN with
> momentum source code to learn the simple exclusive or (XOR)
> function then email at the following address requesting test.cpp.
The big difference is that the XOR function is vastly simpler than
the BPANN, but the DES encryption function is sufficiently complex
that any "learning" process which does not model the actual DES
structure fairly closely doesn't have an appreciable chance of
converging to a *correct* model.
------------------------------
From: C T Skinner <[EMAIL PROTECTED]>
Subject: Cryptonomicon Errata in Neal Stephenson's new fiction:
Date: Tue, 15 Jun 1999 18:27:39 +1000
Cryptonomicon Errata
Neal Stephenson's new fiction:
I am up to p215 & have noted these errata:
p54 Factoring is not 2x as hard with each extra bit,
more like sqrt(N log N) or whatever NFS is these days
p70 2nd line of decrypt T should be R
p92?? earthquake damage in Manila in the 80's (this may well be true, or
true fiction, Volcanoes,Typhoons, I may have forgotten the odd
earthquake)
p98 "sicks out" should be "sticks out"
Do yourself a favour and get this book
(I have not got very far, obviously, and one reviewer said that
NS doesnt tidy up his plot lines, but so far it is delightful.
------------------------------
From: Karel Wouters <[EMAIL PROTECTED]>
Subject: Re: Generating Large Primes for ElGamal
Date: Tue, 15 Jun 1999 11:03:11 +0200
Hi;
there are serveral packages available;
I've worked with:
LiDIA (C++) :
http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html
NTL (C++):
http://www.shoup.net/
and ZEN (C):
http://www.dmi.ens.fr/~zen/
Karel w
On Mon, 14 Jun 1999 [EMAIL PROTECTED] wrote:
> HI,
>
> I'm interested in implementing ElGamal public key encryption. Is there
> any public source available ( C++ would be great ) for generating large
> primes used in public key encryption?
>
> Thanks,
>
> Ron
>
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
>
>
--
"What one man knows, nobody knows; what two men know, everybody knows"
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: DES
Date: Tue, 15 Jun 1999 08:11:18 GMT
> >DES;
> >1 That initial permutation; is it actualy worth
anything
> >cryptograpicaly?
>
> No. They were put there to support the hardware
implementation of
> DES that was popular in the mid-1970s.
>
I've heard and read this several times but while
being from a hardware background I cannot see how
the initial permutation could speed up the
hardware implementation. Does anyone know how it
helps the hardware?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: DES
Date: Tue, 15 Jun 1999 08:11:16 GMT
> >DES;
> >1 That initial permutation; is it actualy worth
anything
> >cryptograpicaly?
>
> No. They were put there to support the hardware
implementation of
> DES that was popular in the mid-1970s.
>
I've heard and read this several times but while
being from a hardware background I cannot see how
the initial permutation could speed up the
hardware implementation. Does anyone know how it
helps the hardware?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: DES
Date: Tue, 15 Jun 1999 08:11:20 GMT
> >DES;
> >1 That initial permutation; is it actualy worth
anything
> >cryptograpicaly?
>
> No. They were put there to support the hardware
implementation of
> DES that was popular in the mid-1970s.
>
I've heard and read this several times but while
being from a hardware background I cannot see how
the initial permutation could speed up the
hardware implementation. Does anyone know how it
helps the hardware?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.compression,alt.comp.compression,sci.math
Subject: Re: huffman code length
Date: Tue, 15 Jun 1999 11:47:54 +0200
Andras Erdei wrote:
>
> p0 = epsilon , p1 = 1.0 - epsilon seems to be non-uniform enough,
> and still the tree ((0)(1)) seems to be "balanced" enough :)
The issue certainly depends on the number of nodes. As my example
shows, with four nodes the possible frequency distributions for
a balanced tree are already fairly limited. I conjecture that
for relatively large number of nodes the possible frequency
distributions (frequencies sorted according to magnitude) for an
arbitrarily given Huffman tree are quite limited so that some useful
informations can be gained. Of course the Huffman tree can't uniquely
determine the frequencies, as the examples clearly indicate.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: DES
Date: Tue, 15 Jun 1999 08:15:26 GMT
> >DES;
> >1 That initial permutation; is it actualy worth anything
> >cryptograpicaly?
>
> No. They were put there to support the hardware implementation of
> DES that was popular in the mid-1970s.
>
I've heard and read this several times before but being from a hardware
background I cannot see how this can help a hardware implementation.
Can anyone tell me how the initial permutation helps implementation in
hardware?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: DES
Date: Tue, 15 Jun 1999 08:11:17 GMT
> >DES;
> >1 That initial permutation; is it actualy worth
anything
> >cryptograpicaly?
>
> No. They were put there to support the hardware
implementation of
> DES that was popular in the mid-1970s.
>
I've heard and read this several times but while
being from a hardware background I cannot see how
the initial permutation could speed up the
hardware implementation. Does anyone know how it
helps the hardware?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: DES
Date: Tue, 15 Jun 1999 08:11:22 GMT
> >DES;
> >1 That initial permutation; is it actualy worth
anything
> >cryptograpicaly?
>
> No. They were put there to support the hardware
implementation of
> DES that was popular in the mid-1970s.
>
I've heard and read this several times but while
being from a hardware background I cannot see how
the initial permutation could speed up the
hardware implementation. Does anyone know how it
helps the hardware?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: DES
Date: Tue, 15 Jun 1999 08:11:23 GMT
> >1 That initial permutation; is it actualy worth
anything
> >cryptograpicaly?
>
> No. They were put there to support the hardware
implementation of
> DES that was popular in the mid-1970s.
>
I've heard and read this several times but while
being from a hardware background I cannot see how
the initial permutation could speed up the
hardware implementation. Does anyone know how it
helps the hardware?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Peter Gunn <[EMAIL PROTECTED]>
Subject: DH with composite modulous based on P
Date: Tue, 15 Jun 1999 11:34:38 +0100
Im now investigating doing a DH key exchange using a large
composite modulous based on multiplying two large primes
together and adding one, rather than the usual large safe prime.
exchange is as follows...
U is username
P is short password hash
X,Y,C1,C2 are large random numbers
g is fixed (say 4)
1) A->B: U, (g^X)%f(P), C1
2) B->A: (g^Y)%f(P),C2
3) A->B: E[(g^XY)%f(P)](C2)
4) B->A: E[(g^XY)%f(P)](C1)
now, Ive been thinking of efficient ways of implementing f(P)
andI was thinking that I could do something like the following...
store a table of primes, lookup 2 based on P, multiply them
together and add one :-)
I could store the prime gaps rather than the primes themselves
for primes over a small range. This should make storage overheads
negligible, but it means that just using 'safe' primes is out (not dense
enough).
Here is a code snippet as an example, which creates an odd
1024bit composite number from a 16bit key...
// 2^512+x+1 is prime (probably prime in this example)
static long gap[256]={
110,698,490,300,264,512,180,540,108,6,1764,1462,336,312,
462,308,172,158,46,20,66,226,140,52,396,1032,242,72,
168,130,20,366,586,614,174,532,26,234,376,84,26,522,
738,1458,216,624,910,246,824,274,350,196,870,80,876,
778,266,154,6,330,414,20,6,462,1212,156,816,208,1548,
890,222,310,692,36,388,170,796,1116,288,330,480,30,
822,338,396,210,456,70,20,70,1068,150,104,166,392,240,
958,1094,886,254,538,428,666,40,318,416,640,122,382,
488,384,94,224,276,672,544,198,170,316,510,1256,850,
966,8,10,156,528,320,396,100,176,144,124,432,116,172,
420,302,1000,336,384,308,142,254,1474,78,464,228,120,
1068,568,30,266,160,440,288,162,694,432,528,192,192,
1028,280,12,858,468,192,260,148,194,78,34,44,1240,144,
848,162,58,902,816,184,960,158,22,116,654,256,224,60,
222,364,2,700,234,426,20,694,6,330,668,840,130,192,
120,284,16,288,260,250,456,20,1060,218,252,178,240,2,
508,1022,198,112,84,966,84,224,96,270,324,372,154,104,
30,42,1518,112,350,340,1950,554,16,224,480,310,620,240,
210,216,598,188,78,130,632,22,42,576
};
// space for the 1024bit composite number.
static unsigned char modulous[128];
// construct a 1024bit number by multiplying two
// 512bit primes together and adding one.
void create_modulous(unsigned short p)
{
unsigned long i,p1,p2,n;
modulous[0]=0x80;
for (i=1;i<1024;i++)
modulous[i]=0;
p1=1;
for (i=1;i<=(p>>8);i++)
p1+=gap[i];
p2=1;
for (i=1;i<=(p&0xff);i++)
p2+=gap[i];
n=(p1>>1)*(p2>>1);
modulous[127]=(unsigned char)(n<<2)+1;
modulous[126]=(unsigned char)(n>>6);
modulous[125]=(unsigned char)(n>>14);
modulous[124]=(unsigned char)(n>>22);
modulous[123]=(unsigned char)(n>>30);
}
Does this sound sensible?
All comments welcome :-)
tata
PG.
------------------------------
** 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
******************************
