Cryptography-Digest Digest #562, Volume #9 Wed, 19 May 99 02:13:02 EDT
Contents:
Hash Program (Jim Dunnett)
Re: How to understand/program more advanced crypt. ("Matthew Bennett")
Re: Can Somebody Verify My DES execution? (Richard Outerbridge)
Re: Hello I am paper, please read me. ([EMAIL PROTECTED])
remailers ([EMAIL PROTECTED])
Re: remailers (Paul Rubin)
Re: Computer-generated random numbers (was Re: Magic) ([EMAIL PROTECTED])
Re: symmetric boolean functions ("Russell Easterly")
Re: prime numbers and the multplicative inverse (Boris Kazak)
Re: Hash Program (Boris Kazak)
Need to design basic authentication system ("Tim Mavers")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Jim Dunnett)
Subject: Hash Program
Date: Tue, 18 May 1999 20:40:09 GMT
Reply-To: Jim Dunnett
Anyone know from where (or if) I can obtain an
MSDOS/Windows executable to 'distill' hardware
produced bits by 'hashing'?
--
Regards, Jim. | Gouverner, c'est choisir.
olympus%jimdee.prestel.co.uk |
dynastic%cwcom.net | - Duc de L�vis 1764-1830
nordland%lineone.net |
marula%zdnetmail.com |
Pgp key: pgpkeys.mit.edu:11371
------------------------------
From: "Matthew Bennett" <[EMAIL PROTECTED]>
Subject: Re: How to understand/program more advanced crypt.
Date: Tue, 18 May 1999 23:16:39 +0100
This might be an interesting, and simple, one to try out (I've yet to code
it myself though..)
TEA (Tiny Encryption Algorithm)
http://www.ftp.cl.cam.ac.uk/ftp/papers/djw-rmn/djw-rmn-tea.html
It includes source code and some strength analysis.
/\/\/\//
Mika Stenberg wrote in message <[EMAIL PROTECTED]>...
>Hi,
>
>Im really new into Cryptography, and I was wondering if someone could
>explain (Maybe with an example program of C / Java / Pascal) how to
>code a little more advanced crypt. program. Advanced would mean
>something else than just replacing chars with another ones.
>
>Mika
>
>
------------------------------
From: [EMAIL PROTECTED] (Richard Outerbridge)
Subject: Re: Can Somebody Verify My DES execution?
Date: Tue, 18 May 1999 18:39:32 -0400
1999-05-18 18:20:01 EDT
In article <7hrk7q$8do$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Thomas Pornin) wrote:
>The DES standardization paper should include some test vector. There is
>also an implementation in Bruce Schneier's "Applied Cryptography" ; be
>sure however that you use the second edition, since the first is a bit
>buggy (the P permutation is reversed, for instance). It contains the
>following test vector : [snip]
Yeah, that's mine. As has been mentioned in this thread a single test
vector only gives a first-order assurance of correctness, but I'm pretty
sure that the AC2 code is correct. Other first-order tests, remarkably
useful in tracking down bugs, are:
a) verify that the weak-key property holds (encrypt twice using the same
weak key equals pt for all four weak-keys);
b) verify that the semi-weak-key property holds (encrypt under key 1,
decrypt under key 2, equals pt, for all six pairs of semi-weak-keys).
NIST has also published a test suite which can identify bitwise flaws
in various parts of an implementation, and Ron Rivest came up with an
abbreviated test which (if passed) verifies correctness for almost all
single-bit errors.
If anyone would like arbitrary test-vector triples from an implementation
I'm pretty sure of, feel free to ask.
outer
--
"Just an eccentric soul with a curiosity for the bizarre."
<[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Hello I am paper, please read me.
Date: Tue, 18 May 1999 23:34:36 GMT
In article <7hovbq$9dp$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> > I thought the shuffling was supposed to produce a pseudo random
> > permutation. Did you actually look at the decks after 8 or 16
> > shuffles? You certainly don't need any shuffling bisectors to
> > notice the patterns.
> >
>
> The problem is that trying to shuffle the deck with only one value
will
> always leave patterns. RC4 over comes this by using the deck as
> paramters and the key (over and over).
I can't tell what you're talking about. What does shuffling with
only one value mean, and what does it have to do with your keying
procedure? It looks like your initial key set-up shuffles once
for each byte of key. Try it with 8 or 16 bytes.
Why do you think RC4 ever had any such problem to overcome?
--Bryan
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Subject: remailers
From: [EMAIL PROTECTED]
Date: 18 May 1999 21:40:55 -0400
I just sent a series of tests through several anonymous remailers;
most of them had a latency of several days. Is this a built-in latency
to frustrate traffic analysis, or are they just slow? Are there any
fast remailers? Is there a more appropriate venue for asking this than
sci.crypt?
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: remailers
Date: Wed, 19 May 1999 03:07:42 GMT
In article <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>I just sent a series of tests through several anonymous remailers;
>most of them had a latency of several days. Is this a built-in latency
>to frustrate traffic analysis, or are they just slow? Are there any
>fast remailers? Is there a more appropriate venue for asking this than
>sci.crypt?
Some remailers have a parameter so you can say how much average delay
you want. Others are fancier, breaking the incoming message into pieces
and sending the pieces (encrypted) to other remailers. The idea of
delays is to not send out messages in the same order that they arrived.
If you want a remailer that doesn't delay, try www.replay.com.
Keep in mind that this increases vulnerability to traffic analysis.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: rec.arts.sf.science
Subject: Re: Computer-generated random numbers (was Re: Magic)
Date: Wed, 19 May 1999 04:36:14 GMT
In article <7hnr9h$4sh$[EMAIL PROTECTED]>,
"Riboflavin" <[EMAIL PROTECTED]> wrote:
> [crossposted to sci.crypt]
> Frank Palmer wrote in message <7hmo5v$qeq$[EMAIL PROTECTED]>...
> >: [EMAIL PROTECTED] (Frank Palmer) writes:
> >: > Start with text, rotate each byte, XOR with the next byte;
> >: > repeat nine times. Result, random bytes.
No, any algorithm like this, even applied an infinite
number of times, may be subject to attack. You need
to at least add a hashing algorithm that has some
known hard core bits that can be used for
true randomness. Hard core bits are those bits produced
by a hash or cipher for which obtaining any statistical
information about the bits is equivalent to breaking
the cipher.
XOR has no hard core bits. MD5 would be a better
choice, though I'm not up on the latest literature
regarding whether anyone has proven the existence of
or found any specific hard core bits in the output
of MD5 or SHA-1.
- Jeff
--
Author, Programming Mobile Objects with Java
http://www.DistributedObjects.com
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: "Russell Easterly" <[EMAIL PROTECTED]>
Crossposted-To:
sci.chem,sci.econ,sci.image.processing,sci.electronics.design,sci.physics,sci.physics.fluid-dynamics,sci.math
Subject: Re: symmetric boolean functions
Date: Tue, 18 May 1999 22:10:22 -0700
Ted W. <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> One example and quite useful function is the parity function.
> It is one iff an odd number of its arguments are 1.
> It is used to for error checking in communications.
Wouldn't AND and OR be shift invariant?
>From the description they might also be "symmetric".
Russell
-2 many 2 count
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Subject: Re: prime numbers and the multplicative inverse
Date: Tue, 18 May 1999 22:35:36 -0400
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
>
> I haven't been able to find an answer to this question. Why does IDEA
> use a prime field for it's multiplication?
>
> Does the field need to be prime to have a multiplicative inverse?
>
> Tom
> --------------------------
The multiplication in IDEA is modular mod.65537 (2^16+1), but one
can do multiplication mod.any other number. In particular, (2^32+1) is
a very promising modulo for cryptographic applications.
The advantage of modulo being a prime number boils down to the fact
that *any* number in the range 1-65536 has a multiplicative inverse if
you use the multiplication mod 65537. This is not true for (2^32+1),
because this is a composite number =6700417*641, and multiples of 641
and of 6700417 do not have multiplicative inverses.
The consequence is that if your *round key* used for modular
multiplication mod.(2^32+1) happens to be one of these multiples,
decryption becomes impossible - there is no multiplicative inverse to
decrypt. This is why in IDEA any number can be used as a round key,
but for a cipher based on multiplication mod.(2^32+1) the key scheduling
must have a way to avoid generating the above mentioned multiples.
Actually this is quite easy to do, but this is already an answer to
another question.
Best wishes BNK
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Subject: Re: Hash Program
Date: Tue, 18 May 1999 22:42:51 -0400
Reply-To: [EMAIL PROTECTED]
Jim Dunnett wrote:
>
> Anyone know from where (or if) I can obtain an
> MSDOS/Windows executable to 'distill' hardware
> produced bits by 'hashing'?
>
> --
> Regards, Jim. | Gouverner, c'est choisir.
> olympus%jimdee.prestel.co.uk |
> dynastic%cwcom.net | - Duc de L�vis 1764-1830
> nordland%lineone.net |
> marula%zdnetmail.com |
> Pgp key: pgpkeys.mit.edu:11371
==================================
Try this, it works under DOS, reads a file, writes a file.
This proposed function is based on multiplication
(mod 2^32+1) with two "twists". First, however, some
background information.
The function uses 256 different modular multipliers
derived from one initial number "SEED". This number is
0x6A09E667, which happens to be the first 8 hex digits of
SQRT(2), less initial 1. The use of this number should
dispel any suspicions about a "trap door" built into SEED.
The multipliers themselves are simply the powers of SEED,
so that Mult[k] = SEED^(k+1), this way SEED^0 = 1 is
avoided, we don't want any trivial multipliers. Also, this
number produces a 33,502,080 long cycle of its powers
until it comes back to 1, so there are no duplicate
multipliers in the array.
The multiplier array can be precomputed in advance or
can be filled at the program start. The latter case saves
some code (no need for a big data table), but implies a
time penalty of 255 modular multiplications.
Original message is divided into segments of the size
twice that of the final hash, e.g. if the final hash will
be 160 bit, the segments will be 320 bit each. The size of
the hash and segments is #defined by the HASHBLOCKSIZE
constant and can be altered according to need.
Now about the "twists". The first twist boils down to
the plaintext-dependent choice of the multiplier. If a
certain 4-byte number is going to be hashed, the
corresponding multiplier is chosen from the table with the
index I = XOR(all 4 bytes of the number).
Second twist regards the progression along the block.
After the multiplication, when the bytes of the product
are returned to their places and it is time to proceed
with the subsequent multiplication, the two LS bytes of
the previous product become the two MS bytes of the new
number to be multiplied, and two adjacent bytes of
the plaintext are appended to them in order to make this
new 32-bit number. When the end of the block is reached,
the index wraps cyclically over the BlockLength.
For each block, there are three rounds (for those
paranoid among us, there is a #define, where one can
change the ROUNDS constant to whatever desired).
Graphically a round can be visualized in the
following sketch:
( the index is circular mod "BlockLength" )
___________________________________________________________
1-st multiplication
XXXXxxxxxxxxxxxxxxxxxxxxxxxxxxxx
( XXXX - 32-bit number to multiply, multiplier
index is computed as X^X^X^X)
___________________________________________________________
2-nd multiplication
ppPPXXxxxxxxxxxxxxxxxxxxxxxxxxxx
(ppPP - product of the first multiplication,
PPXX - 32-bit number to multiply, multiplier
index is computed as P^P^X^X)
___________________________________________________________
3-d multiplication
ppppPPXXxxxxxxxxxxxxxxxxxxxxxxxx
( PPXX - 32-bit number to multiply, multiplier
index is computed as P^P^X^X)
...........................................................
Last multiplication
XXppppppppppppppppppppppppppppPP
( The index is cyclically wrapped over -
PPXX - 32-bit number to multiply, multiplier
index is computed as P^P^X^X)
___________________________________________________________
This arrangement allows an ultra-rapid propagation
of all changes across the entire block - there is complete
avalanche after the 2-nd round and then after each
subsequent round.
It should be also noted that this arrangement
effectively molds the entire hash into an inseparable
entity, where the junctions between the adjacent bytes and
words don't exist any more, they are all blurred by
overlapping and by cyclical wrapover of the index. This
strongly discourages any attacks based on different
behavior of the distinct bytes and words during hashing.
In this function the entire hash is just a circular
sequence of bits without beginning or end, without the
junctions between bytes or words, without any realistic
possibility to trace the output changes back to the changes
in any particular word or byte. The cryptanalyst would
either be forced to attack the hash as a whole (128 or
even 256 bits), or just give up, which I hope will
precisely happen.
After 3 rounds, the new subsequent block is read from
the message and XOR-ed with the hash obtained in the previous
cycles. Then the hashing procedure repeats again for 3
rounds, and so on until the last message block is read.
If the last message block is shorter than needed, it is
padded with 0-s. Thereafter one more block is added to the
hash, containing the full message length as a 64-bit binary
number padded with 0-s. The final operation XOR-s the two
halves of the hash buffer, producing the output hash value.
Since in each multiplication step the multiplicand is
replaced with the product, there is no practical way of
reconstructing the multiplier index (other than computing
multiplicative inverses for all 256 multipliers and testing
the product to find out the match for the index used,
however, the final XOR-ing defeats this option).
Initially the hash buffer contains either 0's or an
appropriate IV. No hashing is done on this value, the first
message block is just XOR-ed into the hash buffer.
If the secret key will be used as the IV, the function
will produce a MAC.
The program takes the filename from the simple dialog
and writes the hash into a new file with the name of the
original file and extension "h32".
The source code was compiled under Borland C++ 4.52
and should compile under any ANSI-compliant C compiler.
The routines for breaking and making the 32-bit integers
from 4 bytes should assure identical results on both big-
endian and little-endian platforms (not tested).
No attempt has been made in order to optimize the
program in any way. After all, it is supposed to be just
a working model, not a racing car. One simple possible
optimization might reverse the direction of scanning
over the "text" block for little-endian Intel processors.
Any comments would be appreciated.
/********************* Start of code ************/
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#define byte unsigned char
#define word16 unsigned int
#define word32 unsigned long int
#define LO 0x0000FFFFUL
#define HI 0xFFFF0000UL
#define HASHBLOCKSIZE 16
#define ROUNDS 3
#define SEED 0x6A09E667UL /* Modular Multiplier seed */
/* First 8 hex digits of SQRT(2), less initial 1 */
/* variables */
word32 mult[256]; /* multiplier array */
word32 message_length; /* size of input file */
int end_of_file;
byte inbuffer[2*HASHBLOCKSIZE], outbuffer[HASHBLOCKSIZE];
byte text[2*HASHBLOCKSIZE]; /* the working array */
/*file handling functions*/
char read_char_from_file(FILE *fp);
void read_block_from_file(FILE *fp);
void write_char_to_file(char data,FILE *fp);
/* Functions */
word32 Mul (word32 x, word32 y) /* Returns (x * y) mod
(2^32+1) */
/* For the purposes of this algorithm 0 =
2^32 */
/* Modular Multiplication "CORRECT BUT SLOW" (mod 2^32+1)
If your compiler does not handle the "double long"
integers (64 bit), you have to split the 32-bit words
into 16-bit halves, multiply them, then juggle the
intermediate products until you get the correct result.
*/
{
word32 t[4]; word16 u[2], v[2];
if (x == 0) return (1 - y);
if (y == 0) return (1 - x);
u[0] = (word16)(x & LO);
v[0] = (word16)(y & LO);
u[1] = (word16)((x >> 16) & LO);
v[1] = (word16)((y >> 16) & LO);
t[0] = (word32) u[0] * (word32) v[0] ;
t[1] = (word32) u[1] * (word32) v[0] ;
t[2] = (word32) u[0] * (word32) v[1] ;
t[3] = (word32) u[1] * (word32) v[1] ;
/* intermediate 32-bit products */
t[3] = t[3] + ((t[1] >> 16) & LO)
+ ((t[2] >> 16) & LO);
/* no overflow possible here */
t[1] = (t[1] & LO) + (t[2] & LO)
+ ((t[0] >> 16) & LO);
/* collect them all in t[1]. Overflow into the
17-th bit possible here */
t[0] = (t[0] & LO) + ((t[1] << 16) & HI);
t[3] = t[3] + ((t[1] >> 16) & LO); /* add eventual overflow */
return (t[0] - t[3] + (t[3] > t[0]));
} /* Mul */
#define MUL(x,y) (x=Mul(x,y))
void MultSetup (word32 *mul)
{
int k;
*mul = SEED; /* Initialize multiplier array */
for (k = 1; k < 256; k++)
{
*(mul+k) = *(mul+k-1); /* Copy next <- previous */
MUL (*(mul+k),SEED); /* Subsequent power */
}
} /* MultSetup */
void DissH1( word32 H, byte *D )
/*
Disassemble the given word32 into 4 bytes.
We want it to work on all kinds of machines,
Little-Endian or Big-Endian.
*/
{
word32 T ;
T = H ;
*D++ = (byte)((T & 0xff000000UL) >> 24) ;
*D++ = (byte)((T & 0x00ff0000UL) >> 16) ;
*D++ = (byte)((T & 0x0000ff00UL) >> 8) ;
*D = (byte) (T & 0x000000ffUL) ;
} /* DissH1 */
word32 MakeH1( byte *B )
/*
Assemble a word32 from the four bytes provided.
We want it to work on all kinds of machines,
Little-Endian or Big-Endian.
*/
{
word32 RetVal, temp ;
temp = *B++ ;
RetVal = (temp << 24) ;
temp = *B++ ;
RetVal += (temp << 16) ;
temp = *B++ ;
RetVal += (temp << 8) ;
RetVal += *B ;
return RetVal ;
} /* MakeH1 */
void Scramble (void) /* This subroutine scrambles the "text" block */
/* It uses the global variables */
/* mult[], text[] and inbuffer[] */
{
int i,k,m;
word32 temp1, temp2;
/* XOR-ing the input into the text array */
for (m=0; m < 2*HASHBLOCKSIZE; m++) text[m] ^= inbuffer[m];
/* Now we can start squashing the block */
for (m=0; m<ROUNDS; m++)
{
for (k=0; k<2*HASHBLOCKSIZE; k+= 2)
{
/* Build a 32-bit multiplicand and multiplier index */
/* We want this to produce same results on big-endian
*/
/* and little-endian machines alike */
temp2 = text[k % (2*HASHBLOCKSIZE)] ; /* Essentially this
procedure */
i = (int)temp2; /* is identical to MakeH2
function */
temp1 = (temp2 << 24) ; /* However, it is
impossible to use */
temp2 = text[(k+1)%(2*HASHBLOCKSIZE)] ; /* MakeH2 function
directly, because */
i ^= (int)temp2; /* the loop index must be
wrapped */
temp1 += (temp2 << 16) ; /* mod 2*HASHBLOCKSIZE, and
also the */
temp2 = text[(k+2) % (2*HASHBLOCKSIZE)] ; /* multiplier index is
computed, */
i ^= (int)temp2; /* which is not provided in
MakeH2 */
temp1 += (temp2 << 8) ;
temp1 += text[(k+3) % (2*HASHBLOCKSIZE)] ;
i ^= (int)temp2;
/* Get the modular product into "temp1" */
MUL(temp1, mult[i]);
/* Return the bytes where they belong */
text[k % (2*HASHBLOCKSIZE)] = (byte)((temp1 & 0xff000000UL) >>
24) ;
text[(k+1) % (2*HASHBLOCKSIZE)] = (byte)((temp1 & 0x00ff0000UL) >>
16) ;
text[(k+2) % (2*HASHBLOCKSIZE)] = (byte)((temp1 & 0x0000ff00UL) >>
8) ;
text[(k+3) % (2*HASHBLOCKSIZE)] = (byte) (temp1 & 0x000000ffUL) ;
}
}
} /* Scramble */
char read_char_from_file(FILE *fp)
{
char temp=0;
message_length++;
if ((fread(&temp,sizeof(char),1,fp))!=1)
{
end_of_file=1;
message_length--;
}
return (temp);
} /* read_char_from_file */
void read_block_from_file(FILE *fp)
{
int i;
for (i=0; i<2*HASHBLOCKSIZE; i++)
{
inbuffer[i]=read_char_from_file(fp);
}
} /* read_block_from_file */
void write_char_to_file(char data,FILE *fp)
{
if ((fwrite(&data,sizeof(char),1,fp))!=1)
{
printf("Fatal Error writing output file!!!\n");
exit(-1);
}
} /* write_char_to_file */
void main()
{
FILE *in,*out;
char infile[100], outfile[100], *dot;
int k;
/* Opening files */
printf("\nEnter input filename:");
gets(infile);
if ((in=fopen(infile,"r+b"))==NULL)
{
printf("\nError opening input file: %s\n",infile);
exit (-1);
}
strcpy(outfile,infile);
dot=strrchr(outfile,'.'); dot++;
*dot++='h'; *dot++='3'; /* Changing file extension */
*dot++='2'; *dot='\0'; /* to .h32 */
if ((out=fopen(outfile,"w+b"))==NULL)
{
printf("\nError opening output file: %s\n",outfile);
exit(-1);
}
printf("\nOutput file is: %s\n",outfile);
/* Setting up the multipliers */
MultSetup(mult);
/* Clearing the text buffer */
for (k=0; k<2*HASHBLOCKSIZE; k++) text[k]=0;
/* Reading and squashing the input file */
while(end_of_file != 1)
{
read_block_from_file(in);
Scramble();
}
/* Building up and squashing the final block */
for (k=0; k<4; k++) inbuffer[k]=0;
DissH1(message_length, (inbuffer+4));
for (k=8; k<2*HASHBLOCKSIZE; k++) inbuffer[k]=0;
Scramble();
/* Building and writing the final hash */
for (k=0; k<HASHBLOCKSIZE; k++)
outbuffer[k] = text[k]^text[k+HASHBLOCKSIZE];
for (k=0; k<HASHBLOCKSIZE; k++)
{
write_char_to_file(outbuffer[k],out);
}
fclose(in); fclose(out);
}
------------------------------
From: "Tim Mavers" <[EMAIL PROTECTED]>
Subject: Need to design basic authentication system
Date: 13 May 1999 07:41:09 -0500
For a project I am working on, I need to design (and implement) a basic,
secure user-authentication system that will allow a user on a client machine
log into a "server" via a name and password.
What is the best way of doing this? I was thinking of a challenge-response
system, but am not sure how to code one (that is relatively secure). I
have read that Kerberos is the perferred method these days. Is that simple
(and free) to implement?
I understand that making a completely secure system for this is not
something that is "simple". I don't really need it to be 100% safe, just
relatively safe so someone can't break the system within a few days.
Thanks
------------------------------
** 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
******************************
