Cryptography-Digest Digest #132, Volume #14 Fri, 13 Apr 01 03:13:00 EDT
Contents:
Re: Request comment on a new cipher design ("Scott Fluhrer")
Re: RSA modulus size and bits (Chenghuai Lu)
Re: How good is steganography in the real world? ("Douglas A. Gwyn")
Re: Black & white .gifs? ("Douglas A. Gwyn")
Re: Ethernet & Encryption ("Trevor L. Jackson, III")
Re: Request comment on a new cipher design ("Joris Dobbelsteen")
Re: Request comment on a 'new' cipher design (update) ("Joris Dobbelsteen")
Re: Is this a block cipher? ("Joris Dobbelsteen")
----------------------------------------------------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Request comment on a new cipher design
Date: Thu, 12 Apr 2001 19:23:57 -0700
Joris Dobbelsteen <[EMAIL PROTECTED]> wrote in message
news:9b3jb4$t7s$[EMAIL PROTECTED]...
> As I'm quite new to cryptography, I didn't was so stupid not to read some
> literature.
Actually, if you're quite new to cryptography, going off and designing block
ciphers without knowing what you are doing is not the way to start...
> John Saverd's web site was quite good, however I got lost in the
> descriptions some times.
>
> If this document in in worse english, sorry, mine just isn't better. Still
I
> would expect you could make some sense from it, otherwise, complain...
>
> However to the point, this is a cipher with a 128-bit block that looks a
> hole lot like IDEA (as you will see when you create a little drawing). I
> expect this on the be faster on the appropirate hardware. This one looks
> quite good to me and not just like a piece of crap, at least, I hope.
>
> It uses <r> rounds, where r is an integer always > 0.
> The key schedule is ommited, as it's not designed yet, and needs to
prevent
> the use of weak keys that are very well possible.
>
> The cipher uses x86 byte order (little-endian?)
>
> Well, now the description:
>
> Note:
> XOR is XOR
> + is addition with carries
> * is multiplication
> ^ is power
> mod is modulo
> << shift left
> >> shift right
> |<< rotate left
> >>| rotate right.
> (quite logic, except rotates/shifts)
>
> k(x) are x 32-bit subkeys, where x >= 0.
>
> =========== Initial steps:
> Divide the 128-bit block into 4 32-bit blocks: A, B, C and D. Where A is
the
> least significant and D the most significant.
>
> =========== Round, r denotes round number and always > 0 (thus starts at
1).
> n = 9(r-1) ; used for the key
>
Possible differential: what if:
A' - A = 13
B = B'
C = C'
D' - D = 1
> A = A + K(n) mod 2^32
> B = B + K(n+1) mod 2^32
> C = C + K(n+2) mod 2^32
> D = D + K(n+3) mod 2^32 ; mixing up, against linearity with
> additions.
Differential unchanged.
>
> E = A XOR C
> F = B XOR D ; Remember IDEA???
E' - E = 13
F' - F = 1
both with some reasonable probability (2**-5???)
>
> L = E + (F << 32) ; 2^64+13 smallest prime > 2^64.
> L = ( L * ( K(n+4) + ( K(n+5) << 32 ) ) mod (2^64+13) ) mod 2^64
L = L'
> L = ( L + ( K(n+6) + (K(n+7) << 32) ) ) mod 2^64
> E = L mod 2^64
> F = L >> 32 ; somwhat different.
E = E'
F = F'
>
> A = A XOR F ; IDEA here too...
> B = B XOR E
> C = C XOR F
> D = D XOR E
A' - A = 13
D' - D = 1
again, with some reasonable probability, possibly 2**-5
>
> L = B + (C << 32)
> L = L |<< ( 20 + ( k(n+8) mod 2^5 ) ) ; Rotate here...
> B = L mod 2^64
> C = L >> 32
These do not affect the differential
>
>
> ======= Do some more rounds =======
>
> =============== End transformation
> n = 9r ; (r is number or rounds)
> E = A mod 2^16
> F = A >> 16
> G = B mod 2^16
> H = B >> 16
> I = C mod 2^16
> J = C >> 16
> K = D mod 2^16
> L = D >> 16
>
> E = ( ( E * Low(k(n)) ) mod 2^16+1 ) mod 2^16
> F = ( ( F * High(k(n)) ) mod 2^16+1 ) mod 2^16
> G = ( ( G * Low(k(n+1)) ) mod 2^16+1 ) mod 2^16
> H = ( ( H * High(k(n+1)) ) mod 2^16+1 ) mod 2^16
> I = ( ( I * Low(k(n+2)) ) mod 2^16+1 ) mod 2^16
> J = ( ( J * High(k(n+2)) ) mod 2^16+1 ) mod 2^16
> K = ( ( K * Low(k(n+3)) ) mod 2^16+1 ) mod 2^16
> L = ( ( L * High(k(n+3)) ) mod 2^16+1 ) mod 2^16
>
> A = E + (F << 16)
> B = G + (H << 16)
> C = I + (J << 16)
> D = K + (L << 16)
This end transformation doesn't disguise if B=B', C=C' originally
>
> ================== Functions
> Low(x)
> { Return x mod 2^16 }
> High(x)
> { Return x >> 16 }
>
>
> ================= Possible Weaknesses:
> * Weak keys as in IDEA. Key Schedule is to be designed, should solve this.
> * 64-bit multiplication leaks 12 values: 2*12=24 values, some less than 5
> bits, so I name it 5 bits for ease.
>
> ================== Possible Strengths:
> * Fast propagation of bit changes
> * addition after 64-bit multiplication to compensate bit loss in
> multiplication
> * All for quarters manipulated at once.
> * No explicit changes of B and C, but using a bit rotate.
> * Last pair of 16-bit multiplications that are revertable. Doesn't get
very
> high security.
> _Probably_ good security against DC and LC. I do expect that...
And why do you expect that???
>
> ================= Key Schedule
> To be designed. Should prevent weak keys form going to be used in the
> routine. I was aiming for a 128-bit to 256-bit or larger key. Hope someone
> can create a routine here that prevents weak keys and supports any input
> key.
>
> ================= Rounds expected
> 8 rounds is expected to be sufficient.
>
>
>
> - Joris
>
>
------------------------------
From: Chenghuai Lu <[EMAIL PROTECTED]>
Subject: Re: RSA modulus size and bits
Date: Thu, 12 Apr 2001 22:42:26 -0400
"Michael J. Fromberger" wrote:
>
> In <9b4nck$hvu$[EMAIL PROTECTED]> "Full Name" <[EMAIL PROTECTED]> writes:
>
> >What does one exactly mean by a 1024-bit RSA modulus? More precisely,
> >must such a modulus have its 1024th bit necessarily set to 1? If not,
> >how much leeway does one have when choosing a 1024-bit modulus? That
> >is, how many leading zero bits is one to tolerate?
>
> Hi there,
>
> The term "a 1024-bit RSA modulus" means "an integer with 1024
> significant bits which is the product of two large prime integers."
> Typically, one might pick two 512-bit primes.
>
> If the 1024th bit (assuming you number bits from 1) is zero, then
> there are at most 1023 significant digits. So, if you are speaking
> precisely, then yes, such a modulus must have its 1024th bit set to 1.
> You cannot tolerate any leading zero bits if you want to retain the
> property that your modulus has 1024 significant bits.
>
> (Actually, you can think of any integer as having an infinite number
> of leading zero bits to the left of the most significant 1).
>
> Cheers,
> -M
>
> --
> Michael J. Fromberger Software Engineer, Thayer School of Engineering
> sting <at> linguist.dartmouth.edu http://www.dartmouth.edu/~sting/
>
> Don't steal. The Government hates competition.
I think, the 1024th bit of modulus must be 1 because the modulus is the
multiplication of two prime numbers( they are odd ).
--
-Chenghuai Lu ([EMAIL PROTECTED])
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: How good is steganography in the real world?
Date: Fri, 13 Apr 2001 04:28:48 GMT
Mok-Kong Shen wrote:
> I think it may be noted that 'spams' is a relative notion.
Our reference point is the charter of the newsgroup.
> ... If the rate of the hidden bits is low enough, then the
> method I suggested in 'Steganography with ASCII text files'
> in sci.crypt, 11th Feb, could be advantageously applied.
But if the "carrier" is posted only for the purpose of
carrying a steganographic signal, then the posting is
truly "noise" for the vast majority of newsgroup readers.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Black & white .gifs?
Date: Fri, 13 Apr 2001 04:31:41 GMT
Jim Gillogly wrote:
> Paul Thomas wrote:
> > why not just take any old regular pictures you got lying around ...
> This is a much better idea. ...
However, most stego of this kind requires that the recipient also
have access to the reference signal (original image). So the
pictures can't just be lying around, they have to be in a public
place. Maybe on www.heartbreaker.com?
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Ethernet & Encryption
Date: Fri, 13 Apr 2001 05:14:29 GMT
Latyr Jean-Luc FAYE wrote:
> Dear all,
>
> You will find below the report of an assignement I had done.
> I would like to have your comments on the solution I proposed on DES and
> RSA, the weakness of the system and the improvements that can be made.
>
> Thanks in advance.
>
> Regards
>
> Jean-Luc
Two brief comments:
First, you have not addressed the possibility of replay or denial-of-service
attacks. The combination of the two are especially pernicious given the
assumption that the secret keys are erased "when transmission is complete". An
attacker can kill off any session by replaying an end-of-session message.
Second, it appears the nodes need to posses the central authority's public key
prior to the start of communication. It cannot be authenticated over the
network. IMHO this assumption should be explicit.
------------------------------
From: "Joris Dobbelsteen" <[EMAIL PROTECTED]>
Subject: Re: Request comment on a new cipher design
Date: Fri, 13 Apr 2001 08:44:51 +0200
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
news:9b5oj7$coj$[EMAIL PROTECTED]...
>
> Joris Dobbelsteen <[EMAIL PROTECTED]> wrote in message
> news:9b3jb4$t7s$[EMAIL PROTECTED]...
> > As I'm quite new to cryptography, I didn't was so stupid not to read
some
> > literature.
> Actually, if you're quite new to cryptography, going off and designing
block
> ciphers without knowing what you are doing is not the way to start...
>
Read John Saverd's web site and also looked into "Handbook of Applied
Cryptography", somwhere on the Web. Some other sites also gave some
interresting and good information about cryptography.
At least basing it on IDEA seemed as good choice, as no other attack than
brute force was efficient to it. Also it looks quite simple and small to
implement (with the right hardware you get good speed).
On the other hand, I can learn what I'm doing wrong and why. At least some
princaple parts of ciphers I understand, where I checked this thing for.
Someone else posted a routine that would only work if it was implemented on
a OTP, the 'crap' with the addition.
> > John Saverd's web site was quite good, however I got lost in the
> > descriptions some times.
> >
> > If this document in in worse english, sorry, mine just isn't better.
Still
> I
> > would expect you could make some sense from it, otherwise, complain...
> >
> > However to the point, this is a cipher with a 128-bit block that looks a
> > hole lot like IDEA (as you will see when you create a little drawing). I
> > expect this on the be faster on the appropirate hardware. This one looks
> > quite good to me and not just like a piece of crap, at least, I hope.
> >
> > It uses <r> rounds, where r is an integer always > 0.
> > The key schedule is ommited, as it's not designed yet, and needs to
> prevent
> > the use of weak keys that are very well possible.
> >
> > The cipher uses x86 byte order (little-endian?)
> >
> > Well, now the description:
> >
> > Note:
> > XOR is XOR
> > + is addition with carries
> > * is multiplication
> > ^ is power
> > mod is modulo
> > << shift left
> > >> shift right
> > |<< rotate left
> > >>| rotate right.
> > (quite logic, except rotates/shifts)
> >
> > k(x) are x 32-bit subkeys, where x >= 0.
> >
> > =========== Initial steps:
> > Divide the 128-bit block into 4 32-bit blocks: A, B, C and D. Where A is
> the
> > least significant and D the most significant.
> >
> > =========== Round, r denotes round number and always > 0 (thus starts at
> 1).
> > n = 9(r-1) ; used for the key
> >
> Possible differential: what if:
> A' - A = 13
> B = B'
> C = C'
> D' - D = 1
>
> > A = A + K(n) mod 2^32
> > B = B + K(n+1) mod 2^32
> > C = C + K(n+2) mod 2^32
> > D = D + K(n+3) mod 2^32 ; mixing up, against linearity with
> > additions.
> Differential unchanged.
>
> >
> > E = A XOR C
> > F = B XOR D ; Remember IDEA???
> E' - E = 13
> F' - F = 1
> both with some reasonable probability (2**-5???)
>
> >
> > L = E + (F << 32) ; 2^64+13 smallest prime >
2^64.
> > L = ( L * ( K(n+4) + ( K(n+5) << 32 ) ) mod (2^64+13) ) mod 2^64
> L = L'
>
> > L = ( L + ( K(n+6) + (K(n+7) << 32) ) ) mod 2^64
> > E = L mod 2^64
> > F = L >> 32 ; somwhat different.
> E = E'
> F = F'
>
> >
> > A = A XOR F ; IDEA here too...
> > B = B XOR E
> > C = C XOR F
> > D = D XOR E
> A' - A = 13
> D' - D = 1
> again, with some reasonable probability, possibly 2**-5
>
> >
> > L = B + (C << 32)
> > L = L |<< ( 20 + ( k(n+8) mod 2^5 ) ) ; Rotate here...
> > B = L mod 2^64
> > C = L >> 32
> These do not affect the differential
>
> >
> >
> > ======= Do some more rounds =======
> >
> > =============== End transformation
> > n = 9r ; (r is number or rounds)
> > E = A mod 2^16
> > F = A >> 16
> > G = B mod 2^16
> > H = B >> 16
> > I = C mod 2^16
> > J = C >> 16
> > K = D mod 2^16
> > L = D >> 16
> >
> > E = ( ( E * Low(k(n)) ) mod 2^16+1 ) mod 2^16
> > F = ( ( F * High(k(n)) ) mod 2^16+1 ) mod 2^16
> > G = ( ( G * Low(k(n+1)) ) mod 2^16+1 ) mod 2^16
> > H = ( ( H * High(k(n+1)) ) mod 2^16+1 ) mod 2^16
> > I = ( ( I * Low(k(n+2)) ) mod 2^16+1 ) mod 2^16
> > J = ( ( J * High(k(n+2)) ) mod 2^16+1 ) mod 2^16
> > K = ( ( K * Low(k(n+3)) ) mod 2^16+1 ) mod 2^16
> > L = ( ( L * High(k(n+3)) ) mod 2^16+1 ) mod 2^16
> >
> > A = E + (F << 16)
> > B = G + (H << 16)
> > C = I + (J << 16)
> > D = K + (L << 16)
> This end transformation doesn't disguise if B=B', C=C' originally
>
> >
> > ================== Functions
> > Low(x)
> > { Return x mod 2^16 }
> > High(x)
> > { Return x >> 16 }
> >
> >
> > ================= Possible Weaknesses:
> > * Weak keys as in IDEA. Key Schedule is to be designed, should solve
this.
> > * 64-bit multiplication leaks 12 values: 2*12=24 values, some less than
5
> > bits, so I name it 5 bits for ease.
> >
> > ================== Possible Strengths:
> > * Fast propagation of bit changes
> > * addition after 64-bit multiplication to compensate bit loss in
> > multiplication
> > * All for quarters manipulated at once.
> > * No explicit changes of B and C, but using a bit rotate.
> > * Last pair of 16-bit multiplications that are revertable. Doesn't get
> very
> > high security.
> > _Probably_ good security against DC and LC. I do expect that...
> And why do you expect that???
>
> >
> > ================= Key Schedule
> > To be designed. Should prevent weak keys form going to be used in the
> > routine. I was aiming for a 128-bit to 256-bit or larger key. Hope
someone
> > can create a routine here that prevents weak keys and supports any input
> > key.
> >
> > ================= Rounds expected
> > 8 rounds is expected to be sufficient.
> >
> >
> >
> > - Joris
> >
> >
>
>
------------------------------
From: "Joris Dobbelsteen" <[EMAIL PROTECTED]>
Subject: Re: Request comment on a 'new' cipher design (update)
Date: Thu, 12 Apr 2001 17:41:11 +0200
> As I'm quite new to cryptography, I didn't was so stupid not to read some
> literature.
> John Saverd's web site was quite good, however I got lost in the
> descriptions some times.
>
> If this document in in worse english, sorry, mine just isn't better. Still
I
> would expect you could make some sense from it, otherwise, complain...
>
> However to the point, this is a cipher with a 128-bit block that looks a
> hole lot like IDEA (as you will see when you create a little drawing). I
> expect this on the be faster on the appropirate hardware. This one looks
> quite good to me and not just like a piece of crap, at least, I hope.
>
> It uses <r> rounds, where r is an integer always > 0.
> The key schedule is ommited, as it's not designed yet, and needs to
prevent
> the use of weak keys that are very well possible.
>
> The cipher uses x86 byte order (little-endian?)
>
> Well, now the description:
>
> Note:
> XOR is XOR
> + is addition with carries
> * is multiplication
Multiplication of a * b:
if a = 0 then a = 2^64 (in rounds) or a = 2^16 (at end)
For b the same rule...
> ^ is power
> mod is modulo
> << shift left
> >> shift right
> |<< rotate left
> >>| rotate right.
> (quite logic, except rotates/shifts)
>
> k(x) are x 32-bit subkeys, where x >= 0.
>
> =========== Initial steps:
> Divide the 128-bit block into 4 32-bit blocks: A, B, C and D. Where A is
the
> least significant and D the most significant.
>
> =========== Round, r denotes round number and always > 0 (thus starts at
1).
> n = 9(r-1) ; used for the key
>
> A = A + K(n) mod 2^32
> B = B + K(n+1) mod 2^32
> C = C + K(n+2) mod 2^32
> D = D + K(n+3) mod 2^32 ; mixing up, against linearity with
> additions.
>
> E = A XOR C
> F = B XOR D ; Remember IDEA???
>
> L = E + (F << 32) ; 2^64+13 smallest prime > 2^64.
> L = ( L * ( K(n+4) + ( K(n+5) << 32 ) ) mod (2^64+13) ) mod 2^64
> L = ( L + ( K(n+6) + (K(n+7) << 32) ) ) mod 2^64
> E = L mod 2^64
> F = L >> 32 ; somwhat different.
>
> A = A XOR F ; IDEA here too...
> B = B XOR E
> C = C XOR F
> D = D XOR E
>
> L = B + (C << 32)
> L = L |<< ( 20 + ( k(n+8) mod 2^5 ) ) ; Rotate here...
> B = L mod 2^64
> C = L >> 32
>
>
> ======= Do some more rounds =======
>
> =============== End transformation
> n = 9r ; (r is number or rounds)
> E = A mod 2^16
> F = A >> 16
> G = B mod 2^16
> H = B >> 16
> I = C mod 2^16
> J = C >> 16
> K = D mod 2^16
> L = D >> 16
>
> E = ( ( E * Low(k(n)) ) mod 2^16+1 ) mod 2^16
> F = ( ( F * High(k(n)) ) mod 2^16+1 ) mod 2^16
> G = ( ( G * Low(k(n+1)) ) mod 2^16+1 ) mod 2^16
> H = ( ( H * High(k(n+1)) ) mod 2^16+1 ) mod 2^16
> I = ( ( I * Low(k(n+2)) ) mod 2^16+1 ) mod 2^16
> J = ( ( J * High(k(n+2)) ) mod 2^16+1 ) mod 2^16
> K = ( ( K * Low(k(n+3)) ) mod 2^16+1 ) mod 2^16
> L = ( ( L * High(k(n+3)) ) mod 2^16+1 ) mod 2^16
>
> A = E + (F << 16)
> B = G + (H << 16)
> C = I + (J << 16)
> D = K + (L << 16)
>
> ================== Functions
> Low(x)
> { Return x mod 2^16 }
> High(x)
> { Return x >> 16 }
>
>
> ================= Possible Weaknesses:
> * Weak keys as in IDEA. Key Schedule is to be designed, should solve this.
> * 64-bit multiplication leaks 12 values: 2*12=24 values, some less than 5
> bits, so I name it 5 bits for ease.
>
> ================== Possible Strengths:
> * Fast propagation of bit changes
> * addition after 64-bit multiplication to compensate bit loss in
> multiplication
> * All for quarters manipulated at once.
> * No explicit changes of B and C, but using a bit rotate.
> * Last pair of 16-bit multiplications that are revertable. Doesn't get
very
> high security.
> _Probably_ good security against DC and LC. I do expect that...
>
> ================= Key Schedule
> To be designed. Should prevent weak keys form going to be used in the
> routine. I was aiming for a 128-bit to 256-bit or larger key. Hope someone
> can create a routine here that prevents weak keys and supports any input
> key.
>
> ================= Rounds expected
> 8 rounds is expected to be sufficient.
>
>
>
> - Joris
>
>
- Joris
------------------------------
From: "Joris Dobbelsteen" <[EMAIL PROTECTED]>
Subject: Re: Is this a block cipher?
Date: Thu, 12 Apr 2001 17:57:01 +0200
The diffence between these two can be quite confusing.
In computer terms a message consists of serveral bytes (in an alphabet these
are letters). A stream cipher does a manipulation on one such unit, while a
block cipher does a manipulation to a more than one byte.
Manipulation is the 'look-up' in a codebook, however as the code-book (2^32,
2^64 and now 2^128 or more psssibilities) get's to big, we replace it with a
algorithm, which is just a compact description of how to generate the
codebook.
Stream-cipher
===============
One data unit (byte/letter) -------------------------> One data unit
[ KEY ]
Block cipher
=============
Large data unit (muliple bytes/muliple letters) ----------> Large data unit
[ KEY ]
Examples are DES/IDEA which use 64-bits, that are 8 bytes.
or AES (Rijndael)/Twofish/Serpent/..... that use 128-bits=16 bytes
RC5 supports multiple block sizes...
"Mr. Smith" <[EMAIL PROTECTED]> wrote in message
news:De8A6.94286$[EMAIL PROTECTED]...
> Greetings! I'm a newbie here, trying to grasp the basic structure of
> ciphers, and cryptography in general. I know what a stream ciper is.
> However, the block ciper is a bit confusing. Does it work like the example
> below?
>
> Key 1:
> aaa = gws
> aab = wjc
> aac = qlg
> ...
> zzz = eut
>
> Key 2:
> aaa = jsd
> aab = nas
> aac = qlm
> ...
> zzz = haa
>
> I'd also like a clarification on exactly what a ket is. I think I know,
but
> re-enfocement wouldn't hurt! ;-) 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
