Cryptography-Digest Digest #512, Volume #12 Wed, 23 Aug 00 05:13:01 EDT
Contents:
Re: New algorithm for the cipher contest ([EMAIL PROTECTED])
Re: Comment from Hardware Experts Please (Mack)
Re: 320-bit Block Cipher (Mack)
Need polynomials for 48 and 64-bit CRC ("Ken Christensen")
Re: SHA-1 program (cool!) (Mack)
Re: Decryption ("kihdip")
Re: SHA-2 name rumors (Mack)
Re: encryption scheme output - samples table? ("kihdip")
Re: The DeCSS ruling (Pekka =?iso-8859-1?Q?Ala=2DM=E4yry?=)
Re: Questions about stream cipher (Runu Knips)
Re: My unprovability madness. (Boudewijn Moonen)
Re: SHA-2 name rumors (Runu Knips)
Re: Re-using CD-R discs ("Paul Pires")
Testvectors for DES and 3xDES ("kihdip")
Dissapearing email (pratik khasnabis)
Re: How many bits of strength does the ZIP encryption have? (Roadkill)
Little help ("Sergio Arrojo")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: New algorithm for the cipher contest
Date: Wed, 23 Aug 2000 06:05:18 GMT
In article <8nvbik$1vq$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> look dopey, flipping bit 'i' of the input to a multiplication in Zn (n
> not prime) will not affect any bits prior (x < i). That demonstrates
> the very poor rate of diffusion.
> Even with the bit reversal there is a
> stronger bias towards upper words... Figure this out please.
>
This effect of multiplication is obvious. Since I began to develop this
cipher I was concerned about it. To achieve the difusion, we need not
only an auxiliar function (Mirror) but more than one round.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mack)
Date: 23 Aug 2000 06:23:06 GMT
Subject: Re: Comment from Hardware Experts Please
>My question is about performming a hardware multiplication in GF(2^n)
>modulo an appropriate primitive polynomial. Sorry if my questions
>seems vague, I am not a hardware expert.
>
>Generally I have two questions:
>
>1. Can it be done with relatively low amounts of hardware. I.e
>cheaper unit. Low power as well.
>
>2. Can it be done with a relatively high output rate. Relative to
>what I am not sure, i.e can it be done quickly? Say something close to
>nlog n steps?
lets see.
Note that Bits is a class
of bit strings with operation ^ and <<
and functions zero,bit and log 2
Bits mulpol(Bits X,Bits Y,Bits M)
{
int n,i;
Bits R;
n=M.log2();
R.zero();
for (i=0;i<N;i++)
{
if (Y.bit(i)) R=R^X;
X=X<<1;
if (X.bit(n)) X=X^M;
}
return R;
}
let me know if I have it wrong but that
seems like the algorithm to me.
for 64 bits it can be simplified
note that the highest bit of M is dropped
this assumes a type equivalent to U64
and corresponding operations
#define U64 unsigned long long
U64 mul64(U64 X,U64 Y,U64 M)
{
int i;
for (i=0;i<63;i++)
{
if ((Y&(((U64)1)<<i)!=0) R^=X;
if ((X&(0x8000000000000000))!=0) X=(X<<1)^M;
else X<<=1;
}
if ((Y&(0x8000000000000000))!=0) R^=X;
return R;
}
>
>I want to design a 128-bit block cipher using decorrelation in eight
>rounds, this requires a 64-bit GF multiply which is very costly in
>software. In hardware this cipher would require 1024 bits of SRAM but
>this could be fed into the unit any way (i.e fed into latches in the
>execution pipeline), and if the GF multiply is efficient in hardware
>then the cipher could be practical for real usage.
In hardware you have a trade off in speed and silicon usage.
you can use a single shift register (fixed shift) and one bit selector and
two xor units (both bit controlled) with a 6 bit counter.
or you can use 64 shift registers (fixed shift) and 64 xor units
all of them bit controlled and 64 polynomial division units.
Note that the polynomial division units take a LOT of silicon.
>
>Thanks,
>Tom
>
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Mack)
Date: 23 Aug 2000 06:48:42 GMT
Subject: Re: 320-bit Block Cipher
>>
>> The key setup is a bit awkward. A better method is
>> L2= L1 xor SHA(R1||K1||C1)
>> R2=R1 xor SHA(L2||K1||C2)
>> L3=L2 xor SHA(R2||K1||C3)
>>
>> where C1,C2, and C3 are constants. maybe strings of
>> digits from PI.
>>
>> It is the basic Luby-Rackoff design.
>>
>> This is reinventing the wheel but it is a sound design.
>
>Good idea I could do that.
>
>Normally I see something like that uses SHA to key a stream cipher...
>this is slightly more like a MDC cipher.
>
>Tom
>
>
One of the papers at FSE'96 used the comparison to MDC.
Faster Luby-Rackoff design by Stefan Lucks
His method used MD5 and RIPEMD but using slightly modified
versions of each.
An additional suggestion is changing K1 to 344 bits. This allows
one byte of PI to be used for each round without length restirction
or appending the length code.
Note that since you don't append the length code you have a class
of equivalent keys. Those with shorter lengths map to those of
longer lengths with zeros appended. This is not a real weakness.
.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: "Ken Christensen" <[EMAIL PROTECTED]>
Subject: Need polynomials for 48 and 64-bit CRC
Date: Mon, 21 Aug 2000 20:57:00 -0400
Hello, I am looking for references that describe good polynomials for 48 and
64 bit CRC. Are there polynomials for such large CRCs? I am experimenting
with using CRCs as a means of digesting large directory listing (e.g., for
sharing directory listings between caches). I am open to suggestions for
other hashing algorithms to quickly and easily (in both software and
hardware implementations) generate 48 and 64 bit hashes.
---
===============================================================
= Kenneth J. Christensen, Ph.D., P.E. (Assistant Professor) =
= Department of Computer Science and Engineering =
= University of South Florida =
= (813) 974-4761 =
= http://www.csee.usf.edu/~christen =
===============================================================
------------------------------
From: [EMAIL PROTECTED] (Mack)
Date: 23 Aug 2000 07:01:46 GMT
Subject: Re: SHA-1 program (cool!)
>>
>>
>
>I would suggest trying it on a different compiler and/or library. May be a
>problem with the library handling certain size files.
>
>
>Mack
>Remove njunk123 from name to reply by e-mail
>
>
>
>
Also check the method of appending the length code.
You may be overwriting data with the length or vice versa.
Or you may be overwriting the low 32 bits of the length with
the high 32 bits. Also possible is not shifting properly since
the 'normal' word size is 32 bits and the length is 64 bits
and expresses the total length of data in bits.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: "kihdip" <[EMAIL PROTECTED]>
Subject: Re: Decryption
Date: Wed, 23 Aug 2000 09:03:04 +0200
John Savard has an example that shows that you go backwards through the
computation to extract the plaintaxt from the ciphertext.
This seems very logical.
But with the Feistel structure in a decryptation, it seems that you do the
same computations as when you encrypt (except for using your keys
backwards).
Why does this work ?? Why isn't it necessary to go through the
function/s-boxes in the Feistel structure backwards when you decrypt ??
Has it something to do with the nature of the s-boxes/function inside the
Feistel structure ??
Kim
John Myre wrote in message
>One common trick is the "Feistal" structure, wherein you do a simple
>invertible modification of part of the block based on a value
>computed (in any complex way you like) from another part of the
>block and some key material. The usual block parts are halves.
>The usual "simple invertible modification" is just bitwise XOR,
>which is its own inverse.
>
>Then you move the parts around (e.g., swap halves) and repeat,
>until everything has been sufficiently mangled.
>
>For decryption, you do the same complex computation as you did for
>encryption, then invert the simple modification of part of the block.
>Of course, if you did several rounds for encryption, you do the
>rounds in the reverse order for decryption.
------------------------------
From: [EMAIL PROTECTED] (Mack)
Date: 23 Aug 2000 07:04:31 GMT
Subject: Re: SHA-2 name rumors
>SHA-1 provides 160 bits; isn't that enough? Seems like it will be good for
>decades to come.
>
>-*---*-------
>S.T.L. My Quotes Page * http://quote.cjb.net * leads to my NEW site.
>My upgraded Book Reviews Page: * http://sciencebook.cjb.net *
>Optimized pngcrush executable now on my Download page!
>Long live pngcrush! :->
>
There was a paper a while back that gave an estimate of ten years.
Due to the long time to standardize it would be good to get the
new standard ready before collision finding becomes practical.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: "kihdip" <[EMAIL PROTECTED]>
Subject: Re: encryption scheme output - samples table?
Date: Wed, 23 Aug 2000 09:19:08 +0200
Most encryption schemes result in a bitstream.
Even with blockciphers you're not able to tell if this is a 64 bit
blockcipher or a 128 bit blockcipher.
So a true ciphertext from fx. DES would be 100010101010001010....
But when the programmer chooses to display the output on your screen, he
normally changes the output to hex numbers.
But wheter the a,b,c,d,e,f are lower or upper case doesn't tell you anything
about the cipher.
In the history of cryptography you'll find schemes where you're able to get
an idea of what cipher is used (take morse or a simple A->K code), but in
modern cryptography you're not.
Kim
Detonate wrote in message <[EMAIL PROTECTED]>...
>I was wondering if anybody knows of any tables that show the outputs of a
>test string from various encryption schemes? For instance, the PC1
algorithm
>in the implementation i've seen always outputs in lowercase alpha
characters
>a through z , and one byte input becomes two output, so "hello" might
>encrypt to "dzeopwlemf". DES seems to be +number+number+number etc ...
>obviously there are many schemes that couldn't be identified visually by
>such characteristics or patterns, but others can - is there a table for
this
>somewhere?
>
>
>
------------------------------
From: Pekka =?iso-8859-1?Q?Ala=2DM=E4yry?= <[EMAIL PROTECTED]>
Subject: Re: The DeCSS ruling
Date: Wed, 23 Aug 2000 07:18:12 GMT
lcs Mixmaster Remailer wrote:
...
> A note: In the Europeon Union reverse-engineering is legal.
> The reverse engineering was not done in the United States.
In Finland reverse engineering of software if illegal. When I checked
the situation in the EU I found "391L0250 Council Directive 91/250/EEC
of 14 May 1991 on the legal protection of computer programs" which is
seeminly identical to that of Finland legistlation. So I dare to say
that it is illegal also in Europe. If I remember right this was the
reason for action of the Norvegian Police.
Ref: http://europa.eu.int/eur-lex/en/lif/dat/1991/en_391L0250.html
Decompilation
1. The authorization of the rightholder shall not be required where
reproduction of the code and translation of its form within the
meaning of Article 4 (a) and (b) are indispensable to obtain the
information necessary to achieve the interoperability of an
independently created computer program with other programs, provided
that the following conditions are met:
(a) these acts are performed by the licensee or by another person
having a right to use a copy of a program, or on their behalf by
a person authorized to to so;
(b) the information necessary to achieve interoperability has not
previously been readily available to the persons referred to in
subparagraph (a); and (c) these acts are confined to the parts of
the original program which are necessary to achieve
interoperability.
2. The provisions of paragraph 1 shall not permit the information
obtained through its application:
(a) to be used for goals other than to achieve the interoperability
of the independently created computer program;
(b) to be given to others, except when necessary for the
interoperability of the independently created computer program; or
(c) to be used for the development, production or marketing of a
computer program substantially similar in its expression, or for
any other act which infringes copyright.
--
mailto:[EMAIL PROTECTED] http://www.iki.fi/pam/
köyhdytetty uraani kyynelkaasu laukaisin Loviisa LSD Luonto-Liitto mafia
malaria marihuana Matts Dumell MC Finland Mika Marenk Mossad MP5 napalmi
MVR Mustavihreät Päivät neutroni Neuvostoliitto Olkiluoto Olli Mattila
------------------------------
Date: Wed, 23 Aug 2000 09:33:20 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Questions about stream cipher
[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]>,
> "Miki Watts" <[EMAIL PROTECTED]> wrote:
> > Hi!
> > I've got a few questions about stream ciphers:
> > 1. Are they faster (in general) than block ciphers?
>
> Yes, but they can have their own disadvantages.
>
> > 2. Where can i find a list of (more or less) secure stream ciphers?
>
> SEAL from IBM and RC4 from RSADSI are the best so far.
If one names RC4 'Arcfour', it can be used freely, because it is only
a trade secret (even if a secret isn't secret anymore if everyone knows
it) and a trademark.
> The prob with stream ciphers is that you can't use the same key twice,
> and in the case of RC4 random seeking is not possible in an encrypted
> stream.
This should read 'SEAL is the only stream cipher so far which is able
to do random seeking'. Well and you, Tom, had a design which tried the
same recently.
------------------------------
From: Boudewijn Moonen <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.physics
Subject: Re: My unprovability madness.
Date: Wed, 23 Aug 2000 09:37:20 +0200
Future Beacon wrote:
>
> What do you want math for? Does everybody have to do it your way?
>
That everybody does it his/her own way is not an alternative
either.
--
Boudewijn Moonen
Institut fuer Photogrammetrie der Universitaet Bonn
Nussallee 15
D-53115 Bonn
GERMANY
e-mail: [EMAIL PROTECTED]
Tel.: GERMANY +49-228-732910
Fax.: GERMANY +49-228-732712
------------------------------
Date: Wed, 23 Aug 2000 09:42:31 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: SHA-2 name rumors
"S. T. L." wrote:
> SHA-1 provides 160 bits; isn't that enough? Seems like it will be good for
> decades to come.
No.
A 160 bit hash length is in principle as secure as a
80 bit key size, because of the birthday paradox.
That is NOT enough for the decades to come.
And, btw, 160 bit is an ugly size. 128, 256 or
512 bit would IMHO be better.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Re-using CD-R discs
Date: Wed, 23 Aug 2000 00:40:32 -0700
Sark <[EMAIL PROTECTED]> wrote in message
news:39a2ec5c$0$62234$[EMAIL PROTECTED]...
> I have heard some rumours about being able to erase CD-R discs by baking
them in the oven. Someone said it was 220 degrees for 10 min. I tried it,
but it didn't work. Any suggestions?
>
> Sark
You were given an incomplete formula. They snipped off the last part that
says " Garnish with parsley and serve with red wine"
Paul
------------------------------
From: "kihdip" <[EMAIL PROTECTED]>
Subject: Testvectors for DES and 3xDES
Date: Wed, 23 Aug 2000 09:57:27 +0200
Has somebody knowledge of a site with testvectors for DES and 3xDES ??
Thanks
Kim
------------------------------
From: pratik khasnabis <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Dissapearing email
Date: Wed, 23 Aug 2000 08:24:08 GMT
Hi
I sometimes read this ng and I'm not a mathematician or cryptographer.As
a communication engg. I know a little about cryptography and is
interested in practical applications.Today I read the story about
dissapearing emails. I have included the hyperlinks at the end. I want
to know how is it possible by this technique to automatically send the
encrypted message to the Disappearing access server and get it
decrypted. How to prevent the message on screen to be copied and pasted.
I am not able to understand this technique. Can you help.
TIA
Pratik
http://www.cnn.com/2000/TECH/computing/08/22/disappearing.email.idg/index.html
http://www.disappearing.com/ --> see the product info .
------------------------------
Date: 23 Aug 2000 08:56:10 -0000
From: Roadkill <[EMAIL PROTECTED]>
Subject: Re: How many bits of strength does the ZIP encryption have?
Sundial Services wrote:
>
> Actually, Tim, about a year and a half ago I investigated the
> possibilities of cracking PKZip's cipher -without- knowing plaintext and
> actually succeeded in doing so from time to time, using a variation of
> the published known-plaintext attack.
>
> The essential observation that I made and was pursuing off-and-on is
> that the frequency characteristics (and a metric I called "bit density")
> in a compressed file are very, very predictable. You can readily tell
> if the data is compressed-anything or if random noise (a la
> cryptography) has been injected into it. And you can modify, relax,
> loosen the tests made by the published algorithm -- so that they are not
> looking for "exact" bytes in each of the 12 positions (say), but only
> "probable" ones.
>
> It helps considerably that most Zip files are -archives- containing
> dozens or even hundreds of members, all of which are likely to have
> similar frequency characteristics and sometimes even blocks of very
> similar data, especially in the first few hundred bytes.
Very interesting. So basically you are saying that compressing plain
text /before/ encrypting like PGP does isn't such a good idea after
all. I have to remember this.
THANKX (I find this a very good newsgroup to be lurking, I did a deja
search, and couldn't find anything on Digital Rights Management by
Microsoft. I think it sucks and it is security by obscurity, in fact I
will be credited by Marie-Jose Klaver in a dutch article tomorrow on
this. Here is the link to MuchoSucks
<http://www.microsoft.com/windows/windowsmedia/en/wm7/drm.asp>, I would
be pleased if this topic was discussed by professional like yourselves
or if I received a link on this by e-mail or in the group. TIA!).
Roadkill
--
"If you're so special, why aren't you dead" - Kim Deal
------------------------------
From: "Sergio Arrojo" <[EMAIL PROTECTED]>
Subject: Little help
Date: Wed, 23 Aug 2000 09:38:30 +0200
Reply-To: "Sergio Arrojo" <[EMAIL PROTECTED]>
Hi
I am an unexperienced student, so my question might be a bit stupid. I was
told to make some Software to implement elliptic curves over GF(2^m). I made
a very simple example with MATLab which was able to operate only with very
small numbers. Then I was told to translate to C and to simulate with
realistic values. The idea was to use a Linux compilator that enabled using
unlimited variables. Soon I saw that I would not be able to end this task. I
was told that this Software is actually quite difficult to design. Since I
(as dumb as I am) was able to make a simplified example that worked with
tiny numbers I assume that the tricky thing is to generate the curves (and
to simulate ECC) in a reasonable amount of time (less than 10^99 centuries)
when operating with really big numbers. Am I right, or am I missing
something here?
Thanks
Sergio
------------------------------
** 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
******************************
