Cryptography-Digest Digest #799, Volume #11 Wed, 17 May 00 10:13:00 EDT
Contents:
Re: Skipjack implementation in C (RogerStaub)
QUESTIONS About ALGOS !! ("Karim A")
What is the advantage of undeniable signature? ("B.T.")
Re: Fixed the stream cipher "Slime"? (Runu Knips)
Re: Creating a good key-shedule (David Blackman)
Re: zeroknowledge.com and freedom.net - Snake oil?
([EMAIL PROTECTED])
Re: Is OTP unbreakable? (R124c4u2)
Re: Diffie's Randomized Stream Cipher (Tim Tyler)
Re: Creating a good key-shedule (Tim Tyler)
Anonymouse URL-CHANGE ([EMAIL PROTECTED])
AEES-Cascade ([EMAIL PROTECTED])
Re: Crypto & UNICODE??? (fork)
Chosen plaintext attack, isn't it absurd? ("Manuel Pancorbo")
Re: Introduction to zero knowledge proofs? (David A Molnar)
Re: What is the advantage of undeniable signature? (David A Molnar)
Re: Interesting differentials in BREAKME (Mark Wooding)
----------------------------------------------------------------------------
From: RogerStaub <[EMAIL PROTECTED]>
Subject: Re: Skipjack implementation in C
Date: Wed, 17 May 2000 08:21:56 -0400
Bad news, Doug. I can tell that the code below has never been
successfully compiled or run, because it contains logical errors and it
fails its own SJ_Selftest() function.
In SJ_Decrypt(), the G_inverse calls should be G_Inverse (capital "I").
In SJ_Selftest(), array K is specified as size eight but is given ten
initializers.
After fixing the above problems, the SJ_Selftest() function will not
return non-zero (ie, success), so there may be more errors somewhere
else in the code.
"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;
> }
------------------------------
From: "Karim A" <[EMAIL PROTECTED]>
Subject: QUESTIONS About ALGOS !!
Date: Wed, 17 May 2000 14:33:07 +0200
Reply-To: "Karim A" <[EMAIL PROTECTED]>
Hi all,
I'm new in Encryption, and I've to implement an Encryption Algo
for an application.
But I have to make a choice between efficiency and speed !
Well I'd like to know if the DES / 3DES is a very fast algo ?
I've been told that Blowfish algorithm was very fast and secure.
What do you think about it ?
Thanks is advance,
Karim
------------------------------
From: "B.T." <[EMAIL PROTECTED]>
Subject: What is the advantage of undeniable signature?
Date: Wed, 17 May 2000 20:18:57 +0800
Compare wtih the RSA or ElGamal digital signature,
what is the advantage of the undeniable signature?
The undeniable signature needs the signer's help to
prove the validity of the signature. Contrarily, RSA
or ElGamal doesn't need the signer's help. Anyone
gives some comments?
------------------------------
Date: Wed, 17 May 2000 14:47:59 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Fixed the stream cipher "Slime"?
Tom St Denis wrote:
> IOW, it's sucks, it's broken, shame on me, sorry guys, it's done.
Hehe - funny definition of being broken: failed to implement
on two different compilers !! *giggle* ;-)
------------------------------
From: David Blackman <[EMAIL PROTECTED]>
Subject: Re: Creating a good key-shedule
Date: Wed, 17 May 2000 22:59:10 +1000
Tom St Denis wrote:
>
>
> 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
Speaking of which, i tried a couple of brute force runs where i ran the
pikachu F function for every possible input. I guess that wouldn't work
too well with double the block size.
The results were a bit weird.
First i did a big table with input bits against a count of how many
times each output bit was 0. It's a 32 x 32 table. There's 2G possible
inputs with a 1 in position 0. 1G of them have an output with a 1 in
position 0. So 0,0 in the table is 1G. Same idea for the rest of the
table. Every single entry is exactly 1073741824. Did you design for that
specifically?
Next, i figured that if there's a weak point it's probably at the least
significant bit of each byte. So taking those bits at input and output
gives us a 16 x 16 table of counts. (Eg entry 3,10 is the number of
inputs with 0,0,1,1 for least significant bits that give 1,0,1,0 for
least significant bits of output.) Obviously these have to average out
at 16M.
The highest was 18670080 and the lowest 14999040. That's a lot more
variation than you'd expect for a random permutation. Also the numbers
in the table have a definite pattern. Try it yourself, the run only took
a few minutes.
Probably this gives scope for some sort of attack using only the low
order bits of each byte. But i am just starting cryptography (haven't
even read Schneier yet), so i will actually have to think before i know
how to work this properly. I will try a few ideas on the weekend, but if
anyone else wants to run with this, please do.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: zeroknowledge.com and freedom.net - Snake oil?
Date: Wed, 17 May 2000 13:23:01 GMT
In article <[EMAIL PROTECTED]>,
Anton Stiglic <[EMAIL PROTECTED]> wrote:
>...
> > > 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.
I've just seen that home.pages.de has blocked my Domain. Maybe that
was the reason. The new URL is http://anonymouse.is4u.de/
GreetingX,
Alex
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (R124c4u2)
Subject: Re: Is OTP unbreakable?
Date: 17 May 2000 13:31:51 GMT
[EMAIL PROTECTED] writes:
>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.
Visualize a hardware exclusive or, one input random the other input 'stuck on
one'. What is the output?
Now visualize the case where one input is 'stuck on zero'. What is the output?
Can the two cases be distinguished? If so, how?
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Diffie's Randomized Stream Cipher
Reply-To: [EMAIL PROTECTED]
Date: Wed, 17 May 2000 12:39:27 GMT
Andru Luvisi <[EMAIL PROTECTED]> wrote:
: On page 419 of the 2nd edition of Applied Cryptography, Bruce Schneier
: mentions a scheme invented by Whitfield Diffie where you send someone
: 2^n random bit strings, and then the message xored against one of
: them. The key is an n bit value which specifies which one. He says
: "Any attack must examine an expected number of bits which is in
: O(2^n). Rueppel points out that if you send n random strings instead
: of 2^n, and if the key is used to specify a linear combination of
: those random strings, the security is the same."
This last appears to me to be questionable. If you only need to store "n"
strings, and perform linear operations on them, the work required to do
this on any practical computer architecture will become small compared to
the work compared to store 2^n strings as n increases.
This is because storing huge numbers of strings takes up space, reducing
the mean time-to-access each member - while by contrast you can hold "n"
strings locally in a cache.
The only way you can get the same security figure is if you count
key attempts - and ignore the work-factor behind each attempt.
I also believe the strings have to be long enough for the chance of them
being linear combinations of one another by chance to be miniscule - since
if they /are/ linear combinations of other strings, they can simply be
discarded from the keyspace search by the attacker before he begins.
: Am I correct in understanding this to mean that if I use a 128 bit
: key, and for every plaintext byte I send 128 random bytes, along with
: the xor of the ones selected by the 1 bits in the key and the
: plaintext byte (129 bytes in total), the result is a 128 bit cipher
: against which brute force is guaranteed to be the best attack?
Note that n = 128 - thus you need to send 128 *linearly independent*
random bytes - plus a key of 128 bits to choose how they are combined -
for the scheme to have any chance of working properly at all.
Unfortunately for the scheme, this is totally impossible.
Also note that there may be attacks on the RNG used to choose
the key, and attacks on the RNG used to generate the pads.
: Also, does anyone know how important the randomness of the random
: parts is?
In the original scheme it's used as an OTP. Deviations from randomness
are liable to leak information "in the usual way".
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Goodbye cool world.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Creating a good key-shedule
Reply-To: [EMAIL PROTECTED]
Date: Wed, 17 May 2000 12:47:43 GMT
Simon Johnson <[EMAIL PROTECTED]> wrote:
:Tom St Denis wrote:
:> A 16 bit block doesn't make for a very secure block cipher.
: Why?
: Surely its easier to defuse & confuse using a 16-bit block?
It is certainly easier to diffuse using a 16-bit block.
The problem is that attackers can probably use known-plaintext to build a
table of the relationships between plaintext blocks and cyphertext blocks.
With a 128-bit block size, they would need *lots* of storage space to do
this - but with a 16-bit block size, they can build the whole table
happily in only 64 kB of memory :-(
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Goodbye cool world.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.2600,alt.hackers.malicious
Subject: Anonymouse URL-CHANGE
Date: Wed, 17 May 2000 13:35:26 GMT
Anonymouse for free anonymous surfing, emailing and posting formerly
under http://anonymouse.home.pages.de/ is now located under
http://anonymouse.is4u.de/ or http://anonymity.is4u.de/
Please update your Bookmarks!
GreetingX,
Alex
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: AEES-Cascade
Date: Wed, 17 May 2000 13:44:20 GMT
AEES-Cascade is 640-bit DES-like block cipher, where
cascade of F-funcrions is used instead of rounds.
Performance of AEES-Cascade excluding I/O operations was measured
sending for encryption 410Mb in a loop. It is 931 Kb/sec.
There is followning architecture of F-fubction:
256 byte key length
S-box is multiplication table of a group of the order 256
16 sub-key-dependent S-boxes
16 sub-keys 256 bytes length
IP and inverse one are sub-key dependent
EP and P are sub-key dependent
XOR with current sub-key
XOR with left part of input
The Avalanche Effect of AEES-Cascade.
A desirable property of any encryption algorithm is that a small
change in either the plaintext or the key should produce a
significant change in the ciphertext. For 64-bit block DES change
only one bit gives 34 bit change in ciphertext. This makes 53%.
To be able to compare AEES-Cascade implementation (640-bit) with
DES (64-bit) we should change the same amount of information namely
10 bits. Two ciphertexts encrypted with AEES-Cascade differ in 303
bits, which makes 47,3%.
With two keys that differ in only one bit position in DES
we have about 50% of the bits in the ciphertext differ.
In AEES we are using 2048 bits key. To be able to compare
key avalanche effect with DES we should change 37 bits.
Again, the results show that about half of the bits in the
cipher text differ.
Algorithm description and source code can be found
at <www.alex-encryption.de>
Please follow download or view link for 'AEES-Cascade'.
Best regards.
Alex.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: fork <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Crypto & UNICODE???
Date: Wed, 17 May 2000 09:56:49 -0400
Runu Knips wrote:
> By the way, one normally doesn't store unicode the way you've described
> it. Basically, one sets the msb of the first byte if the character is
> larger than 7 bit, saving the rest of the bits in the next character
> where again a flag is set if that character is still not enough. This
> way every unicode character is stored in 1 to 3 bytes on disk.
Is it not UTF8 ?
=================
Daniel Léonard (aka fork)
Computer Science Student
Université de Montréal
"The nuclear warhead is one of the Humans' most efficient weapons. They
first tested it on themselves, obliterating several entire cities. The
intervening centuries since the weapon's first use had not dimmed its
effectiveness, as the Black Star proved when it blew apart. It was, from
all accounts, a most impressive display and took - by the standart of
such thing - quite some time as one section after another after another
of the ship erupted."
- Emperor Londo Mollari, Babylon 5 : In the Beginning
------------------------------
From: "Manuel Pancorbo" <[EMAIL PROTECTED]>
Subject: Chosen plaintext attack, isn't it absurd?
Date: Wed, 17 May 2000 15:42:28 +0200
I mean, if the attacker is able to access the encipher machinery (but not
the actual key) and then test the ciphertexts she wants, what stops her to
access the DEcipher machinery?
I posted here some months ago a question about the security of an algorithm
with involution property, that is cryptosystem where encryption =
decryption:
Ek(Ek(m)) = m
If the above argument is really silly (counterarguments, please) I will
quickly understand why involution algorithms are weak!
--
____________________________________________________________________________
_________
Manuel Pancorbo
[EMAIL PROTECTED]
"...
Más vale aprender una sola línea de Ciencia
que postrarse cien veces en oración. (Corán)
Pli valoras lerni ech nur unu linion de Scienco
ol preghe genui cent fojojn. (Korano)
..."
____________________________________________________________________________
_________
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Introduction to zero knowledge proofs?
Date: 17 May 2000 13:39:02 GMT
Volker Hetzer <[EMAIL PROTECTED]> wrote:
> Hi!
> Is there any good introduction on zero knowledge
> proofs out there?
There is some material in Neal Koblitz _A Course in Number Theory
and Cryptography_. I don't have the book with me at the moment, but
it outlines the notion of a simulator, justifies why being able to
simulate a protocol shows it is zero-knowledge, and gives some sample
zero-knowledge protocols (I think graph non-isomorphism and 3-coloring?).
It's probably not a *bad* introduction, but I don't think it covers things
like the fact that there are various _types_ of zero-knowledge protocols,
depending on what you allow verifiers to do. For example, do you assume
that the verifier is always "honest" -- i.e. that she always sends exactly
what she's supposed to send in each part of the protocol? If you do, then
proving things becomes much easier...but you're a fool if you think that
the resulting proof will necessarily hold up in the real world.
Another example is the notion of "concurrent" zero-knowledge -- is your
protocol zero-knowledge even if the adversary can open up 15,000,000
different sessions with you at different times and pass information
between all of them while still in the middle of the protocol? Turns out
most protocols can't be proved zero-knowledge in this case, and there's
supposed to be at least one example of a protocol which fails badly under
this attack. (I haven't gone and hunted down the paper yet).
I don't know of any really good textbook. I'd be very interested to hear
if one exists. There is the book by Oded Goldreich on probabilistic proofs
from Springer, but that doesn't really cover zero-knowledge proofs (and
it's very expensive, too). Your best bet may be online course notes from
courses with a "theory of cryptography" bent.
The Bellare and Goldwasser lecture notes from their summer course have a
short section on zero-knowledge proofs and an appendix with the complexity
theory background you may want. You can find them at
http://www-cse.ucsd.edu/~mihir/papers/gb.html
Light on applications, but you should be able to get some idea of what you
need to know and what's going on.
Probably the most comprehensive reference is the
chapter on zero-knowledge protocols in Goldreich's "Fragments of a
Book." It's not easy going.
It looks like he's writing another book on the foundations of
crypto as well; maybe this will be more accessible. Both at :
http://www.wisdom.weizmann.ac.il/home/oded/public_html/index.html
There is a list of online courses kept by Avi Rubin at :
http://avirubin.com/courses.html
Good luck,
-David Molnar
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: What is the advantage of undeniable signature?
Date: 17 May 2000 13:51:16 GMT
B.T. <[EMAIL PROTECTED]> wrote:
> Compare wtih the RSA or ElGamal digital signature,
> what is the advantage of the undeniable signature?
> The undeniable signature needs the signer's help to
> prove the validity of the signature. Contrarily, RSA
> or ElGamal doesn't need the signer's help. Anyone
> gives some comments?
ISTR that one example is a publisher of virus protection
software which signs its updates with undeniable signatures. Then it
validates the signature only for registered users. Unregistered users
thereby have no way of telling whether a "new update" is genuine or a
spoof, therefore they have an incentive to pay $$$ to the publisher.
This completely ignores the fact that one person can buy a subscription
and then validate updates for all his friends. I think in the original
protocol his friends don't even have to trust him; he just authenticates
himself to the publisher and then diverts the traffic to his friend.
Thanks,
-David
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Interesting differentials in BREAKME
Date: 17 May 2000 14:04:59 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> What does "zero-output" mean? Zero difference in the output for
> different inputs? ARrg... Iwish I wasn't such a retard... damn it!!!
<grin>
By `zero-output probability', I meant `probability of an output
difference of zero'. I apologize for my lack of clarity.
-- [mdw]
------------------------------
** 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
******************************
