Cryptography-Digest Digest #798, Volume #11 Wed, 17 May 00 09:13:01 EDT
Contents:
Re: Skipjack implementation in C (RogerStaub)
Re: homophones (UBCHI2)
Re: Is OTP unbreakable? ([EMAIL PROTECTED])
Re: Skipjack implementation in C (RogerStaub)
Re: Crypto & UNICODE??? (Marcin Jaskolski)
Re: Creating a good key-shedule (Tom St Denis)
Re: Crypto & UNICODE??? (John Savard)
Re: zeroknowledge.com and freedom.net - Snake oil?
([EMAIL PROTECTED])
Re: Interesting differentials in BREAKME (Tom St Denis)
Re: Definition of "Broken" Cipher (Nicol So)
Re: zeroknowledge.com and freedom.net - Snake oil?
([EMAIL PROTECTED])
Re: bamburismus (John Savard)
----------------------------------------------------------------------------
From: RogerStaub <[EMAIL PROTECTED]>
Subject: Re: Skipjack implementation in C
Date: Wed, 17 May 2000 07:47:14 -0400
"Douglas A. Gwyn" wrote:
>
> /*
> 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;
> }
Thanks. I found one on an FTP site (ftp.funet.fi), but it doesn't
work. It compiles, but it doesn't encrypt or decrypt correctly.
Besides that, it's got some extra crap in it that has nothing to do with
Skipjack (and I wasn't looking forwarding to weeding that stuff out).
------------------------------
From: [EMAIL PROTECTED] (UBCHI2)
Subject: Re: homophones
Date: 17 May 2000 11:48:46 GMT
If they attack the cipher with frequency analysis of homophones, digraphs etc.,
then a transposition key prior to encryption is necessary.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Is OTP unbreakable?
Date: Wed, 17 May 2000 11:41:11 GMT
I am pretty convinced that some of the non random pattern of the
plaintext shows up in the ciphertext...If that is the case, then XORing
non-random data with a random key does not necessarily produce a random
output.
In previous discusions on this issue, some have recommended doing a
compression before the XOR.
I would certainly compress the plaintext before XORing with the Key.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: RogerStaub <[EMAIL PROTECTED]>
Subject: Re: Skipjack implementation in C
Date: Wed, 17 May 2000 07:50:25 -0400
"Douglas A. Gwyn" wrote:
>
> "Douglas A. Gwyn" wrote:
> > SKIPJACK implementation in Standard C
>
> Oops, sorry! I meant for that to go to the requester,
> not the newsgroup. (Darned "user-friendly" newsreader
> interface.) However, you're welcome to use it,
> just please don't tell me how to "improve" it.
Actually, I'm glad you posted it because it wouldn't have made it to me
via e-mail. I always use a fake e-mail address when I post to Usenet,
to avoid spammers and net kooks.
------------------------------
From: Marcin Jaskolski <[EMAIL PROTECTED]>
Subject: Re: Crypto & UNICODE???
Date: Wed, 17 May 2000 13:52:59 +0200
On Wed, 17 May 2000, Mok-Kong Shen wrote:
>
>
> Kenneth Cascio wrote:
>
> > If I have a plaintext Message "ABCDEFG" (Represented in memory by 7-Bytes
> > (HEX): 41, 42, 43, 44, 45, 46, 47) that I want to keep a secret (i.e.
> > encrypt) and my application is using standard ASCII character strings (1
> > byte per character), than an eavesdropper, unless he has other methods, can
> > not infer anything about my original message from the ciphertext.
> >
> > On the other hand, if my application is using UNICODE instead of ASCII, the
> > same message "ABCDEFG", now occupies 14-Bytes of memory (UNICODE is a
> > multi-byte character) and is represented in memory (on an Intel based
> > machine) as: 41, 0, 42, 0, 43, 0, 44, 0, 45, 0, 46, 0, 47, 0. Any algorithm
> > acting on this block of memory (now 14 bytes) will be encrypting the 0s
> > which are now part of the message.
> >
> > The eavesdropper could now infer (if he knows anything about my system)
> > parts of the original plaintext message. He/she could assume that the
> > original message looked something like this: ?, 0, ?, 0, ?, 0, ?, 0, ?, 0,
> > ?, 0. The "?" represents an unknown BYTE and the 0s are the known BYTES
> > (zeros). Now, he/she knows half of my original message! With this
> > information, I would think that a "Known Plaintext Attack" could be used in
> > an attempt to decrypt the ciphertext.
>
> Sorry for my ignorance. I don't yet understand your agruments. If, as
> you said, the opponent knows of you system that every other byte is
> a meaningless 0, then he reduces the information obtained to that of
> the first case you described. How can he be in a better position to
> crack than in the first case? Presumably I have missed quite a lot.
> Could you please illustrate with a tiny concrete example of your
> known plaintext attack? Thanks in advance.
>
hmmm. I don't really have the point. If the cryptosystem works in way
described above, then itlooks like a block cipher taking only one
byte at a time, then encrypting it. So, message AAABBBCCCAAA will be
encrypted like that : XXXYYYZZZXXX., Then its
1.very vulnerable to chosen plaintext attacks - the attacker will
encrypt the message :ABCD.....WXYZ - then he will know everything;
2.vulnerable to known plaintext attacks - the eavesdropper is likely to
decrypt part of the message;
3.assuming you are using english language in your secrets, attacker
can guess quite a lot by doing statistical research - for example
AFAIK the 'e' letter is very often used in english - you got the point
I think you should use a block cipher which takes at leas, say 128 bits
(?) at a time. Attacks described above will become, uhm, not very
practical :-)
Habe a nice day,
Marcin Jaskolski
[EMAIL PROTECTED]
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Creating a good key-shedule
Date: Wed, 17 May 2000 11:51:35 GMT
In article <[EMAIL PROTECTED]>,
David Blackman <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> >
> > In article <[EMAIL PROTECTED]>,
> > David Blackman <[EMAIL PROTECTED]> wrote:
>
> > > There's really no reason not to go
> > > 128 bits or even larger. A 128 bit block can probably be encrypted
> > > securely slightly faster than 2 64 bit blocks on current
hardware, so
> > > you may even win on performance.
> >
> > Well yea, I think 128-bits is a good starting point, but not alot of
> > amateurs want to start there... so start with 64 bits.
> >
> > Tom
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
> Why don't people want to start at 128 bits? It doesn't look hard to
do.
Well it may be just me, but normally I find it easier to get a hint if
it's any good with smaller block sizes.
I dunno, I really am retarded when it comes to serious cryptanalysis,
but I can normally spot "no-no"s in smaller F functions with less
inputs,etc...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Crypto & UNICODE???
Date: Wed, 17 May 2000 12:01:21 GMT
On Tue, 16 May 2000 18:30:40 -0400, "Kenneth Cascio"
<[EMAIL PROTECTED]> wrote, in part:
>If I have a plaintext Message "ABCDEFG" (Represented in memory by 7-Bytes
>(HEX): 41, 42, 43, 44, 45, 46, 47) that I want to keep a secret (i.e.
>encrypt) and my application is using standard ASCII character strings (1
>byte per character), than an eavesdropper, unless he has other methods, can
>not infer anything about my original message from the ciphertext.
>On the other hand, if my application is using UNICODE instead of ASCII, the
>same message "ABCDEFG", now occupies 14-Bytes of memory (UNICODE is a
>multi-byte character) and is represented in memory (on an Intel based
>machine) as: 41, 0, 42, 0, 43, 0, 44, 0, 45, 0, 46, 0, 47, 0. Any algorithm
>acting on this block of memory (now 14 bytes) will be encrypting the 0s
>which are now part of the message.
You are correct that UNICODE increases redundancy, but "can not infer
anything" isn't quite accurate for the ASCII case: the first bit of
each byte for ASCII text is always zero, and for upper and lower case
letters, the second bit is one, so that, too, will be true most of the
time.
However, this doesn't mean that UNICODE will stop everyone from using
cryptography, for two reasons:
1) Starting with DES, modern cipher algorithms are designed to
withstand a known-plaintext attack, and
2) Files can be, and often are, compressed before being encrypted. As
this works by removing redundancy, it directly addresses this kind of
problem.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: zeroknowledge.com and freedom.net - Snake oil?
Date: Wed, 17 May 2000 11:59:45 GMT
In article <[EMAIL PROTECTED]>,
Anton Stiglic <[EMAIL PROTECTED]> wrote:
> > Sure this point is the catchiest point. Anonymizers rewrite URLs,
> > but therefore they work behind firewalls!
> >
> > > For example, I just tried to connect to http://www.thematrix.com
> > > from your anonymouse.home.pages.de and I got an error:
> > > the requested URL could not be retrieved
> > >
> > > >While trying to retrieve the URL: http://mainframe.html
> > > ...
> >
> > Just get no connection to thematrix.com, will try that later. Maybe
> > it uses JavaScript? ... My latest Anonymizer-Version can handle
> > JavaScript, but is not publically available .. only useable in the
> > university.
>
> The direct connection to www.thematrix.com was fine, it must have been
> some JavaScript. This is the point of the remark I made just above,
> unless you can predict *every* single situation, every Microsoft
> HTML tag, every ...., there are some pages you won't be able to
> view with such an Anonymizer, that is it's major inherent bug. Just
> from a software engineering point of view, that is not how you should
> resolve the problem of privacy.
My Anonymizer doesn't need to know any tag, it uses other techniques.
Can you name those pages, which are not viewable by an Anonymizer?
Sure if I use a proxy-server every request will go through it, but it's
not as comfortable as with a Web-Anonymizer. There can be "hostile"
HTML-Code that may bypass the Web-Anonymizer, but this can also happen
with Proxy-Servers. Think of hostile Java-Applets ...
My goal was an easy-to-use, useable-by-nearly-everyone (behind
firewalls) no-need-to-install Anonymizer. And that's a Web-Anonymizer.
> > > My friend beside me couldn't even connect to anonymouse, it gave
> > > him a link that gives him the choice of clicking on Netscape or
IE,
> > > he's got the same version of Netscape that I have??
> >
> > Well, maybe he has a slow connection to anonymouse ... if I had as
> > much money as ZKS I could setup more, better, faster and more secure
> > (SSL) servers.
>
> Same connection (same intranet), same PIII computer, except he
> reconfigured some of his netscape options, which I believe is the
> cause of the problem.
> Again, supporting my above remark.
Interesting. No one has reported me a similar problem yet ...
> > > Freedom is the only seriously built privacy device that considered
> > > the best known theoretical results and that truly tries to provide
> > > adequate security and privacy and is always honest to their
> > > customers.
> >
> > Everyone can say that he is honest. How can you ensure, that the
> > carrier of the servers, where the requests run through, are
> > trustworthy?
> >
> > GreetingX,
> > Alex
> >
>
> You can't, that is why Freedom is trying to get as many possible so
> that the client can chose which one he trusts (we used to have 50, I
> think we have 150 now, I don't know the exact figures...). But this
> is a weird remark coming from someone who promotes Anonymizers over
> Freedom, since with an Anonymizer, all of your privacy relies on the
> fact that one single server (the one that runs the Anonymizer), is
> not logging what you are doing. Freedom gives you a theoretically
> proven way of giving you some cushion factor (at least one server out
> of the 3 that you have chosen has to be honest, and that's all you
> need).
Web-Anonymizers could be chained in a special way or there could be
a Onion-Router behind the Anonymizer, so there is also Anonymity
against the Anonymizer-Server ... but I don't have enough money
to provide that.
GreetingX,
Alex
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Interesting differentials in BREAKME
Date: Wed, 17 May 2000 12:00:31 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mark Wooding) wrote:
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] (Mark Wooding) wrote:
> > > Watch out particularly for zero-output differentials. Adam:
where did
> > > you get that S-box: it's awful.
>
> Mea typo. That should have been a `?' at the end. (I have an excuse:
> this was a rapid retype after my news client lost the original.)
>
> > I think he told me the max differential was 32/256 which is 1/8,
which
> > is what you found in the round function right?
>
> Indeed. In fact there's only one input difference with a 1/8
> zero-output probability.
What does "zero-output" mean? Zero difference in the output for
different inputs? ARrg... Iwish I wasn't such a retard... damn it!!!
> The big problem was that it had an output of zero, giving me a free
> second round each time. And I'd just been looking at Rijmen and
> Knudsen's cryptanalysis of LOKI97, which uses a very similar idea (and
> ends with the immortal words, `Conclusion: LOKI97 is broken.'
I liked that paper :)
> > However this cipher was designed to be cryptanalyzed.
>
> Well designed, then ;-)
And perfectly bad use of sboxes made by my program...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Definition of "Broken" Cipher
Date: Wed, 17 May 2000 08:09:00 -0400
Reply-To: see.signature
"Douglas A. Gwyn" wrote:
>
> 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.
That, of course, is only a kind of heuristic thinking that doesn't
always lead to the right decision.
"Broken", as an English word, is ambiguous. When something is "broken",
it may be malfunctioning, it may have been defeated, or it may not work
the way it's supposed to. Algorithms don't malfunction, so the first
meaning doesn't really apply to ciphers. For the second and third
meanings, they are relative to what the cipher in question is supposed
to do.
If a cipher is used to protect the privacy of information, "faster than
brute force" is not a useful criterion for judging whether it is broken.
(More specifically, "faster than brute force" is not a sufficient
condition for a cipher to be broken). Using that criterion, the
public-key ciphers that I can think of are all immediately disqualified
as broken.
On the other hand, block ciphers are sometimes used as a building block
for more complex primitives, such as hash functions and pseudorandom
number generator. The constructions usually assume an abstract,
idealized cipher. If a cipher demonstrates properties that are not
expected of an idealized cipher, it may break the model and invalidate
the analyses built upon it. That, however, doesn't automatically mean
the derived designs (hash function, pseudorandom number generator etc)
are weak, or not suitable for a specific purpose.
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: zeroknowledge.com and freedom.net - Snake oil?
Date: Wed, 17 May 2000 12:07:34 GMT
In article <8ftn5f$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Guy Macon) wrote:
>...
> >Sure this point is the catchiest point. Anonymizers rewrite URLs,
> >but therefore they work behind firewalls!
>
> If the users of the firewall I administer want to use either of your
> products and I don't want them to, I can stop them. (in real life I
> would offer free tech support!). Your system doen't change this.
And if I don't want that the users don't use ZKS I can stop them
too. Now what?
NO System can change that, but Web-Anonymizers work behind firewalls
(until the admin restricts it) Proxy-based Servers as ZKS don't.
>...
GreetingX,
Alex
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: bamburismus
Date: Wed, 17 May 2000 12:07:45 GMT
On Tue, 16 May 2000 18:59:48 +0200, "Ferrante Formato"
<[EMAIL PROTECTED]> wrote, in part:
>Any information about Turing's Bamburismus?
>It was a probabilistic meythod settled to crack Enigma code in WWII
It was a variation on the Kappa test.
In the kappa test, two enciphered texts are compared to one another at
various offsets (displacements in characters) and where the number of
matching letters is similar to the higher number that would be
produced by two unrelated plaintexts, rather than the lower number by
two random sequences of letters, it becomes likely that the two texts
were enciphered in the same key.
Banburismus (the name derived from Banbury) was a refinement of this
that gave extra weight to coincidences of more than one contiguous
letter, since languages have additional structure (or redundancy) at
the digraph, trigraph, and word levels, for example.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/
------------------------------
** 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
******************************
