Cryptography-Digest Digest #712, Volume #9 Sun, 13 Jun 99 13:13:03 EDT
Contents:
Re: Maximum key size in block ciphers (Casey Sybrandy)
Re: Slide Attack on Scott19u.zip (fungus)
Re: OTP is it really ugly to use or not? (fungus)
Re: Slide Attack on Scott19u.zip (SCOTT19U.ZIP_GUY)
Re: Slide Attack on Scott19u.zip (SCOTT19U.ZIP_GUY)
Re: PKCS#10 request ([EMAIL PROTECTED])
Re: Maximum key size in block ciphers ([EMAIL PROTECTED])
Re: Prime number generators... (James Pate Williams, Jr.)
Re: Slide Attack on Scott19u.zip (Horst Ossifrage)
Re: RSA msg length... ("Particle")
Re: Random numbers on a sphere (Ian Goldberg)
RC4 Shell Extension / COM Server ([EMAIL PROTECTED])
Re: Slide Attack on Scott19u.zip (fungus)
----------------------------------------------------------------------------
From: Casey Sybrandy <[EMAIL PROTECTED]>
Subject: Re: Maximum key size in block ciphers
Date: Sun, 13 Jun 1999 07:49:01 -0400
If you're running linux or if you have access to any unix workstations,
use the bc command. It is designed for large integer arithmatic. You
may also be able to find a windows/dos port. Two good places to start
are www.gnu.org and ftp.cdrom.com
[EMAIL PROTECTED] wrote:
> I must apologize to DaveScott. I did post bad info. The actual max
> size of any block cipher key is
>
> (2^n)! for example if the block size is 8 bits, then the max key size
> is 256! or 1683.99628722421461940614767931775 bits
>
> If you think about it thats the number of arrangments for the
> substitution. For block sizes of 64 bits it's quite large at
>
> s = 18446744073709551616!
>
> (in bits it is 'log(s) / log(2)')
>
> Which I cannot do on my calc or any calc (It would take a bit...)
>
> Sorry about the previous bad info.
>
> --
> PGP public keys. SPARE key is for daily work, WORK key is for
> published work. The spare is at
> 'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
> 'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Slide Attack on Scott19u.zip
Date: Sun, 13 Jun 1999 08:28:12 +0200
[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]>,
> fungus <[EMAIL PROTECTED]> wrote:
> >
> > Dream on.
> >
> > DS is no doubt planning scott20 as we speak...he's like (worse
> > than!) Freddy Kruger, he just won't give it a rest.
>
> Ok well why not break my cipher? I think it can be done and I really
> want to try (I am just not good at things like this). I hate thinking
> that my cipher is 'really strong' which means I don't know enough yet.
>
One thing is when a person is willing to discuss algorithms and
methods.
Another thing is when somebody goes on and on about a program with
no published algorithms, methodology, or reasoning behind it, just
a big pile of messy C code for us to inspect if we can be bothered.
D. Scott has been pushing scott19 for about a year now. He claims
it's the answer to the NSA and that things like PGP shouldn't
be trusted. Then, as soon as somebody looks at it seriously it
falls apart.
It happened with scott16u, the result was scott19u. It happened with
scott19u and I have a horrible feeling that the "answer" will be
scott20u. The process will start all over again.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: OTP is it really ugly to use or not?
Date: Sun, 13 Jun 1999 08:29:33 +0200
Erm Yankoil wrote:
>
> Cyba Nonymous <[EMAIL PROTECTED]> wrote:
>
> >I read in this group that the security of an OTP depends on the
> >pad being random. Really random and not just pseudo-random.
>
> I think it's more accurate to say that the absolute validity of the
> mathematical proof that the OTP is secure depends on the true
> randomness of the pad. It's perfectly possible to use a less
> than perfect random number generator for your one time pad and
> still have message security that can and will never be compromised.
eg. RC4.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Slide Attack on Scott19u.zip
Date: Sun, 13 Jun 1999 14:15:27 GMT
In article <[EMAIL PROTECTED]>, Horst Ossifrage <[EMAIL PROTECTED]> wrote:
>SCOTT19U.ZIP_GUY wrote:
>>
>> In article <7jumfq$b1m$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (David Wagner) wrote:
>> >In article <7jue3a$2ci0$[EMAIL PROTECTED]>,
>> >SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>
>> >> Just what do you mean bypass the fact the first and last round
>> >> are different. DO you mean your attacking a reduced version
>> >> of Scott19u. I think that reduced version attack was kind of what
>> >> Paul Onions did a long time ago?
>> >
>> >I'm not suggesting to attack a reduced version.
>>
>> Then you have to face the fact of the two other passes
>> front and back
>
>Slide Attack Attempt Against Scott19u.zip
>
>The cipher is immune to the Slide Attack because it uses
>a non-periodic round structure. In the paper on the Slide
>Attack, on page 2, paragraph 2 it says that the attack is
>"easy to prevent by destroying self-similarity of an
>iterative process".
>
>The Scott19u.zip algorism has 25 rounds: the first one
>and last one are the "Paul" function, and the middle
>23 rounds are the ones described in the documentation
>in great detail. I forgot to put mention of the Paul
>function in the documentation, and I hope that David
>Scott will edit that page on xoom.com to describe those
>rounds. Here is part of the C program for encryption.
>(It is made non-functional for export limitations).
>Notice that it uses Paul(a, i19) before and after the
>loop for the 23 middle rounds:
>
>#define EPE (23)
>void
>doEnce(p19 * a, un32 x)
>{
> /* encrypts a file using 19 bit words */
> un32 iz, izz;
> un32 i, j, ip, ipp, k;
> un32 i19, i19s, jj;
> p19 *pp19;
> po19 *ppo19;
> void *v;
> if (x < 8) {
> printf(" this method for 8 or more characters only \n");
> exit(1);
> }
> jj = ((x%19)*8+18)/19;
> i19s = ((x%19)*8)/19;
> i19 = ( x/19)*8 + jj; /* length of file in 19 bit units to cover it
>all*/
> i19s = ( x/19)*8 + i19s; /* length of file in full use 19 bit units */
> v = a;
> pp19 = a;
> /* snipped to make non-functional to foil export usability 6/13/99 */
> pf19 = v + x;
> pb19 = v + x - 8;
>
> Paul(a, i19);
>
> if( i19 != i19s){
> pf19->a00 = 0x7ffff;
> iz = geto19(ppo19, i19-1);
> pf19->a00 = 0;
> izz = geto19(ppo19, i19-1);
> i19s += 0 == ( iz ^ izz);
> ;}
>
> for (i = 0; i < EPE; i++) {
> k = pb19->a00;
> ip = get19(a, 0);
> ipp = get19(a, 1);
> k = get19( ft, 0x7ffff &(( k ^ ip) + ipp) );
> puto19(k, ppo19, 0);
> pf19->a00 = k;
>
> ip = ipp;
> ipp = get19( a, 2);
> /* snipped to make non-functional to foil export usability 6/13/99 */
> puto19(k, ppo19, 1);
> pf19->a01 = k;
>
> for( j = 2; j < i19s; j++ ){
> ip = ipp;
> ipp = get19( a, j+1);
> k = get19( ft, 0x7ffff &(( k ^ ip) + ipp) );
> puto19(k, ppo19, j);
> }
> ip = get19( a, j+1);
> puto19(ipp, ppo19,j);
> puto19(ip, ppo19,j+1);
> }
> Paul(a, i19);
>}
>
>In conclusion, the cryptographic algorithm Scott19u.zip
>is immune to the basic Slide Attack because the rounds
>are not all the same. The first round is different from
>the next 23 rounds. The last round is like the first round.
>
>Thanks to David, David, Paul, Tom, Tim, and others for
>participating in this discussion. Good bye.
Thanks Horst
For looking at the Slide Attack. I am glad you have analyzed it
deeply enough to find that it is immune to the basic Slife Attack.
I took Choosen Plain Text Attacks more seriously after Paul Onions
convinced me that it should be immune if possible to a single choosen
Plaintext attack. I have not read the full article yet of Wagners attack
but on the surface it sounds very similar to the work of Paul Onions
who desires a lot of credit. It was thoughts of him while consuming
vast quanties of my favorite german beer ( better than english beer sorry)
that lead to this first and last round function called the Paul function.
Yes I will add a write up in your section describing the routine.
But wish you would edit the english sense your better at it.
However I still feel that thousands of "total choosen plain text attack
files" Is not a realistic way to break any method. Since it would require
the enemy to send thousands of nonsense messages of the exact size
however I feel that it is a partial measure of securtiy just like the fact
that if you use any of the AES candidates and the blessed chainning
methods. An enemy needs on a small portion of you file to have enough
information to break your method. It is far better when sending complete
messages to use a "all or nothing encryption" method like scott19u.zip
The Paul routine was my first attempt to defeat plain text attacks and
my code should be analyzed in the mode where the encrypted file is
the same exact lenght as the input file. This is hard to achive with the
NSA approved chainning methods. But in reality to get a boost of security
beyond my basic approach I would encourage the mode where a random
pad is added to the front of file. Espeially useful for short messages.
If one has a good compler you can also add in my h2com.exe routine
if one is using files that are generally compressable with an adaptive
huffman compress.( I will add this in menu for next release). This is far
better than the way compression done in PGP. The compressed file has
no headers what so ever and unlike most compression routines was designed
to be used with encryption. In there are no headers in any file that an
attacker would stumble upon if guessing a key has the property that if
any file uncompress by my method it would recompress back to the same file. Do
not confuse this with the property shared by other compressors that any
compressed file uncompress back to the orginal file. If any one knows of any
other compression methods like this please let me know.
Thanks Again Horst
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Slide Attack on Scott19u.zip
Date: Sun, 13 Jun 1999 14:38:34 GMT
In article <[EMAIL PROTECTED]>, fungus
<[EMAIL PROTECTED]> wrote:
>
>
>[EMAIL PROTECTED] wrote:
>>
>> In article <[EMAIL PROTECTED]>,
>> fungus <[EMAIL PROTECTED]> wrote:
>> >
>> > Dream on.
>> >
>> > DS is no doubt planning scott20 as we speak...he's like (worse
>> > than!) Freddy Kruger, he just won't give it a rest.
>>
>> Ok well why not break my cipher? I think it can be done and I really
>> want to try (I am just not good at things like this). I hate thinking
>> that my cipher is 'really strong' which means I don't know enough yet.
>>
>
>One thing is when a person is willing to discuss algorithms and
>methods.
>
>Another thing is when somebody goes on and on about a program with
>no published algorithms, methodology, or reasoning behind it, just
>a big pile of messy C code for us to inspect if we can be bothered.
>
>D. Scott has been pushing scott19 for about a year now. He claims
>it's the answer to the NSA and that things like PGP shouldn't
>be trusted. Then, as soon as somebody looks at it seriously it
>falls apart.
>
>It happened with scott16u, the result was scott19u. It happened with
>scott19u and I have a horrible feeling that the "answer" will be
>scott20u. The process will start all over again.
>
>
Actually you are lying it never happened with scott16u. I made scott19u
since it was the largest size that could have a key that could cover any
possible single cycle S-table of 19 bits. Why do you have to ly and if you
read Horst's last comment he says it does not fall apart under the basic
Slide Attack. Yet assholes like you keep remembering the partial comments
of the spammer mr BS and David Wagner who consider it dead yet don't
have the time to look at it.
I am not a kiss ass false crypto god that is afraid some ametuer is going
to shoe them up. When can ass holes like you get that through your thick
head. Again for you 'SCOTT16U" was never broken and I have a contest
for it with a thousand dollars that expires on Nov 11 this year. Last year
one of the crypto gods called the contest a joke since it was a short time
the asshole went in to say not enough time. I had to write the asshole to
explain that it didn't expire to NOV 11 1999 needless to say the asshole
never correct his error. They like to make sweeping statements to mislead
but seldom clean up the mis truths they spread. And assholes like you
continue to spread there lies.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: PKCS#10 request
Date: Sun, 13 Jun 1999 13:22:08 GMT
In article <[EMAIL PROTECTED]>,
Tomislav Posavec <[EMAIL PROTECTED]> wrote:
> Looking for freeware source code to generate PKCS#10 cert requests.
> Does anyone know if something like that is out there? Thanks.
I think a good place to start looking is at RSADSI. I dunno for sure.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Maximum key size in block ciphers
Date: Sun, 13 Jun 1999 13:20:28 GMT
In article <[EMAIL PROTECTED]>,
Casey Sybrandy <[EMAIL PROTECTED]> wrote:
> If you're running linux or if you have access to any unix
workstations,
> use the bc command. It is designed for large integer arithmatic. You
> may also be able to find a windows/dos port. Two good places to start
> are www.gnu.org and ftp.cdrom.com
>
Thanks for the info I will check it out. but wouldn't 2^64! take a
while no matter what program you run?
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (James Pate Williams, Jr.)
Subject: Re: Prime number generators...
Date: Sun, 13 Jun 1999 16:16:26 GMT
On 13 Jun 1999 15:39:27 GMT, Krunoslav Leljak <[EMAIL PROTECTED]>
wrote:
>It seems that prime number generators of all numeric libraries
>OCCASIONALY hang slower computers. Is that happening to
>somebody else?
When I had a Pentium I 90 MHz machine with 16 MB of RAM F-Secure SSH
used to hang-up when I tried to generate a RSA key greater than
512-bits. Now that I have a Pentium II 450 MHz with 128 MB of RAM this
does not occur.
==Pate Williams==
[EMAIL PROTECTED]
http://www.mindspring.com/~pate
------------------------------
From: Horst Ossifrage <[EMAIL PROTECTED]>
Subject: Re: Slide Attack on Scott19u.zip
Date: Sun, 13 Jun 1999 08:44:21 -1000
SCOTT19U.ZIP_GUY wrote:
>
> In article <[EMAIL PROTECTED]>, Horst Ossifrage <[EMAIL PROTECTED]> wrote:
> >Slide Attack Attempt Against Scott19u.zip
> >
> >The cipher is immune to the Slide Attack because it uses
> >a non-periodic round structure.
> Thanks Horst
> For looking at the Slide Attack. I am glad you have analyzed it
> deeply enough to find that it is immune to the basic Slife Attack.
> Yes I will add a write up in your section describing the routine.
> But wish you would edit the english sense your better at it.
> David A. Scott
Yes David,I will edit your documentation page, again. You
have my phone number and true e-mail address, so let's start
writing a couple of paragraphs on it tomorrow. My machine
will contact your machine.
Horst Ossifrage (not)
============================
Download Scott19u.zip today! Expect nothing, get everything!
http://members.xoom.com/ecil/index.htm
------------------------------
From: "Particle" <[EMAIL PROTECTED]>
Subject: Re: RSA msg length...
Date: Sun, 13 Jun 1999 11:44:43 -0400
> >how big can a msg (block) be?
> Think of an example with artificially small parameters:
> p = 3 and q = 5, n = p * q = 15 = 1111 (in binary). The largest
> message is m = 14 = 1110. This has bit length 4 which is the bit
> length of the modulus.
hmm... thanks. I didn't have enough sense to test it with such
small numbers... and so I did... and you're right!
p = 3
q = 5
n = 15
e = 7
d = 7
plain = 1; encrypted = 1; plain = 1;
plain = 2; encrypted = 8; plain = 2;
plain = 3; encrypted = 12; plain = 3;
plain = 4; encrypted = 4; plain = 4;
plain = 5; encrypted = 5; plain = 5;
plain = 6; encrypted = 6; plain = 6;
plain = 7; encrypted = 13; plain = 7;
plain = 8; encrypted = 2; plain = 8;
plain = 9; encrypted = 9; plain = 9;
plain = 10; encrypted = 10; plain = 10;
plain = 11; encrypted = 11; plain = 11;
plain = 12; encrypted = 3; plain = 12;
plain = 13; encrypted = 7; plain = 13;
plain = 14; encrypted = 14; plain = 14;
plain = 15; encrypted = 0; plain = 0;
plain = 16; encrypted = 1; plain = 1;
plain = 17; encrypted = 8; plain = 2;
plain = 18; encrypted = 12; plain = 3;
the algorithm does break down if msg is taken to
be more than n-1
thanks a lot!
--
Particle
[EMAIL PROTECTED]
http://www.geocities.com/SiliconValley/Way/7650
Home of the Java Data Structures 2nd Edition.
------------------------------
From: [EMAIL PROTECTED] (Ian Goldberg)
Crossposted-To: sci.math.num-analysis
Subject: Re: Random numbers on a sphere
Date: 13 Jun 1999 15:59:19 GMT
>Ed McBride wrote:
>>>What am I missing? I would use spherical coordinates, select theta
>>>randomly between 0,2pi then phi randomly between 0,pi set radius =1
>>>and I'm done.
>
>Pierre Asselin wrote:
>>Too many points near the poles. Try it and see.
(On my news server, anyway, this just showed up on sci.crypt...)
The problem is to pick points uniformly at random across the _surface area_
of a sphere, yes?
Simple (method; hard to understand why it works): pick z uniformly at random
from [-1,1]. This selects a circle. Select theta uniformly at random to
pick a point on the circle.
This is a consequence of the so-called "apple skin" theorem: (assuming
spherical apples) if you cut an apple into *equally thick* slices, there
will be the same amount of skin on each slice. The slices near the ends
will be smaller, but mostly skin. The slices in the middle will be larger,
but only have skin around the edge. It turns out these things exactly cancel
out.
- Ian "generalization to n dimensions is left as an exercise for the reader"
------------------------------
From: [EMAIL PROTECTED]
Subject: RC4 Shell Extension / COM Server
Date: Sun, 13 Jun 1999 15:55:47 GMT
FYI
http://community.wow.net/grt/rc4se.html
128 bit RC4 (TM) Encryption
Shell Extension and COM Automation
Server for Windows 95/98/NT4.
115 KB.
Freeware. Freely distributable.
RC4SE.DLL is a Windows 95/98/NT4 Shell Extension and COM
Automation Server for
(a) encryption/decryption of files from the Explorer right click
context menu
(b) encryption/decryption/wiping of files using MS Visual Basic,
the Windows Scripting Host, MS Office VBA, MS Java, C++ etc
It uses the 128 bit RC4 (TM) encryption of the Microsoft
Enhanced Cryptographic Service Provider RSAENH.DLL. This is
typically installed by the 128 bit version of MS Internet Explorer
or an NT4 Service Pack.
Gerard R Thomas
Port of Spain, Trinidad and Tobago
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
PGP Key IDs: RSA:0x9DBCDE7D DH/DSS:0xFF7155A2
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Slide Attack on Scott19u.zip
Date: Sun, 13 Jun 1999 19:21:29 +0200
[EMAIL PROTECTED] wrote:
>
> maybe Dave Scott can
> learn about efficient algorithm design? Maybe he will learn, I think
> we should grant him a little patience. He thinks he is the be-all in
> the world. Let him mature a bit and maybe he could contribute
> usefullness.
>
"Mature a bit"?
In my experience he gets worse as time passes.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
** 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
******************************
