Cryptography-Digest Digest #250, Volume #9 Thu, 18 Mar 99 21:13:03 EST
Contents:
Re: Is TEA Algorithm safe???? ([EMAIL PROTECTED])
Re: Quantum Computation and Cryptography ([EMAIL PROTECTED])
Re: Testing Algorithm (hash) ([EMAIL PROTECTED])
Re: RC4 file encryptor (please take a look) ([EMAIL PROTECTED])
Re: scramdisk problem (Charles W.)
Re: Partial key exposure (Scott Fluhrer)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Is TEA Algorithm safe????
Date: 18 Mar 1999 23:05:45 GMT
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] (Mark Carroll) writes:
>In article <[EMAIL PROTECTED]>, melih <[EMAIL PROTECTED]> wrote:
>>Can anyone tell me if TEA algorithm is safe (I am told it is not safe
>>however the reason as to why is what I am after).
>>
>>If not, does TEA Extensions solve the problems that made the TEA unsafe?
>
>I can't remember what the breaks are but the papers seem fairly
>well-known. Nothing too damning, but enough.
enough under what assumptions? i mean if your threat model does not include
the NSA or anyone with a major bankroll and you want a fast cipher would
TEA still be acceptable?
--
Lamont Granquist ([EMAIL PROTECTED])
ICBM: 47 39'23"N 122 18'19"W
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Quantum Computation and Cryptography
Date: 18 Mar 1999 23:13:00 GMT
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
>> so, what's wrong with having three outputs and "throwing away" the
>> output of the other two?
>
>"Throwing away" is not a unitary operation.
Sure it is. You just have to be able to make sure that it doesn't
interact with anything and "collapse the wavefunction". Just have an
output that you never subsequently do anything with.
--
Lamont Granquist ([EMAIL PROTECTED])
ICBM: 47 39'23"N 122 18'19"W
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Testing Algorithm (hash)
Date: Thu, 18 Mar 1999 23:22:56 GMT
> Your frequency tests don't match mine. I replaced the driver
> part of th1.c as shown at the end of this msg, in order to run
> a bunch of randomish 20-byte plaintexts through it. By the way,
> strlen() will stop on a null byte, so your driver as it stands
> won't hash general binary files. My modification outputs the
> hashes of 2^20 20-byte plaintexts taken from /dev/urandom but
> does not change the actual hash code.
>
I used 2^25 4-byte strings. What I will do is plug in data from a large file
and perform 2^20 tests. I will get back to you.
>From what I can tell it doesn't have known biases. But you may be correct.
(thanks for your interest :) )
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RC4 file encryptor (please take a look)
Date: Thu, 18 Mar 1999 23:16:36 GMT
> > Basically I want to have people evaluate the effectiveness of the
public_key
> > portion.
>
> There is no public/private key pair in the program. Are you
> talking about the salt?
You're right I used the wrong term. It should read public/private portions of
the key.
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Charles W.)
Subject: Re: scramdisk problem
Date: Thu, 18 Mar 1999 23:20:33 GMT
On 14 Mar 1999 22:30:18 -0000, [EMAIL PROTECTED] (Gretchen Anonymous
Remailer) wrote:
>I've created a scramdisk volume on my hard drive. But when I try to copy or
>move a folder or file into the mounted volume I get a message to say that
>access has been denied 'cannot create or replace (folder name)'. Does anyone
>recognise this problem?
>
>The volume isn't full, and the files aren't read only.
>
>Thanks for any help.
>
I've seen this occur if someone tries to copy too many files into the
root directory of the Scramdisk volume. Scramdisk volumes are like
any other FAT based volume in that there is a strict limitation on how
many files can exist in the root directory (256?). Try cleaning out a
few files from the root of the scramdisk volume, then create a
subdirectory and move the files into that. Subdirectories don't have
that strict filecount limitation.
------------------------------
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: Partial key exposure
Date: Fri, 19 Mar 1999 01:55:51 GMT
In article <7cphbf$kkr$[EMAIL PROTECTED]>,
"Anthony Lineham" <[EMAIL PROTECTED]> wrote:
>I'm curious as to what peoples thoughts are on the following situations.
>
>Suppose a key is broken into blocks of 16 bits. Which of the following to
>cases would you consider to be the least serious in terms of breach of
>security.
>
>1. 6 of the 16 bits (eg bits 0-5) becomes known while the remaining bits
>(6-15) remain unknown.
Is only 6 bits of the entire key revealed, or is 6 bits out of every 16 bit
block revealed? My analysis below assumes only 6 bits total are revealed.
If more bits are revealed, case 1 is much more serious breach of security.
>
>2. The bits are divided into 3 blocks, 2 of 6-bits and 1 of 4-bits, with
>2 zeros appended to make 6-bits. Where the zeros are appended to the third
>block is not important but is known. The 3 6-bit blocks are XORed together
>to give a 6-bit block. The 6-bit result of the XOR becomes known.
The two situations are equivilent. In both cases, the size of keyspace is
reduced by a factor of 2**6, and in both cases, it is trivial to enumerate the
reduced keyspace. In both cases, the expected time to perform a brute force
search after the breach is a factor of 2**6 less than then expected to brute
force the original cipher.
In addition, if either of the cases are significantly easier to attack than
that, then there is a better-than-brute force attack on the original cipher.
This attack is: step through all possible 6 bit codes xxxxxx, and assume
that those bits were revealed. Use your significantly better attack using
the assumed revelation xxxxxx.
>
>
>From rough calculations there are 2 to the power of 10 possible 16-bit
>blocks that can produce the 6-bit XOR result. (I think this is correct?)
Correct.
>
>Both situations result in 10-bits of uncertainty, but would you consider one
>situation more serious than the other, or both the same. I realise that
>this is really an algorithm dependent situation so think of it terms of a
>DES-like algorithm.
Actually, it is algorithm independant, assuming brute force is the best
possible attack on the cipher. If brute force isn't the best attack, then
one or the other may be preferable.
>
>My intuitive preference is situation (2) as it doesn't explicitly reveal any
>of the bits, only the possibilities, while (1) gives away 6 bits with
>absolute certainty. Knowledge of these 6 bits might then be used as
>somekind of stepping stone to a further attack.
As above, if revealing some bits of the key could be used as a stepping stone,
then that fact itself could be used as an attack, even if you didn't know
those bits.
--
poncho
------------------------------
** 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
******************************
