Cryptography-Digest Digest #151, Volume #11 Fri, 18 Feb 00 12:13:01 EST
Contents:
Re: Question about OTPs (Dave Hazelwood)
Re: I stole also the diary and calendar of Markku J. Saarelainen ("William A.
Nelson")
Re: RSA Speed (long) (Doug Stell)
Re: EOF in cipher??? (John Myre)
Re: EOF in cipher??? ("Trevor Jackson, III")
Re: Method to break triple-DES (Mickey McInnis)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Dave Hazelwood)
Subject: Re: Question about OTPs
Date: Fri, 18 Feb 2000 16:18:44 GMT
Sorry but I am a programmer :). And to me a "byte" is 8 bits
regardless of whether it is a "byte" value found in OTP data
or OTP data.
In fact what is the difference between a byte of OTP data and
a byte value found in the OTP data?
Are you saying a "byte" of OTP data is more than 8 bits and has
more than 256 values?
If so, please clarify the definition of your "byte". There
are some systems that use other than 8 bit bytes but unless you
specifically state otherwise most of us will assume an 8 bit
byte.
With a true OTP you must never reuse the same PAD and the PAD
must be certified random. But, even within a random pad you
will have repeated "bytes" albeit at random intervals. This
is ok and even if the "OTP data" (the message?) is encrypted
multiple times with different random pads it is still totally
secure.
So I am still confused what he means.
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>Dave Hazelwood wrote:
>> Surely you mean never reuse a byte "sequence" as opposed to "no"
>> byte?
>
>He means "no byte of the OTP data". NOT "no byte *value* found
>in the OTP data". When we say that a file contains 2MB, we don't
>mean that it contains 2M distinct byte *values*.
------------------------------
From: "William A. Nelson" <[EMAIL PROTECTED]>
Crossposted-To:
talk.politics.european-union,soc.culture.british,soc.culture.french,soc.culture.belgium
Subject: Re: I stole also the diary and calendar of Markku J. Saarelainen
Date: Fri, 18 Feb 2000 16:27:26 GMT
Some examples of Markku J. Saarelainen's ingenuity are described in few
brief sections of his 1970-80 diaries. He actually seemed to have spent some
significant time at one police station, when he was 8 to 14, and talked with
many police officers and other law enforcement people. At the same time, he
actually acquired many bits and pieces of the knowledge and intelligence
that were acquired by these police officers during their routine and special
tasks. He had written down specific examples how to control and manipulate
the system with the method of using law enforcement officers and agents
without them ever knowing this. Markku had also listened a police radio at
the time. In addition, in one paragraph from 1988, he makes some references
to the special branch of Finland's security police and intelligence (SUOPO)
and describes some communications with the head of this intelligence
organization in detail. It does appear that Markku J. Saarelainen had the
skill of deceiving and influencing people since early 1970's.
Yours,
William A. Nelson
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: RSA Speed (long)
Date: Fri, 18 Feb 2000 16:11:20 GMT
On Thu, 17 Feb 2000 17:34:22 -0500, Erik <[EMAIL PROTECTED]> wrote:
>Thanks. After I improved my multiplication routine and implemented
>Montgomery multiplication, it came down to around 2 seconds. But how do
>you use the C.R.T? AC gives an algorithm for it, but doesn't explain
>how to use it to find C^d mod n.
Erik,
Since you asked, here is a worked example of RSA with a small modulus.
It is done in the conventional manner, using Chinese Remainder Theorem
and using Montgomery Multiplication. I did this years ago as an aid in
teaching classes on RSA.
doug
Example of the RSA Algorithm, on a 4-function Calculator
========================================================
Key Derivation
==============
Alice picks the following numbers:
Prime numbers: P = 11, Q = 17
Public exponent: E = 3 E < P-1, E < Q-1
g.c.d.(3,10) = 1
(E relatively prime to P and Q) g.c.d.(3,16) = 1
Alice computes the following numbers:
Public Modulus: N = P * Q = 11 * 17 = 187
Private Modulus: Phi[N] = (P-1) * (Q-1) = 10 * 16 = 160
Private exponent, using Euclid's Theorem: D = 107
D = (E)^-1 (mod Phi[N]) = (E)^(Phi[N]-1) (mod Phi[N])
= (3)^(P-1)*(Q-1)-1 (mod (P-1)*(Q-1))
= (3)^159 (mod 160) = 107
Check: E * D = 3 * 107 = 321 = 2(160) + 1 = 1 (mod 160)
Alice's public key is [N, E] = [187, 3] - made public
Alice's private key is [N, D] = [187, 107] - held in secret
-----------------------------------------------------------------
Computation of (3)^159 (mod 160), via the successive square and
multiply method:
expressing the exponent in binary form: 159 -> 1001,1111
applying the exponent from right (LSB) to left (MSB)
Successive squaring of 3 Accumulation of result
------------------------ -------------------------
(3)^01 = 3 1 -> 3 * 1 = 3
(3)^02 = 9 1 -> 9 * 3 = 27
(3)^04 = 81 (mod 160) 1 -> 81 * 27 = 107 (mod 160)
(81)^2 = 6,561 = 41(160) + 1 = 1 (mod 160)
81 * 27 = 2,187 = 13(160) + 107 = 107 (mod 160)
(3)^08 = 1 1 -> 1 * 107 = 107
(3)^16 = 1 1 -> 1 * 107 = 107
(3)^32 = 1 0 -> no mult. 107
(3)^64 = 1 0 -> no mult. 107
(3)^128 = 1 1 -> 1 * 107 = 107
Alice may discard prime numbers, P and Q, and Phi[N], as they
are no longer needed, or she may use them to increase
computation speed via the Chinese Remainder Theorem method.
Encryption for Authentication, with private key (187,107)
=========================================================
Alice wishes to authenticate a message, M, the number 129, and
send
it to Bob. Alice, therefore, applies her private key pair (187,
107).
Computation of cipher C = (129)^107 (mod 187), via the successive
square and multiply method:
expressing the exponent in binary form: 107 -> 110,1011
applying the exponent from right (LSB) to left (MSB)
Successive squaring of 129 Accumulation of result
-------------------------- -------------------------
(129)^01 = 129 1 -> 129 * 001 = 129
(129)^02 = 185 (mod 187) 1 -> 185 * 129 = 116 (mod 187)
(185)^2 = 34,225 = 183(187) + 4 = 4 (mod 187)
185 * 129 = 23,865 = 127(187) + 116 = 116 (mod 187)
(129)^04 = 4 (mod 187) 0 -> no mult. 116
(129)^08 = 16 1 -> 16 * 116 = 173 (mod 187)
(129)^16 = 69 (mod 187) 0 -> no mult. 173
(129)^32 = 86 (mod 187) 1 -> 86 * 173 = 105 (mod 187)
(129)^64 = 103 (mod 187) 1 -> 103 * 105 = 156 (mod 187)
Therefore, the resulting cipher is C = (129)^107 = 156 (mod 187)
------------------------------------------------------------------
Decryption of cipher 156 with public key (187,3)
================================================
Bob uses Alice's public key pair (187, 3) to decrypt the cipher
Computation of M = (156)^3 (mod 187), via the successive square
and multiply method:
Successive squaring of 129 Accumulation of result
-------------------------- -------------------------
(156)^01 = 156 1 -> 156 * 001 = 156
(156)^02 = 26 (mod 187) 1 -> 26 * 156 = 129 (mod 187)
Therefore, the recovered message is (156)^3 = 129 (mod 187)
M = (C)^E = ((M)^D)^E (mod N) because D * E = 1 (mod Phi[N])
------------------------------------------------------------------
Interesting point of note: The number of steps in the calculation
is the sum of the number of bits in the exponent, excluding
leading
zeros and the number of 1-bits in the exponent. That is why short
exponents with few 1-bits compute quickly.
Encryption of a Message for Secrecy, with public key (187,3)
============================================================
Bob wishes to send a message, M, the number 129, to Alice in
secret.
Bob, therefore, applies Alice's public key pair (187, 3).
Computation of cipher C = (129)^3 (mod 187), via the successive
square and multiply method and using the table of the previous
page
Successive squaring of 129 Accumulation of result
-------------------------- -------------------------
(129)^01 = 129 1 -> 129 * 001 = 129
(129)^02 = 185 (mod 187) 1 -> 185 * 129 = 116 (mod 187)
Therefore, the resulting cipher is C = (129)^3 = 116 (mod 187)
------------------------------------------------------------------
Decryption of cipher 116 with private key (187,107)
===================================================
Alice decrypts the encrypted cipher from Bob, using her private
key pair (187, 107).
Computation of M = (116)^107 (mod 187), via the successive square
and multiply method:
expressing the exponent in binary form: 107 -> 110,1011
applying the exponent from right (LSB) to left (MSB)
Successive squaring of 129 Accumulation of result
-------------------------- -------------------------
(116)^01 = 116 1 -> 116 * 001 = 116
(116)^02 = 179 (mod 187) 1 -> 179 * 116 = 7 (mod 187)
(116)^04 = 64 (mod 187) 0 -> no mult. 7
(116)^08 = 169 (mod 187) 1 -> 169 * 7 = 61 (mod 187)
(116)^16 = 137 (mod 187) 0 -> no mult. 61
(116)^32 = 69 (mod 187) 1 -> 69 * 61 = 95 (mod 187)
(116)^64 = 86 (mod 187) 1 -> 86 * 095 = 129 (mod 187)
Therefore, the recovered message is (116)^107 = 129 (mod 187)
M = (C)^D = ((M)^E)^D (mod N) because D * E =1 (mod Phi[N])
------------------------------------------------------------------
Original scientific calculator example, supplied by D. James
Bidzos (president) and Bert. S. Kaliski of RSA Data Security,
Inc. "An Overview of Cryptography, Technology provides network
privacy," LAN TIMES, February 1990.
Modified for 4-function calculator (with memory) and CRT method
example added by Doug Stell. (This is also the method used by
the Cylink public key chip and many other implementations.)
Example of the Chinese Remainder Theorem Method of Calculation
==============================================================
The computations using the public key are relatively fast, due
to the fact that the exponent has been chosen to be a small
number with few one-bits. However, computations using the
private key are quite slow and will benefit from use of the
Chinese Remainder Theorem. This permits the combining of two
faster exponentiations, using smaller numbers, rather than one
exponentiation using larger numbers.
As an example of the CRT method, we will again use two examples,
Alice encrypting message, M = 129, by computing the cipher,
C = (129)^107 = 156 (mod 187) and Alice decrypting cipher,
C = 116, by computing M = (116)^107 = 129 (mod 187). (Actual
exponentiations are not shown in this example.)
Further Key Derivation for Chinese Remainder Theorem
====================================================
Instead of discarding the primes, P and Q, and using only the
private exponent, D, the primes are retained and two related key
components are computed. These are the multiplicative inverses
of P and Q, P1 and Q1, using Euclid's Theorem, such that
(P*P1) (mod Q) = 1 and (Q*Q1) (mod P) = 1.
P1 = inverse of (P = 11): P1 = (P)^(Q-2) (mod Q)
= (11)^15 (mod 17)
= 14 (mod 17)
Q1 = inverse of (Q = 17): Q1 = (Q)^(P-2) (mod P)
= (17)^9 (mod 11)
= (6)^9 (mod 11)
= 2 (mod 11)
The private exponents (mod P-1) and (mod Q-1) are also computed.
Private Exponent D = 107: = 7 (mod 10) = 11 (mod 16)
The CRT method private key is:
[N, P, Q, P1, Q1, D (mod P-1), D (mod Q-1)]
= [187, 11, 17, 14, 2, 7, 11]
Encryption for Authentication, with CRT method private key
==========================================================
1. Alice computes separately (M)^D (mod P) and (M)^D (mod Q).
(mod P) part (mod Q) part
-------------- ----------------
Private Exponent: D = 107 = 7 (mod 10) = 11 (mod 16)
Plaintext data: M = 129 = 8 (mod 11) = 10 (mod 17)
(M)^D = (129)^107 = (8)^7 (mod 11) = (10)^11 (mod 17)
= 2 (mod 11) = 3 (mod 17)
2. The Chinese Remainder Theorem says that we may combine the
above computations by substitution into the formula below:
Y (mod P*Q) = [(Y (mod P))*Q*Q1 + (Y (mod Q))*P*P1 ) (mod P*Q)
C = (M)^D (mod 187) = [(2 * 17 * 2) + (3 * 11 * 14)]
= 68 + 462 = 68 + 88 (mod 187) = 156 (mod 187)
= 530 = 156 (mod 187)
Decryption of cipher 116 with CRT method private key
====================================================
1. Alice computes separately (C)^D (mod P) and (C)^D (mod Q).
(mod P) part (mod Q) part
-------------- ----------------
Private Exponent: D = 107 = 7 (mod 10) = 11 (mod 16)
Ciphertest data: C = 116 = 6 (mod 11) = 14 (mod 17)
(C)^D = (116)^107 = (6)^7 (mod 11) = (14^11) (mod 17)
= 8 (mod 11) = 10 (mod 17)
2. The Chinese Remainder Theorem says that we may combine the
above computations by substitution into the formula below:
Y (mod P*Q) = [(Y (mod P))*Q*Q1 + (Y (mod Q))*P*P1 ) (mod P*Q)
M = (C)^D (mod 187) = [(8 * 17 * 2) + (10 * 11 * 14)]
= 272 + 1540 = 85 (mod 187) + 44 (mod 187) = 129 (mod 187)
= 1812 = 129 (mod 187)
------------------------------------------------------------------
Original scientific calculator example, supplied by D. James
Bidzos (president) and Bert. S. Kaliski of RSA Data Security,
Inc. "An Overview of Cryptography, Technology provides network
privacy," LAN TIMES, February 1990.
Modified for 4-function calculator (with memory) and CRT method
example added by Doug Stell. (Note that the successive square
and multiply method is also the method used by the Cylink public
key chip and many other implementations.)
CRT Method - calculations of supporting exponentiations
=======================================================
Computation of (11)^15 (mod 17): 15 = 1111 (binary)
Successive squaring of 11 Accumulation of result
-------------------------- ------------------------
(11)^01 = 11 1 -> 11 * 1 = 11
(11)^02 = 2 (mod 17) 1 -> 2 * 11 = 5 (mod 17)
(11)^04 = 4 1 -> 4 * 5 = 3 (mod 17)
(11)^08 = 16 1 -> 16 * 3 = 14 (mod 17)
Computation of (6)^9 (mod 11): 9 = 1001 (binary)
Successive squaring of 11 Accumulation of result
-------------------------- ------------------------
(7)^01 = 6 1 -> 6 * 1 = 6
(7)^02 = 3 (mod 11) 0 -> no mult. 6
(7)^04 = 9 0 -> no mult. 6
(7)^08 = 4 (mod 11) 1 -> 4 * 6 = 2 (mod 11)
Computation of (8)^7 (mod 11): 7 = 111 (binary)
Successive squaring of 8 Accumulation of result
-------------------------- ------------------------
(8)^01 = 8 1 -> 8 * 1 = 8
(8)^02 = 9 (mod 11) 1 -> 9 * 8 = 6 (mod 11)
(8)^04 = 4 (mod 11) 1 -> 4 * 6 = 2 (mod 11)
Computation of (10)^11 (mod 17): 11 = 1011 (binary)
Successive squaring of 10 Accumulation of result
-------------------------- ------------------------
(10)^01 = 10 1 -> 10 * 1 = 10
(10)^02 = 15 (mod 17) 1 -> 15 * 10 = 14 (mod 17)
(10)^04 = 4 (mod 17) 0 -> no mult. 14
(10)^08 = 16 1 -> 16 * 14 = 3 (mod 17)
Computation of (6)^7 (mod 11): 7 = 111 (binary)
Successive squaring of 6 Accumulation of result
-------------------------- ------------------------
(6)^01 = 6 1 -> 6 * 1 = 6
(6)^02 = 3 (mod 11) 1 -> 3 * 6 = 7 (mod 11)
(6)^04 = 9 1 -> 9 * 7 = 8 (mod 11)
Computation of (14)^11 (mod 17): 11 = 1011 (binary)
Successive squaring of 14 Accumulation of result
-------------------------- ------------------------
(14)^01 = 14 1 -> 14 * 1 = 14
(14)^02 = 9 (mod 17) 1 -> 9 * 14 = 7 (mod 17)
(14)^04 = 13 (mod 17) 0 -> no mult. 7
(14)^08 = 16 (mod 17) 1 -> 16 * 7 = 10 (mod 17)
Montgomery Method Multiplication
================================
Goal: To replace the "mod m" operation and the trial divisions
associated with it in the main loop with faster multiplications
and right shifts.
Moduli: R = 256 Montgomery modulus, 2^x, for binary machines
m = 187 Original modulus
Requirements: R > m
gcd(R,m) = 1
Input variables: a = 116
b = 179
c = 169
d = 69
e = 86
Expected result: f = a * b * c * d * e = 129 mod 187
Generation of values needed:
R = 256, the next power of 2 higher than modulus
m-bar = - m^(-1) mod R = - 187^(-1) mod 256 = 141
R-bar = R^(-1) mod m = 256^(-1) mod 187 = 103
R^2 mod n = 256^2 mod 187 = 69^2 mod 187 = 86
T = x-bar * y-bar, a temporary product for each calculation
U = T * m-bar mod R
Define: REDUC(T) = T * R^(-1) mod m
Compute U = T * m-bar mod R
Compute xy-bar = (T + U*m) /R
doing division by shifting
if (xy-bar < m) return xy-bar
else return (xy-bar - m)
Method summary:
Pick R meeting the requirements
Compute R^2 mod m, m-bar, R-bar
Convert inputs to Montgomery format
For each multiplication (x * y):
Compute T = x-bar * y-bar
Reduce T = T *R^(-1) mod m, as defined above
Convert Montomery result back to normal format
Conversion of input variables to Montomery format:
a-bar = aR mod 187 = REDUC (116 * (R^2 mod 187)) =
T = 116 * 86 = 9976
U = (T * m-bar) mod R = (9976 * 141) mod 256 = 152
T + U*m = 9976 + 152 * 187 = 38400
Dividing by 256 or shifting right 8 bits
a-bar = 150
b-bar = bR mod 187 = REDUC (179 * (R^2 mod 187)) =
T = 179 * 86 = 15394
U = (T * m-bar) mod R = (15394 * 141) mod 256 = 186
T + U*m = 15394 + 186 * 187 = 50176
Dividing by 256 or shifting right 8 bits
b-bar = 196 (Note 196 > 187)
b-bar = 9
c-bar = cR mod 187 = REDUC (169 * (R^2 mod 187)) =
T = 169 * 86 = 14534
U = (T * m-bar) mod R = (14534 * 141) mod 256 = 14
T + U*m = 14534 + 14 * 187 = 17152
Dividing by 256 or shifting right 8 bits
c-bar = 67
d-bar = dR mod 187 = REDUC (69 * (R^2 mod 187)) =
T = 69 * 86 = 5934
U = (T * m-bar) mod R = (5934 * 141) mod 256 = 86
T + U*m = 5934 + 86 * 187 = 22016
Dividing by 256 or shifting right 8 bits
c-bar = 86
e-bar = eR mod 187 = REDUC (86 * (R^2 mod 187)) =
T = 86 * 86 = 7396
U = (T * m-bar) mod R = (7396 * 141) mod 256 = 148
T + U*m = 7396 + 148 * 187 = 35072
Dividing by 256 or shifting right 8 bits
e-bar = 137
First multiplication:
T = a-bar * b-bar = 150 * 9 = 1350
U = T * m-bar mod R = 1350 * 141 mod 256 = 142
T + U*m = 1350 + 142 * 187 = 27904
Dividing by 256 or shifting right 8 bits:
ab-bar = 109
Second multiplication:
T = ab-bar * c-bar = 109 * 67 = 7303
U = T * m-bar mod R = 7303 * 141 mod 256 = 91
T + U*m = 7303 + 91 * 187 = 24320
Dividing by 256 or shifting right 8 bits:
abc-bar = 95
Third multiplication:
T = abc-bar * d-bar = 95 * 86 = 8170
U = T * m-bar mod R = 8170 * 141 mod 256 = 226
T + U*m = 8170 + 226 * 187 = 50432
Dividing by 256 or shifting right 8 bits:
abcd-bar = 197 (Note: 197 > m)
abcd-bar = 197 - 187 = 10
Fourth multiplication:
T = abcd-bar * e-bar = 10 * 137 = 1370
U = T * m-bar mod R = 1370 * 141 mod 256 = 146
T + U*m = 1370 + 146 * 187 = 28672
Dividing by 256 or shifting right 8 bits:
f-bar = abcde-bar = 112
Converting f-bar to f:
f = f-bar * R^(-1) mod m = 112 * 103 mod 187 = 129
f = f-bar * R^2 mod 187 = REDUC (112) =
T = 112
U = (T * m-bar) mod R = (112 * 141) mod 256 = 176
T + U*m = 112 + 176 * 187 = 33024
Dividing by 256 or shifting right 8 bits
f = 129
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Fri, 18 Feb 2000 09:40:52 -0700
Runu Knips wrote:
>
> "Trevor Jackson, III" schrieb:
> > Mok-Kong Shen wrote:
> > > To be sure that I didn't misunderstand, I like to ask whether the
> > > code (from KR):
> > > while ((C = getc(fp)) != EOF)
> > > .........
> > > needs to be modified or using rb is sufficient for taking care of
> > > the presence of any bit combinations in the file. Thanks.
> > The issue is the type of the variable C. To operate correctly it must
> > be an int not a char.
>
> Unfortunately, the above code will run on many systems without
> problems until fp is a binary file which happends to contain
> the code 0xff, which is equal to (signed char)-1 (on machines
> with 8 bits for a character).
Only if the C library (presumably it came with the compiler)
is implemented incorrectly.
The return type of getc() is already "int", which means there is
no promotion (and possible sign extension) going on. In a correct
implementation, 0xff is returned as 255, not -1.
(I suppose the whole thing would fail if "int" were 8 bits,
but please - has there *ever* been such an implementation?)
John M.
------------------------------
Date: Fri, 18 Feb 2000 12:03:36 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Runu Knips wrote:
> "Trevor Jackson, III" schrieb:
> >
> > "Douglas A. Gwyn" wrote:
> >
> > > "Trevor Jackson, III" wrote:
> > > > Runu Knips wrote:
> > > > > EOF works well, because EOF is defined to be -1, while all characters
> > > > > are returned as nonnegative values.
> > > > This is _completely_ off topic. But the last statement is completely
> > > > false. The signedness of characters is implementation defined. Thus on
> > > > some systems characters are signed.
> > >
> > > No, first of all you mean char type, not characters.
> > > Secondly, the standard I/O functions such as getc deal with
> > > the data as unsigned char. So long as sizeof(char) < sizeof(int),
> > > which is practically always the case, EOF (-1) can never result
> > > from inputting any data value, even when char is a signed type.
> > >
> > > Please stop giving bad C advice!
> >
> > You are out of line again. The original statement was that "all characters
> > are returned as nonnegative values". That statement was false.
>
> That statement is true. Its exactly what the standard says.
Section 7.9.7.1 "The fgetc function" is probably representative. Section 7.9.7.5
refers to it, and 7.9.7.6 refers to 7.9.7.5.
It indeed asserts that all characters are returned as nonnegative values.
However, for production code one cannot rely upon this. It leads to the mistaken
assumption that...
while ( ( c = getchar() ) > 0 )
... will work. On some compilers this will fail because they do not conform to
the standard. I know of two.
I've used at least a dozen, and none, zero, nada, were fully conformant. The
essence of "bad C advice" is making unnecessary assumptions about machine
architecture.
Since my customers _will_not_ pay for software that ought to work because it
follows the standard but fails to work in practice, I tend to write in that
Kernigan refers to as the "mainstream" of the language. That is good C advice
from someone who I consider qualified to have an opinion.
Assuming that EOF is the only negative value returned by fgetc/getc/getchar is
certainly not the mainstream of the language.
>
> > And there are machines where EOf != -1 and some where sizeof(char) ==
> > sizeof(int). I've worked on them.
>
> Thats both against the standard. ISO specifies that int must be at least
> 16 bit (i.e. it says short must be 16 bit, and sizeof(int) >=
> sizeof(short),
> which means int is also at least 16 bit). A character value, however, is
> the smallest type which has at least 7 bit.
Right. So 12-bit machines _cannot_ conform to the standard because int is
generally the most natural integral machine data type, usually the register size.
And 6-bit character sets are seriously ugly. So char maps to 12 bits too.
>
>
> > If you are advising programmers to make invalid and unnecessary assumptions
> > about the architecture of their machines, which of us is giving "bad C
> > advice".
>
> I'm sorry, but thats all from my good old K&R book (the version which
> was
> published after ISO and already contained the changes).
My references are:
Kernigan & Ritchie, "The C Programming Language" 1978
Plauger, "The Standard C Library", 1992
Kernigan & Pike, "The Practice of Programming", 1999
------------------------------
From: [EMAIL PROTECTED] (Mickey McInnis)
Subject: Re: Method to break triple-DES
Date: 18 Feb 2000 16:45:38 GMT
Reply-To: [EMAIL PROTECTED]
com>
Organization:
Keywords:
In article <[EMAIL PROTECTED]>, Johnny Bravo
<[EMAIL PROTECTED]> writes:
|> On 17 Feb 2000 23:07:16 GMT, [EMAIL PROTECTED] (Mickey
|> McInnis) wrote:
|>
|> >That sounds much more difficult than the description I heard of, but since
|> >I didn't pay that much attention to it, I can't be sure. I think the
|> >number or operations required was much less, in the range of 2**64 or
|> >less.
|>
|> You could be remembering the 2**56 part of the paper. It might be
|> easier for 2 key 3DES, where keys 1 and 3 are the same. For the normal
|> three key version you need to precompute one set of 2**56, store it in
|> memory, and use it with the rest of the 2**112 operations of the other two
|> keys. It is a known plaintext break; 2**113 operations compared to 2**168
|> operations, but you are still left with 112 bits to check for the 50/50
|> chance. The attack is real, is a massive reduction in the strength of the
|> cipher, but the remaining strength is still damn strong.
|>
Yes, when I hear "3-DES", I think the 2x56 bit key "EDE" encryption. I
am under the impression that this is the most common thing called "3-DES",
but I could be wrong.
The "meet in the middle" with 2**56 attempts in one direction and
2**112 operations in the other directions, I consider old informaton.
I think it's been generally believed for some time that the safe assumption
is that 3DES might be breakable with no more than 2*112 trials and lots
of storage. In fact, it's the reason to use 3-DES instead of 2-DES.
The article that caught my eye left me with the impression that 3-DES
with 2x56 bit keys might be crackable with much less than 2*112 trials.
If true, this is very significant in my opinion.
|> >My recollection is that it was something difficult and expensive, but
|> >not completely beyond the realm of possibility for a government or
|> >multinational company in the near future.
|>
|> Gig machines are currently in use, and it would certainly be possible
|> for a dedicated machine to be built with 500 gig of RAM, but the 2**112
|> operations are still going to take quite a bit of time to complete. It
|> would be easy for a government or a large company to build such a machine,
|> 112 bits is still pretty secure but it is about time to retire it and
|> implement the AES to be on the safe side.
|>
|> --
|> Best Wishes,
|> Johnny Bravo
|>
|> "The most merciful thing in the world, I think, is the inability
|> of the human mind to correlate all it's contents." - HPL
--
Mickey McInnis - [EMAIL PROTECTED]
--
All opinions expressed are my own opinions, not my company's opinions.
------------------------------
** 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
******************************
