Cryptography-Digest Digest #238, Volume #9 Mon, 15 Mar 99 22:13:04 EST
Contents:
Re: Test vectors for RC4 (Mok-Kong Shen)
Re: Secure Hash (shc.c) (Jim Gillogly)
Source-code to program to wipe free disk-space in Win95? (Sundial Services)
Re: Finite Field with Hard Division? (Guenther Brunthaler)
Re: Test vectors for RC4 ([EMAIL PROTECTED])
Re: Secure Hash (shc.c) ([EMAIL PROTECTED])
Re: DIE HARD and Crypto Grade RNGs. (Patrick Juola)
Re: Test vectors for RC4 ("John E. Kuslich")
Re: Test vectors for RC4 ("John E. Kuslich")
Re: Secure Hash (shc.c) (Jim Gillogly)
Re: Self-executing encryption program (Sundial Services)
Re: RSA in JavaScript? (Paul Rubin)
ANNOUNCING A TINY VERSION OF RIJNDAEL ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Test vectors for RC4
Date: Mon, 15 Mar 1999 19:50:30 +0100
[EMAIL PROTECTED] wrote:
> Yes, RC4 has not been broken, and no weaknesses have been reported yet. It
> seems quite strong. However it's slower then RC5/RC6, doesn't support block
In my opinon statements like 'it seems quite strong' don't convey
much.
M. K. Shen
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Secure Hash (shc.c)
Date: Mon, 15 Mar 1999 13:46:44 -0800
Jim Gillogly wrote:
> 66481 0.0040 80
> 66538 0.0040 05
> 66539 0.0040 02
> 66601 0.0040 20
> 66615 0.0040 01
> 66740 0.0040 40
> 66864 0.0040 10
> 67048 0.0040 08
> 67069 0.0040 04
> 71501 0.0043 00
I re-did this test using random 4-byte inputs rather than sequential
ones, and got the same effect. Looks like something in your hash is
eating bits, predisposing the outputs to be 0 bits with some probability.
--
Jim Gillogly
Highday, 23 Rethe S.R. 1999, 21:45
12.19.6.0.8, 3 Lamat 1 Cumku, Eighth Lord of Night
------------------------------
Date: Mon, 15 Mar 1999 15:44:00 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Source-code to program to wipe free disk-space in Win95?
Is there any source-code to a program that will wipe free disk-space and
scrub unused space in the last cluster of files? The program should run
under Win95, any filesystem, and should use only published Win32
interfaces (if possible) to do its work.
Many thanks in advance. Please reply to the newsgroup only.
------------------------------
From: [EMAIL PROTECTED] (Guenther Brunthaler)
Subject: Re: Finite Field with Hard Division?
Date: Mon, 15 Mar 1999 22:42:15 GMT
On Sat, 13 Mar 1999 07:40:05 GMT, [EMAIL PROTECTED] wrote:
>>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)
Well, actually I am only interested in calculating the multiplicative
inverse for any x in GF(2 ** m).
So I was thinking this inverse could simply be calculated as
x^(2 ** m - 2)
but this was correct only for m == 0 && m == 1!
>the field, thus, in this case, q-1. (The order of the multiplicative
>group of a field of order q is q-1---throw out 0) Thus for every x in
>the field, x^(q-1)=1. That is, x^q=x, as was originally stated
>(correctly).
Does that mean I the inverse can be calculated as
x^(2 ** m - 3)
then?
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: [EMAIL PROTECTED]
Subject: Re: Test vectors for RC4
Date: Mon, 15 Mar 1999 23:14:46 GMT
> > Yes, RC4 has not been broken, and no weaknesses have been reported yet. It
> > seems quite strong. However it's slower then RC5/RC6, doesn't support
block
>
> In my opinon statements like 'it seems quite strong' don't convey
> much.
>
Well there are 256! possible session keys. And I believe the user key and
session key have a 1:1 ratio. So that would mean it's pretty strong.
Provided you don't use the same key twice.
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Secure Hash (shc.c)
Date: Mon, 15 Mar 1999 23:25:41 GMT
> 66481 0.0040 80
> 66538 0.0040 05
> 66539 0.0040 02
> 66601 0.0040 20
> 66615 0.0040 01
> 66740 0.0040 40
> 66864 0.0040 10
> 67048 0.0040 08
> 67069 0.0040 04
> 71501 0.0043 00
>
Would this mean that there are biases? Any clue why it's always towards zero?
It's not linear (02 and 05 are at the top), but why zero?
Would you say my algorithm is not secure, but reasonably ok given it's speed?
I would like to make another pass at it. I already posted my idea for SHC2
(different diffusion), what would you suggest?
Thanks again,
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: 15 Mar 1999 14:56:39 -0500
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>Patrick Juola wrote:
>>
>
>> Well, it's a good measure of the amount of computational machinery
>> required to obtain a string as long as you don't care how long it
>> takes.
>>
>> If you don't regard it as a good definition, then don't use it.
>
>I am afraid that the term 'computational machinery' is fairly vague.
Well, if you want the formal definition, do the math. 8-)
>Let me venture to express my personal 'sentiment' to concepts of
>Kolmogorov type. We could in analogous way attempt to tackle the
>problem of determining the strength of an encryption algorithm:
>Define the strength of an algorithm to be the shortest average
>time to break that algorithm. This measure could certainly be
>useful for comparing algorithms. But there is no way to determine
>that 'shortest average time' just as there is no way to determine
>the length of the shortest program for a given sequence. Both
>are in my opinion useless but merely do a 'transformation' of
>a problem without actually solving it at all.
Actually, this would be quite useful if you could get the amount
of theoretical support for this definition that K-complexity has
for it.
For example, there are some useful theorems available that state
that Kolmogorov complexity is universal (to within a constant)
irrespective of the particular implementation of a Turing Machine
you use, so, for example, you get the same complexity definitions
whether you're using a RAM or a pure Turing machine.
It would be both useful and interesting if you could show that,
for example, a particular class of encryption schemes requires the
same amount of computational effort to break irrespective of the
amount of cyphertext you have available -- or irrespective of
whether you've got plaintext/cyphertext pairs. Or a proof that
the solution to *this* encryption scheme is independent of
the solution to *that* one. All of which are available as analogues
for Kolmogorov complexity.
It sounds to me like you're whining that a hammer won't paint the
walls. Lots of people like hammers, lots of people use hammers,
and if you're trying to paint the wall with a hammer, don't blame
the designer of the hammer -- or the designer of the wall, for
that matter. If Kolmogorov complexity doesn't appear to solve the
problem you're interested in, then why the hell don't you get a
different tool?
-kitten
------------------------------
Date: Mon, 15 Mar 1999 17:28:58 -0700
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Test vectors for RC4
Right, while RC$ as a cipher has not yet been broken (so far as I know) the 40
bit rendition of RC4 with it's use of the MD5 password hash (modified) in Excel
and Word has recently bitten the dust.
See http://www.crak.com
JK
[EMAIL PROTECTED] wrote:
> In > Questions of your type is in general ill-posed. For an algorithm that
> > is broken, the question need not be asked; for an algorithm
> > that is not yet broken the strength can not be expressed because
> > there is no standard unit of strength of encryption algorithms to
> > measure that unambiguiously.
> >
>
> Yes, RC4 has not been broken, and no weaknesses have been reported yet. It
> seems quite strong. However it's slower then RC5/RC6, doesn't support block
> modes and has the same problems as the OTP. RC4 is ok if you use a salt
> though.
>
> Test vectors? Try:
>
> KEY = 00 00 00 00 00 00 00 00
> P = 00 00 00 00
> C = DE 18 89 41
>
> Tom
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
--
CRAK Software (Password Recovery Software)
Http://www.crak.com
[EMAIL PROTECTED]
602 863 9274 or 1 800 505 2725 In the USA
------------------------------
Date: Mon, 15 Mar 1999 17:41:12 -0700
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Test vectors for RC4
I have made this point before and I know that Bruce (Applied Cryptography)
Schneier disagrees with this point, but...
No matter what you are talking about, you are talking about MONEY. The real test
of any cipher is the cost of recovery of secret information from the encrypted
document made by a cryptosystem using the cypher.
You can talk bits of key and theoretical elliptic curve mumbo-jumbo until you are
blue in the face, the reality is: the steel clad super strong submarine sinks when
one tiny little hatch is left open.
The way to test a sub is to go full speed ahead, damn the torpedoes, and yell DIVE
DIVE DIVE...if there is a leak you will know about it soon...
In other words the way to test the strength of a cryptosystem is to use it to
protect something really valuable...or offer a big reward for recovery of the
enciphered information. The marketplace will take care of the rest!
Adios RC4 ...see http:/www.crak.com
JK
Mok-Kong Shen wrote:
> [EMAIL PROTECTED] wrote:
>
> > Yes, RC4 has not been broken, and no weaknesses have been reported yet. It
> > seems quite strong. However it's slower then RC5/RC6, doesn't support block
>
> In my opinon statements like 'it seems quite strong' don't convey
> much.
>
> M. K. Shen
--
CRAK Software (Password Recovery Software)
Http://www.crak.com
[EMAIL PROTECTED]
602 863 9274 or 1 800 505 2725 In the USA
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Secure Hash (shc.c)
Date: Mon, 15 Mar 1999 16:49:00 -0800
[EMAIL PROTECTED] wrote:
>
> > 66481 0.0040 80
> > 66538 0.0040 05
> > 66539 0.0040 02
> > 66601 0.0040 20
> > 66615 0.0040 01
> > 66740 0.0040 40
> > 66864 0.0040 10
> > 67048 0.0040 08
> > 67069 0.0040 04
> > 71501 0.0043 00
> >
>
> Would this mean that there are biases? Any clue why it's always towards zero?
> It's not linear (02 and 05 are at the top), but why zero?
Yes, it would mean there are biases toward producing more 0 bits than desired.
> Would you say my algorithm is not secure, but reasonably ok given it's speed?
No. If you want something fast and insecure, try a CRC. Having a hash
that superficially looks secure but isn't can be misleading to somebody
doing an implementation. If you need secure, use a hash that's been
tested by people who need good hashes to make their living.
> I would like to make another pass at it. I already posted my idea for SHC2
> (different diffusion), what would you suggest?
I'd suggest doing a bunch of mathematical analysis to determine the expected
effects, then doing a bunch of practical tests to see whether your expectations
of random output are met. You should read papers about popular hashes to
see why they were designed as they were, and how they were broken (e.g. MD4
and SNEFRU).
Designing a cipher or a hash by the kitchen sink method makes the analysis
very complicated. We're well advised to reread Knuth's "Seminumerical
Algorithms", wherein he points out that random number generators designed
randomly are typically poor. The same goes for ciphers and hashes.
To test the specific problem I seem to be seeing with your hash, you
could throw a lot of small random files at it, do a frequency count on
the output bytes (or nibbles, or smaller units), then calculate the
correlation coefficient between the Hamming weight of a byte and its
frequency in the table. The Hamming weight (number of 1 bits) of those
bytes above (in order from the top), are 1,2,1,1,1,1,1,1,1,0. In a well
distributed frequency count they would be randomly (but not uniformly)
spread from 0 to 8. This would reduce the problem I was seeing to a
single number you could use to reject designs that lost in this same way.
--
Jim Gillogly
Sterday, 24 Rethe S.R. 1999, 00:28
12.19.6.0.9, 4 Muluc 2 Cumku, Ninth Lord of Night
------------------------------
Date: Mon, 15 Mar 1999 15:52:59 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Self-executing encryption program
Mycroft wrote:
>
> Sundial Services wrote:
>
> > Mycroft wrote:
> > >
> > > "Bo Dömstedt" wrote:
> > >
> > > > [EMAIL PROTECTED] wrote:
> > > > >Does anyone know of an encryption program that creates self-executing
> > > > >decryption files, so you can send files to anyone who doesn't have the
> > > > >program, as long as they have a password?
> > >
> > > Pkzip has a "scramble" option and you can create self-extracting
> > > executables
> > > with it.
> >
> > [Snicker...] Do you know how long it actually takes to dismantle the
> > PKZip stream cipher? If you have the slightest idea of what as little
> > as 12 bytes of the original plaintext was, at any point in the
> > enciphered stream, then you can compute the internal key and recover the
> > information remarkably quickly. This fact is all-too-well known.
>
> Hmmmm....I don't recall the original poster asking for a "fool proof"
> self-extracting encrypted executable, just an example of ANY self-extracting
> ecrypted executable. If you have a better example, then post it. If not...
Gee, I didn't mean that post the way that it sounds on the re-reading!
Actually I hope there -is- a good self-extract tool that uses stronger
encryption than PkZip alone does, because I could definitely use it.
PKSFX (I still think they should have used the obvious "E" instead of
"F!") is a very useful utility if only it had adequate protection for
the data.
Sending PGP-encrypted files around is nice (albeit overkill), the only
trouble being that you have to posess PGP to use it. Lots of "install"
tools provide password-security, and this is what we are forced to do
now, but even a cursory examination of their files reveal that weak
cryptosystems (or in some cases, no cryptosystems!) are being used.
So I can't offer a better example but I'm sure hoping someone else
does. There is a market there. [P.S. My wish-list would be "it
requires nothing more than DOS to do the decrypt..."]
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: RSA in JavaScript?
Date: Tue, 16 Mar 1999 02:03:34 GMT
In article <7ck2bp$o51$[EMAIL PROTECTED]>,
<anonymous-remailer@[146.115.234.58]> wrote:
>---BEGIN ANONYMOUS REMAILING---
>Are there any implementations of RSA in JavaScript out there?
>---END ANONYMOUS REMAILING---
Low exponent encryption or signature verification would be reasonable
and not too hard to implement. Decryption and signing would be too
slow to deal with for most purposes. Key generation would be ridiculous.
In more recent Netscape browsers you could use the JDK 1.1 java bignum
class to do public key operations reasonably fast. In MSIE you can
make an ActiveX control that runs at full cpu speed. Normally these
things are considered evil, but if the user doesn't trust you s/he
shouldn't be using your RSA implementation no matter what language
it's written in, so it's not so unreasonable in that situation.
------------------------------
From: [EMAIL PROTECTED]
Subject: ANNOUNCING A TINY VERSION OF RIJNDAEL
Date: Tue, 16 Mar 1999 02:50:00 GMT
RIJNDAEL is a block cipher invented by Joan Daemen and Vincent
Rijmen in Belgium. It has been submitted to the AES competition, and is
believed to be one of the more promising entries. It is a non-Feistel
cipher based on matrix operations in GF(2^8). The best thing about
RIJNDAEL, however, is that it is not patented and the authors state
that it will never be so.
Several variants of the RIJNDAEL block cipher have been imcorporated
into a shell using CFB block chaining mode and coded in compact .ASM
form. The various routines have been checked against the original
RIJNDAEL output, and all programs seem to be working correctly. The
shell is based on Fauzan Mirza's TinyIdea program, with further size
optimization suggested by Mark Andreas.
The version called RIJNDAEL is completely compatible with the
original (when the original is used in CFB mode), and the RIJNDAEL S-box
is included in the code. The code, including this 256 byte table, requires
633 bytes of code. A second version, RIJNREAD, reads the S-box data from
a file named RJ, which must reside either in the current directory or in]
the root directory. The program requires 416 bytes. The third version,
called TINYRIJN, creats its own S-box, and uses right-shift of the rows
instead of left-shift, all of which make for a shorter program; only 382
bytes. All the versions are compiled for 128-bit block and key sizes,
but the code has been written to allow use of 128, 192, or 256-bit keys
and/or blocks by resetting the size variables and recompiling.
The distribution file can be downloaded at:
<a href="http://www.afn.org/~afn21533/rijndael.pgp"></a> or
<a href="http://members/tripod.com/~afn21533/rijndael.pgp"></a>
This distribution file contains all three versions mentioned above,
complete with source, listing, executable and documentation, along with
the RJ s-box file mentioned above. Since EAR applices, even thouth this
cipher was invented outside the US, they cannot be exported from here.
So the distribution file is encrypted with PGP -c conventional encryption
and you will need to send me your PGP public key (RSA only; I use 2.6.3a)
along with a statement of residence and citizenship in either the US or
Canada to get the decryption key.
Robert G. Durnal
Web pages at www.afn.org/~afn21533
and members.tripod.com/~afn21533
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
** 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
******************************
