Cryptography-Digest Digest #794, Volume #11 Wed, 17 May 00 00:13:01 EDT
Contents:
Re: AES final comment deadline is May 15 (Bryan Olson)
Re: How does one test an encryption algorithm? (William Rowden)
Re: Is OTP unbreakable? (William Rowden)
Re: Definition of "Broken" Cipher (Boris Kazak)
Re: Theoretical question (Bryan Olson)
Re: Encryption of graphics by transposition ("Douglas A. Gwyn")
Re: Unbreakable encryption. ("Douglas A. Gwyn")
Re: Definition of "Broken" Cipher ("Douglas A. Gwyn")
Re: Is OTP unbreakable? ("Douglas A. Gwyn")
An attack on reduced Pikachu ([EMAIL PROTECTED])
Re: Skipjack implementation in C ("Douglas A. Gwyn")
Re: Q: How to find good characteristics for differential cryptanalysis?
([EMAIL PROTECTED])
Re: (May 16, 2000) Cipher Contest Update (Raphael Phan Chung Wei)
Re: Tiny Stream Cipher "slime" ("Trevor L. Jackson, III")
----------------------------------------------------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: AES final comment deadline is May 15
Date: Wed, 17 May 2000 01:59:13 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> Bryan Olson wrote:
>
> > I tend to disagree. I'm not convinced the mailing lists
> > and newsgroups are where the AES action is.
>
> Certainly the proper AES 'action' is done by the authors of the
> submissions. However, it could be said that the ensemble of
> crypto mailing lists and crypto newsgroups is the proper place
> where the general opinions of the crypto community are to be
> found, I suppose.
I hear it also came up at FSE.
> > Sort of. It's destined to be T H E symmetric block cipher
> > of the next few decades, and probably T H E symmetric
> > cipher. But sci.crypt's obsession with secret key encryption
> > is out of touch with both modern cryptology and the
> > cryptographic market. AES is not among the "New Directions
> > in Cryptography". It's a replacement for DES.
>
> Isn't it that both secret key and public key encryption are needed
> in practice?
Not to mention authentication, certification and revocation,
e-cash and micro-payments, fair elections, group signatures,
time stamping, time release and many others. Cryptography
can provide capabilities far beyond the "secret writing"
that gives it its name.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (William Rowden)
Subject: Re: How does one test an encryption algorithm?
Date: 17 May 2000 02:25:32 GMT
In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
>On Sun, 14 May 2000 15:39:25 GMT, in <[EMAIL PROTECTED]>,
>in sci.crypt [EMAIL PROTECTED] (Bruce Schneier) wrote:
>>On Thu, 11 May 2000 00:37:29 GMT, [EMAIL PROTECTED] wrote:
[snip]
>>>All I want to know is that if my algorithm is tough to crack.
>>>
>>>How does one estimate the confidence factor of an encryption algorithm?
>>>Are there any metrics defined?
>>
>>See:
>>
>> http://www.counterpane.com/crypto-gram-9810.html#cipherdesign
>
>...where we see the same old pablum about getting experts to "analyze"
>the cipher, and then -- somehow -- leaping to a belief in its
>strength.
It seems to me that Terry Ritter's posts fairly consistently disagree
with experts' opinions as a measure of cipher strength. Nevertheless,
AFAICS the thesis of the article cited in Bruce Schneier's post is
*not* "trust algorithms analyzed by experts". While that idea is
perhaps implied, the article introduces its topic by posing this
question:
You want to get well-known cryptographers to look at your
work. What can you do?
The remainder of the article answers this rhetorical question--a
question that appears very relevant to a request for others to examine
the cipher created by [EMAIL PROTECTED]
> Absent a mathematical proof of strength in practice, there is no
> scientific basis for a belief in cipher strength.
Nevertheless, given a choice between a cipher that many have tried
unsuccessfully to break, and a cipher designed by someone ignorant of
known attacks, I'll place my bet on the former.
> Indeed, the entire history of cryptography has been about the
> unexpected weakness of commonly-accepted ciphers.
In my opinion, I think the issue here is not the unexpected weakness
of a commonly-accepted cipher, but rather the expected weakness--to
known attacks by experienced cryptanalysts--of unknown ciphers. I
believe this weakness is all the more likely if the designer is not
aware of what those attacks might be.
The danger may be summarized as follows: unknown ciphers are likely to
be susceptible to well-known attacks. In other words, even if it is
true that "well-known ciphers are likely to have unknown weaknesses"
it does not follow that "unknown ciphers are unlikely to have
well-known weaknesses."
--
-William
PGP key: http://www.eskimo.com/~rowdenw/pgp/rowdenw.asc until 2000-08-01
Fingerprint: FB4B E2CD 25AF 95E5 ADBB DA28 379D 47DB 599E 0B1A
------------------------------
From: [EMAIL PROTECTED] (William Rowden)
Subject: Re: Is OTP unbreakable?
Date: 17 May 2000 02:36:44 GMT
This post looks familiar. :-)
In article <8fs9j6$9q9$[EMAIL PROTECTED]>,
William Rowden <[EMAIL PROTECTED]> wrote:
> I'm beginning to see why the sci.crypt FAQ has this entry:
>
> 4.4. Why is the one-time pad secure?
I'll admit that explanation is terse.
> As Bryan Olson pointed out, the mathematical explanation goes back
> at least to Shannon's 1949 paper
It seems Kahn's _The Codebreakers_ puts the invention of the OTP at
1917. An explanation of the security of the OTP that is perhaps more
accessible than Shannon's is in _Applied Cryptography_, pp 13-15 of
the version I see.
--
-William
PGP key: http://www.eskimo.com/~rowdenw/pgp/rowdenw.asc until 2000-08-01
Fingerprint: FB4B E2CD 25AF 95E5 ADBB DA28 379D 47DB 599E 0B1A
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Definition of "Broken" Cipher
Date: Wed, 17 May 2000 02:53:36 GMT
Paul Koning wrote:
>
*******************
> > However most sane protocals will re-key to avoid using the same key for
> > any long period of time. Say every 2^20 blocks....
>
> 2^20 blocks is NOT a long time! That's only 64 (or 128 for AES)
> megabits. That's less than a second of traffic for the sort of
> high speed links you can get as a high end Internet *user*, never
> mind the far faster links used in the Internet core. (The latter
> are less relevant since encryption is normally an end to end
> activity. But if you have an OC-3 link into the Internet, you're
> not particularly likely to rekey as often as you suggest, not
> by a long shot.
>
> Indeed, one of the arguments against *all* 64-bit blocksize ciphers
> is that you need to rekey within 2^32 blocks, and that's rather fast
> for modern high speed traffic...
>
> paul
===================
Depends on the application in question. If you are transmitting some
confidential information from the embassy in Pakistan, 2^12 blocks are
already too many to transmit without rekeying, but if you are digitally
uploading a new movie to the chain of cinema theatres, you might go
for 2^40 blocks before changing the key.
Best wishes BNK
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Theoretical question
Date: Wed, 17 May 2000 02:52:04 GMT
In article <8fssas$jif$[EMAIL PROTECTED]>,
Bryan Olson
> Suppose we have many pigeons and many pigeon-holes and the
> holes/pigeons ratio is r.
^^^^^^^^^^^^^
Oops. Pigeons/holes is r.
> If each pigeon independently
> picks a random hole to fly into, then the ratio of occupied
> holes to all holes should be close to:
>
> 1 - e^-r
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Encryption of graphics by transposition
Date: Wed, 17 May 2000 03:16:45 GMT
John Bailey wrote:
> Are the usual encryption techniques, eg pgp, feistel ciphers, DES,
> etc really suitable for encrypting graphics, eg gif files, pgp
> files, etc?
Yes; the security should be adequate using any good cryptosystem,
which are designed to protect the privacy of *any* data. The only
file-format dependency of concern might be the decryption speed,
since image data tends to be presented to the human visual system,
which has fairly high bandwidth.
> A more straightforward approach than using these substitution
> based ciphers would be remapping the location of pixels within
> the image, ...
That's hardly "more straightforward" when security is desired.
If a handful of image files of identical size are transposed
using the same fixed transposition map, then the cryptanalyst
shouldn't have a very difficult time reconstructing most of the
images.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Unbreakable encryption.
Date: Wed, 17 May 2000 03:24:37 GMT
[EMAIL PROTECTED] wrote:
> Well, I never realized that what I invented on the spur of the
> moment really is unbreakable.
I read your description, and you're confusing complication with
security. The system would certainly be breakable by a skilled
cryptanalyst, if he were motivated to do so. For further
relevant information, see the sci.crypt section on submission
of challenge ciphers from amateur cryptosystems.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Definition of "Broken" Cipher
Date: Wed, 17 May 2000 03:32:46 GMT
Tom St Denis wrote:
> Well if I can attack a cipher X, in 2^100 steps is it really broken?
The standard idea appears to be that, absent any other evidence
as to the relative security of rival cryptosystems of identical
external characteristics (e.g. key size), one should prefer the
system that has no known sub-brute-force attacks over one that
does.
My own approximate definition of breaking a cryptosystem is to
discover a methodology that, when *applied in practice* to
heavy-volume traffic protected by that system, has a substantial
likelihood of recovering a useful amount of plaintext. For
example, if credit-card transaction protection via the Web can
be attacked by a snooper using a method that will recover one
in every 10,000 credit cards, I'd consider that system to have
been successfully cracked. This would hold true even if the
breakthrough comes about due to an occasional "operator error"
that sends too-easily cracked information over the normally
secure channel. (Thus the emphasis on *applied in practice*.)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Is OTP unbreakable?
Date: Wed, 17 May 2000 03:35:05 GMT
DJohn37050 wrote:
> OTP is information theory secure. There is a proof. Any message
> (of the right length) is equally likely.
No! However, the ciphertext provides no information that would
allow one to adjust the a priori relative likelihoods of the
possible plaintexts.
------------------------------
From: [EMAIL PROTECTED]
Subject: An attack on reduced Pikachu
Date: Wed, 17 May 2000 03:30:44 GMT
Hello sci.crypt
See the Pikachu cipher at Cipher Contest
http://www.wizard.net/~echo/crypto-contest.html
I have developed a truncated differential attack on nine or ten rounds
of Pikachu. A truncated differential is one in which only part of the
cipher text XOR is known in the intermediate rounds.
The linear layer takes four bytes of input and produces
a = 2a+b+c+d
b = 2a+2b+2c+d
c = a+b+2c+d
d = 2a+b+2c+2d
The transform has some interesting differentials. If we take two texts
(a,b,c,d),(a',b,c',d) and XOR them we sometimes get (k,0,k,0). The
interesting part is that sometimes the output of the linear layer will
be
(x,0,x,0) when the input is (k,0,k,0). The rules appear to be that
(a+c) == (a'+c') and
((2a+c)^(2a'+c')) == ((a+2c)^(a'+2c'))
This happens in about 1 in 32 cases.
Now the non-linear layer pass the bytes through four sboxes. When the
input is differentially (x,0,x,0) the output is sometimes (j,0,j,0).
the chance of both linear and non-linear happening together is about 1
in 256 or 2^-8.
So here is an attack that can recover some of the key. This shows
differential input. Two texts are used to create the input. The right
side will be equal the left has a certain XOR pattern.
1 (x,0,x,0) (0,0,0,0) probability 1 two texts (abcdefgh)^(cbadefgh)
2 (0,0,0,0) (y,0,y,0) p = 2^-8
3 (y,0,y,0) (z,0,z,0) p = 2^-8
4 (z,0,z,0) (m,0,m,0) p = 2^-8
5 (m,0,m,0) (z,0,z,0) p = 2^-8
6 (z,0,z,0) (k,0,k,0) p = 2^-8
7 (k,0,k,0) (t,0,t,0) p = 2^-8
8 (t,0,t,0) (e,0,e,0) p = 2^-8
9 (e,0,e,0) (q,0,q,0) p = 1 the pattern will fail here
(q,0,q,0) (a,b,c,d) cipher text
The probability is about 2^-56. Several 'good pairs' can be gathered.
Part of the key be deduced from the b and d in the last round. Since
the XOR of the input is known to be (q,0,q,0) and by assumption the
previous round had the form of (y,0,y,0), the key may be guessed to
within a few values. Three good pair should do it. Some wrong pairs
might creep in as well, they wil suggest the wrong value. The most
suggested value is the correct one.
If the whitening key is guessed, then the last round key can be peeled
off. The cipher is then one round shorter and the same attack can be
used.
I ran the attack on six rounds with some success. The code is pretty
sloppy but I will clean it up if there is interest.
The attack took more input than I expected so my 2^-8 probability may
be
off somewhat. Anymore than 12 or 13 rounds is certainly immune to this
attack.
--Matthew
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Skipjack implementation in C
Date: Wed, 17 May 2000 03:41:13 GMT
/*
SKIPJACK implementation in Standard C
last edit: 25-Jun-1998 [EMAIL PROTECTED]
Derived from Markus G. Kuhn's Ada 95 implementation.
This is a C89 implementation of the SKIPJACK block cipher algorithm
as specified in version 2.0 of NSA's SKIPJACK specification dated
1998-05-29 <http://csrc.nist.gov/SJ_Encryption/skipjack-kea.htm>.
ASSUMES width of type "unsigned char" is 8 bits.
*/
/*
Interface specification:
*/
#define SJ_Keysize 10 /* to match NSA spec (80 bits) */
/* Encryption/decryption is performed for a single 64-bit (8-byte)
block. */
void SJ_Encrypt ( const unsigned char *Key, const unsigned char
*Plaintext,
unsigned char *Ciphertext
);
void SJ_Decrypt ( const unsigned char *Key, const unsigned char
*Ciphertext,
unsigned char *Plaintext
);
int SJ_Selftest ( void ); /* returns nonzero iff passed test */
/*
Implementation:
*/
static const unsigned char F[256] =
{
0xA3, 0xD7, 0x09, 0x83, 0xF8, 0x48, 0xF6, 0xF4,
0xB3, 0x21, 0x15, 0x78, 0x99, 0xB1, 0xAF, 0xF9,
0xE7, 0x2D, 0x4D, 0x8A, 0xCE, 0x4C, 0xCA, 0x2E,
0x52, 0x95, 0xD9, 0x1E, 0x4E, 0x38, 0x44, 0x28,
0x0A, 0xDF, 0x02, 0xA0, 0x17, 0xF1, 0x60, 0x68,
0x12, 0xB7, 0x7A, 0xC3, 0xE9, 0xFA, 0x3D, 0x53,
0x96, 0x84, 0x6B, 0xBA, 0xF2, 0x63, 0x9A, 0x19,
0x7C, 0xAE, 0xE5, 0xF5, 0xF7, 0x16, 0x6A, 0xA2,
0x39, 0xB6, 0x7B, 0x0F, 0xC1, 0x93, 0x81, 0x1B,
0xEE, 0xB4, 0x1A, 0xEA, 0xD0, 0x91, 0x2F, 0xB8,
0x55, 0xB9, 0xDA, 0x85, 0x3F, 0x41, 0xBF, 0xE0,
0x5A, 0x58, 0x80, 0x5F, 0x66, 0x0B, 0xD8, 0x90,
0x35, 0xD5, 0xC0, 0xA7, 0x33, 0x06, 0x65, 0x69,
0x45, 0x00, 0x94, 0x56, 0x6D, 0x98, 0x9B, 0x76,
0x97, 0xFC, 0xB2, 0xC2, 0xB0, 0xFE, 0xDB, 0x20,
0xE1, 0xEB, 0xD6, 0xE4, 0xDD, 0x47, 0x4A, 0x1D,
0x42, 0xED, 0x9E, 0x6E, 0x49, 0x3C, 0xCD, 0x43,
0x27, 0xD2, 0x07, 0xD4, 0xDE, 0xC7, 0x67, 0x18,
0x89, 0xCB, 0x30, 0x1F, 0x8D, 0xC6, 0x8F, 0xAA,
0xC8, 0x74, 0xDC, 0xC9, 0x5D, 0x5C, 0x31, 0xA4,
0x70, 0x88, 0x61, 0x2C, 0x9F, 0x0D, 0x2B, 0x87,
0x50, 0x82, 0x54, 0x64, 0x26, 0x7D, 0x03, 0x40,
0x34, 0x4B, 0x1C, 0x73, 0xD1, 0xC4, 0xFD, 0x3B,
0xCC, 0xFB, 0x7F, 0xAB, 0xE6, 0x3E, 0x5B, 0xA5,
0xAD, 0x04, 0x23, 0x9C, 0x14, 0x51, 0x22, 0xF0,
0x29, 0x79, 0x71, 0x7E, 0xFF, 0x8C, 0x0E, 0xE2,
0x0C, 0xEF, 0xBC, 0x72, 0x75, 0x6F, 0x37, 0xA1,
0xEC, 0xD3, 0x8E, 0x62, 0x8B, 0x86, 0x10, 0xE8,
0x08, 0x77, 0x11, 0xBE, 0x92, 0x4F, 0x24, 0xC5,
0x32, 0x36, 0x9D, 0xCF, 0xF3, 0xA6, 0xBB, 0xAC,
0x5E, 0x6C, 0xA9, 0x13, 0x57, 0x25, 0xB5, 0xE3,
0xBD, 0xA8, 0x3A, 0x01, 0x05, 0x59, 0x2A, 0x46
};
#define G( k, i, h, l ) \
h ^= F[l ^ k[i]]; \
if ( ++i >= SJ_Keysize ) i = 0; \
l ^= F[h ^ k[i]]; \
if ( ++i >= SJ_Keysize ) i = 0; \
h ^= F[l ^ k[i]]; \
if ( ++i >= SJ_Keysize ) i = 0; \
l ^= F[h ^ k[i]]; \
if ( ++i >= SJ_Keysize ) i = 0;
#define G_Inverse( k, i, h, l ) \
l ^= F[h ^ k[i]]; \
if ( --i < 0 ) i = SJ_Keysize - 1; \
h ^= F[l ^ k[i]]; \
if ( --i < 0 ) i = SJ_Keysize - 1; \
l ^= F[h ^ k[i]]; \
if ( --i < 0 ) i = SJ_Keysize - 1; \
h ^= F[l ^ k[i]]; \
if ( --i < 0 ) i = SJ_Keysize - 1;
void
SJ_Encrypt ( const unsigned char *Key, const unsigned char *Plaintext,
unsigned char *Ciphertext
)
{
register int i;
unsigned char counter = 0;
unsigned char temp[2];
for ( i = 0; i < 8; ++i )
Ciphertext[i] = Plaintext[i];
i = 0;
while ( ++counter <= 8 )
{
temp[0] = Ciphertext[6];
temp[1] = Ciphertext[7];
Ciphertext[2] = Ciphertext[0];
Ciphertext[3] = Ciphertext[1];
Ciphertext[4] = Ciphertext[2];
Ciphertext[5] = Ciphertext[3];
Ciphertext[6] = Ciphertext[4];
Ciphertext[7] = Ciphertext[5];
G( Key, i, Ciphertext[2], Ciphertext[3] );
Ciphertext[0] = temp[0] ^ Ciphertext[2];
Ciphertext[1] = temp[1] ^ Ciphertext[3] ^ counter;
}
while ( ++counter <= 16 )
{
temp[0] = Ciphertext[6];
temp[1] = Ciphertext[7];
Ciphertext[2] = Ciphertext[0];
Ciphertext[3] = Ciphertext[1];
Ciphertext[4] = Ciphertext[2];
Ciphertext[5] = Ciphertext[3];
Ciphertext[6] = Ciphertext[4];
Ciphertext[7] = Ciphertext[5];
Ciphertext[4] ^= Ciphertext[0];
Ciphertext[5] ^= Ciphertext[1] ^ counter;
G( Key, i, Ciphertext[2], Ciphertext[3] );
Ciphertext[0] = temp[0];
Ciphertext[1] = temp[1];
}
while ( ++counter <= 24 )
{
temp[0] = Ciphertext[6];
temp[1] = Ciphertext[7];
Ciphertext[2] = Ciphertext[0];
Ciphertext[3] = Ciphertext[1];
Ciphertext[4] = Ciphertext[2];
Ciphertext[5] = Ciphertext[3];
Ciphertext[6] = Ciphertext[4];
Ciphertext[7] = Ciphertext[5];
G( Key, i, Ciphertext[2], Ciphertext[3] );
Ciphertext[0] = temp[0] ^ Ciphertext[2];
Ciphertext[1] = temp[1] ^ Ciphertext[3] ^ counter;
}
while ( ++counter <= 32 )
{
temp[0] = Ciphertext[6];
temp[1] = Ciphertext[7];
Ciphertext[2] = Ciphertext[0];
Ciphertext[3] = Ciphertext[1];
Ciphertext[4] = Ciphertext[2];
Ciphertext[5] = Ciphertext[3];
Ciphertext[6] = Ciphertext[4];
Ciphertext[7] = Ciphertext[5];
Ciphertext[4] ^= Ciphertext[0];
Ciphertext[5] ^= Ciphertext[1] ^ counter;
G( Key, i, Ciphertext[2], Ciphertext[3] );
Ciphertext[0] = temp[0];
Ciphertext[1] = temp[1];
}
}
void
SJ_Decrypt ( const unsigned char *Key, const unsigned char *Ciphertext,
unsigned char *Plaintext
)
{
register int i;
unsigned char counter = 32;
unsigned char temp[2];
for ( i = 0; i < 8; ++i )
Plaintext[i] = Ciphertext[i];
i = 127 % SJ_Keysize + 1;
while ( --counter > 24 )
{
temp[0] = Plaintext[0];
temp[1] = Plaintext[1];
Plaintext[0] = Plaintext[2];
Plaintext[1] = Plaintext[3];
Plaintext[2] = Plaintext[4];
Plaintext[3] = Plaintext[5];
Plaintext[4] = Plaintext[6];
Plaintext[5] = Plaintext[7];
G_inverse( Key, i, Plaintext[0], Plaintext[1] );
Plaintext[2] ^= Plaintext[0];
Plaintext[3] ^= Plaintext[1] ^ counter;
Plaintext[6] = temp[0];
Plaintext[7] = temp[1];
}
while ( --counter > 16 )
{
temp[0] = Plaintext[0] ^ Plaintext[2];
temp[1] = Plaintext[1] ^ Plaintext[3] ^ counter;
Plaintext[0] = Plaintext[2];
Plaintext[1] = Plaintext[3];
Plaintext[2] = Plaintext[4];
Plaintext[3] = Plaintext[5];
Plaintext[4] = Plaintext[6];
Plaintext[5] = Plaintext[7];
G_inverse( Key, i, Plaintext[0], Plaintext[1] );
Plaintext[6] = temp[0];
Plaintext[7] = temp[1];
}
while ( --counter > 8 )
{
temp[0] = Plaintext[0];
temp[1] = Plaintext[1];
Plaintext[0] = Plaintext[2];
Plaintext[1] = Plaintext[3];
Plaintext[2] = Plaintext[4];
Plaintext[3] = Plaintext[5];
Plaintext[4] = Plaintext[6];
Plaintext[5] = Plaintext[7];
G_inverse( Key, i, Plaintext[0], Plaintext[1] );
Plaintext[2] ^= Plaintext[0];
Plaintext[3] ^= Plaintext[1] ^ counter;
Plaintext[6] = temp[0];
Plaintext[7] = temp[1];
}
while ( --counter > 0 )
{
temp[0] = Plaintext[0] ^ Plaintext[2];
temp[1] = Plaintext[1] ^ Plaintext[3] ^ counter;
Plaintext[0] = Plaintext[2];
Plaintext[1] = Plaintext[3];
Plaintext[2] = Plaintext[4];
Plaintext[3] = Plaintext[5];
Plaintext[4] = Plaintext[6];
Plaintext[5] = Plaintext[7];
G_inverse( Key, i, Plaintext[0], Plaintext[1] );
Plaintext[6] = temp[0];
Plaintext[7] = temp[1];
}
}
int
SJ_Selftest( void )
{
register int i;
const unsigned char K[8] =
{
0x00, 0x99, 0x88, 0x77, 0x66,
0x55, 0x44, 0x33, 0x22, 0x11
};
const unsigned char P[8] =
{
0x33, 0x22, 0x11, 0x00,
0xDD, 0xCC, 0xBB, 0xAA
};
unsigned char C[8], P2[8];
const unsigned char Cexp[8] =
{
0x25, 0x87, 0xCA, 0xE2,
0x7A, 0x12, 0xD3, 0x00
};
SJ_Encrypt( K, P, C );
SJ_Decrypt( K, C, P2 );
for ( i = 0; i < 8; ++i )
if ( C[i] != Cexp[i] || P2[i] != P[i] )
return 0;
return 1;
}
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Q: How to find good characteristics for differential cryptanalysis?
Date: Wed, 17 May 2000 03:54:32 GMT
In article <[EMAIL PROTECTED]>,
JBR <[EMAIL PROTECTED]> wrote:
The is no general way to create a good differential. The sboxes and
the linear transforms of the function in question must be analyzed.
For large block ciphers, it is difficult to determine the best N round
characteristic.
Check out Eli Bihams web site. I believe he has several papers there
dicussing differential crypto. Cool stuff.
--Matthew
> [This is a re-post]
>
> Hello sci.crypt'ers,
>
> Given an iterated cipher, how would you go about finding
> high-probability characteristics for differential cryptanalysis?
>
> I've read several descriptions of differential cryptanalysis and
> understood them (for the most part, but not completely). What the
> authors didn't say was how they came up with the high-probability
> characteristics in the first place.
>
> Is there a surefire method for finding the most probable n-round
> characteristic for specific round structures?
>
> If not, what would be a good heuristic for finding good (but not
> necessarily optimal) n-round characteristics for unfamiliar round
> structures?
>
> In general, are the characteristics used in published differential
> cryptanalyses known to be optimal, or do they just work well enough?
>
> I don't have convenient access to a technical library, so a brief
> description of the relevant algorithms and heuristics would be
helpful.
> (Pointers are welcome too, of course).
>
> My sincere thanks in advance.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Wed, 17 May 2000 11:59:12 +0800
From: Raphael Phan Chung Wei <[EMAIL PROTECTED]>
Subject: Re: (May 16, 2000) Cipher Contest Update
==============98EA19C7DEE1FCBA496135AF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi,
I have taken a look at your description of BREAKME.. Under section "4. Breakme
Cipher", you forgot to add the xor with L_i-1
4. The BREAKME Cipher
N = 10 (Number of rounds)
L,R = 64-bit block to be encrypted.
K = Sub-key
L = L xor K_0
R = R xor K_1
For i = 0 up to N-1 do
L_i = F(R_i-1) xor L_i-1
R_i = R_i-1 xor K_i+2
Swap L_i and R_i
Next i
Good luck with the analysis. Nice effort you are doing, hosting this contest
:)
Raphael
Adam Durana wrote:
> Well the contest has picked up quite considerably. Right now there are 8
> ciphers in the listing. Since my last update posting, 3 new ciphers have
> been added. LJA2 by Andru Luvisi, SNAPPY by Tom St Denis, and BREAKME by
> yours truly. I also updated the web site. I added a new list, which lists
> the ciphers that have been broken. The cipher I submitted, BREAKME, should
> be easy to cryptanalyze and that is the reason it was submitted. I put it
> together in under an hour. It will be interesting to see how long it takes
> until it is broken. Also if anyone has any programs they have written to
> help them analyze any of the ciphers and would be willing to share, send
> them to me and I will post them on the web site.
>
> - Adam
==============98EA19C7DEE1FCBA496135AF
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
<p>I have taken a look at your description of BREAKME.. Under section "4.
Breakme Cipher", you forgot to add the xor with L_i-1
<p>4. The BREAKME Cipher
<p>N = 10 (Number of rounds)
<br>L,R = 64-bit block to be encrypted.
<br>K = Sub-key
<p>L = L xor K_0
<br>R = R xor K_1
<p>For i = 0 up to N-1 do
<br> L_i = F(R_i-1) <b>xor L_i-1</b>
<br> R_i = R_i-1 xor K_i+2
<br> Swap L_i and R_i
<br>Next i
<p>Good luck with the analysis. Nice effort you are doing, hosting
this contest :)
<p>Raphael
<p>Adam Durana wrote:
<blockquote TYPE=CITE>Well the contest has picked up quite considerably.
Right now there are 8
<br>ciphers in the listing. Since my last update posting, 3 new ciphers
have
<br>been added. LJA2 by Andru Luvisi, SNAPPY by Tom St Denis, and
BREAKME by
<br>yours truly. I also updated the web site. I added a new
list, which lists
<br>the ciphers that have been broken. The cipher I submitted, BREAKME,
should
<br>be easy to cryptanalyze and that is the reason it was submitted.
I put it
<br>together in under an hour. It will be interesting to see how
long it takes
<br>until it is broken. Also if anyone has any programs they have
written to
<br>help them analyze any of the ciphers and would be willing to share,
send
<br>them to me and I will post them on the web site.
<p>- Adam</blockquote>
</html>
==============98EA19C7DEE1FCBA496135AF==
------------------------------
Date: Wed, 17 May 2000 00:15:49 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Tiny Stream Cipher "slime"
Tom St Denis wrote:
> In article <8fsg5a$611$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > I just designed a compact, simple and somewhat fast stream cipher
> which
> > I called (for some reason) Slime. It requires all of 16 bytes of ram
> > to work, and can be written in under 50 or so lines of code (most of
> > which is the sbox).
> >
> > My mini-paper at (http://www.tomstdenis.com/slime.txt) includes source
> > and test vectors.
> >
> > I have tried to poke at it a bit, I dunno if it's really secure, but
> it
> > looks nice.
> >
> > Any feedback would be nice.
> >
> > Thanks,
> > Tom
>
> Wow, I just noticed something.... I make up two keys K1 and K2, I make
> K2 differ by one bit. Then I xor the two streams together... expecting
> the output to pass diehard... it fails misserably...
>
> Any ideas to why it fails?
Most probably because the ciphertexts are related. Such correlation is a red
flag for strength.
------------------------------
** 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
******************************
