Cryptography-Digest Digest #35, Volume #12 Thu, 15 Jun 00 12:13:01 EDT
Contents:
Re: Digits of pi in Twofish (Mark Wooding)
Re: Digits of pi in Twofish (tomstd)
Re: Finding prime numbers (Bob Silverman)
randomness tests : more specific ([EMAIL PROTECTED])
primality tests ([EMAIL PROTECTED])
Re: New Idea (Runu Knips)
Re: Comments/analysis requested: stream cipher derived from hash function (SHA-1)
(Lon Willett)
Re: New Idea (Runu Knips)
Re: randomness tests : more specific (tomstd)
Re: New Idea (tomstd)
Re: Comments/analysis requested: stream cipher derived from hash function (SHA-1)
(tomstd)
Re: Good ways to test. (John)
Re: salt length? (Jim Gillogly)
Re: New Idea (csybrandy)
Re: New Idea (csybrandy)
Re: RIP Bill 3rd Reading in Parliament TODAY 8th May (MagiconInc)
Re: salt length? (zapzing)
Re: salt length? (tomstd)
Re: salt length? (Mark Wooding)
Re: salt length? (tomstd)
Re: Observer 4/6/2000: "Your privacy ends here" (Mok-Kong Shen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Digits of pi in Twofish
Date: 15 Jun 2000 13:25:08 GMT
Tim Tyler <[EMAIL PROTECTED]> wrote:
> A public demonstration involving a real random number generator,
> designed by a representatives of the potential users is another idea
> that might offer some assurance - though this lacks the eternal nature
> of using the digits of PI ;-)
How do you stand with regard to the MARS designers' idea of using a
published seed value and a generator based on SHA1 to make S-boxes with
particular published characteristics? The only problem I can see
(assuming that they didn't break SHA1 while building their trap door) is
that they might have selected their published seed on the basis of more
restrictive criteria, which include both their published criteria and
some others carefully chosen to introduce appropriate weaknesses. Given
how simple and inefficient the MARS team's algorithm for S-box
generation was, loading on extra criteria seems unlikely.
Changing tack slightly, the RC2 block cipher (like some other Rivest
designs) uses a permutation on bytes which is `derived from the digits
of pi', but I've not found out how this derivation is meant to work.
Does anyone actually have information about *how* these permutations are
derived from the digits of pi?
-- [mdw]
------------------------------
Subject: Re: Digits of pi in Twofish
From: tomstd <[EMAIL PROTECTED]>
Date: Thu, 15 Jun 2000 06:33:31 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Mark Wooding) wrote:
>Tim Tyler <[EMAIL PROTECTED]> wrote:
>
>> A public demonstration involving a real random number
generator,
>> designed by a representatives of the potential users is
another idea
>> that might offer some assurance - though this lacks the
eternal nature
>> of using the digits of PI ;-)
>
>How do you stand with regard to the MARS designers' idea of
using a
>published seed value and a generator based on SHA1 to make S-
boxes with
>particular published characteristics? The only problem I can
see
>(assuming that they didn't break SHA1 while building their trap
door) is
>that they might have selected their published seed on the basis
of more
>restrictive criteria, which include both their published
criteria and
>some others carefully chosen to introduce appropriate
weaknesses. Given
>how simple and inefficient the MARS team's algorithm for S-box
>generation was, loading on extra criteria seems unlikely.
>
>Changing tack slightly, the RC2 block cipher (like some other
Rivest
>designs) uses a permutation on bytes which is `derived from the
digits
>of pi', but I've not found out how this derivation is meant to
work.
>Does anyone actually have information about *how* these
permutations are
>derived from the digits of pi?
Why magic of course.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Finding prime numbers
Date: Thu, 15 Jun 2000 13:34:42 GMT
In article <8i93rb$mq7$[EMAIL PROTECTED]>,
AllanW <[EMAIL PROTECTED]> wrote:
>
<snip>
> I'm not familiar with the names "wheel" and "spoke." But I did
> discover on my own a technique that closely matches what you've
> described, so I'm reasonably sure that it is the same thing.
>
> The point of an 8-spoke wheel, then, is to avoid candidate
> primes (or in your case, candidate factors) which are
> multiples of 2, 3, or 5. You expressed these values as
> 1,7,11,13,17,19,23,29
> but I've been using
> 6,4,2,4,2,4,6,2
> which I'm sure you recognize as the delta values, starting one
> position further down your wheel.
Yes. This is correct.
>
> > But trying to break an RSA key by trial division is worse
> > than hopeless.
>
> If you want to know if a number is prime or composite, finding
> a factor quickly is more important than finding prime factors.
Huh? This makes no sense to me. What are you trying to say?
>
> As I understood it, though, the public key and private key were
> both created from a simple formula with two prime numbers. So
> we don't just want to find a factor, we want to find prime
> factors.
Oh. Now I see the confusion.
The fundamental theorem of arithmetic says that factorization
into primes is UNIQUE. Finding factors (which may not be prime)
is equivalent to finding prime factors since any method which
finds composite factors can be applied recursively to find
prime factors.
Or I suppose you could go by HOW MANY factors you
> find; three or more factors means that we haven't got the
> public/private keypair. Still, a simple declaration that the
> number isn't prime is not complete.
I don't understand what you are trying to say here. An RSA is
usually the product of two primes. Once you find one factor, you
are done.
What do you really mean?
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: randomness tests : more specific
Date: Thu, 15 Jun 2000 14:03:00 GMT
>
> Diehard and ent are completely useless. Why? Because the only
> usefull test is specific to *what* you want to use the prng for.
>
> If you want to pick five cards randomly for poker, then test to
> make sure your prng has a good random dsitribution of cards. If
> you want to pick 0/1 answers make sure it's not serially
> correlated or biased...
>
> But performing DNA/OPSQ/Sphere/Etc.. tests are meaningless if
> you can't interpret their results in a manner related to your
> use of the prng.
>
> Tom
>
that's just the point i was thinking ...
so let me tell the situation more precisely :
say that i have a entropy collector function, getting entropy from the
system and forming a pool.
And i want to generate 1024 bit - 2048 bit random data to generate my
keys ...
i do check the entropy of it, but what are the other possible tests
which i must perform to test the output (from hash function or from a
PRNG)?
thanks ....
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: primality tests
Date: Thu, 15 Jun 2000 14:01:43 GMT
hello all,
when i implement probabilistic primality tests,
i know that
with Millrob for one base error possibility 0.25
(and with n bases (0.25)^n )
with Lehman 0.5
with Lucas 5/16
with Frobenius 1/7710
say that i implement 20 bases with MillRob i get (0.25)^20
but how much this error probability decrease by checking 8691 primes
before this test? (is there a formula?)
(i firstly Test for easy division of primes upto 8691)
thanks for any help ....
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Thu, 15 Jun 2000 16:18:49 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: New Idea
tomstd wrote:
> Well if you use rotations like Csybrandy then
> let me be the first to break your cipher :)
Hehe. ;-)
No, even my buggy Whirl128 didn't worked that
way, did it ? :-)
------------------------------
From: Lon Willett <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Comments/analysis requested: stream cipher derived from hash function
(SHA-1)
Date: Thu, 15 Jun 2000 14:24:56 GMT
In article <[EMAIL PROTECTED]>,
tomstd <[EMAIL PROTECTED]> wrote:
> A better simpler idea is to maintain the same S1/S2 buffers and
> perform this
>
> S1' = H(S1 || S2)
> S2' = H(S2 || S1)
>
> Output S1' and replace (S1, S2) with (S1', S2')
I'm not sure why this is better. It looks about the same to me.
> An even better idea is to maintain a counter.
I agree (see other posts in this thread).
> Pick a random 512-bit string r, and a 128-bit counter k.
>
> O = H(k || r)
> k = k + 1
>
> Where O is the next output.
But this is susceptible to backtracking attacks (if an attacker steals
the state after I've generated 10 values, he can reconstruct those 10
values).
> Tom
/Lon
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Thu, 15 Jun 2000 16:26:15 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: New Idea
tomstd wrote:
> Even if a1..a4 were totally random things like
>
> B += (A <<< a1) xor (A >>> a2)
>
> Is a very bad idea. For example with a prob of 1/32 you have a
> weak transform (zero output) and a myrad of other problems.
>
> My idea for RC5 was to use four 8x5 sboxes and use those to calc
> the rotate.
Hmm you meant TC5, don't you ?
> However, differntial attacks on the sboxes are all
> that is stopping cryptanalysis of the entire cipher then.
> Something like
>
> B += ((((A <<< a1) + K1) <<< a2) + K2) <<< a3) + K3) <<< a4
>
> If you could make a1..a4 randomly distributed over 0..31
> (basically 20 bits) that are dependent on the plaintext that
> should be ok.
>
> However, there is a 2^-15 chance of this being totally linear
> (all rotates the same). In a block cipher it would really
> depend on how you get those 20 bits.
I found it really helpful to paint a diagram showing the
operations of my cipher to detect where the problems are.
For example, when you study IDEA that way, one can see
clearly that XOR is never followed by another XOR etc.
------------------------------
Subject: Re: randomness tests : more specific
From: tomstd <[EMAIL PROTECTED]>
Date: Thu, 15 Jun 2000 07:29:33 -0700
In article <8ianm7$r1t$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
wrote:
>
>>
>> Diehard and ent are completely useless. Why? Because the
only
>> usefull test is specific to *what* you want to use the prng
for.
>>
>> If you want to pick five cards randomly for poker, then test
to
>> make sure your prng has a good random dsitribution of cards.
If
>> you want to pick 0/1 answers make sure it's not serially
>> correlated or biased...
>>
>> But performing DNA/OPSQ/Sphere/Etc.. tests are meaningless if
>> you can't interpret their results in a manner related to your
>> use of the prng.
>>
>> Tom
>>
>
>that's just the point i was thinking ...
>
>so let me tell the situation more precisely :
>
>say that i have a entropy collector function, getting entropy
from the
>system and forming a pool.
>
>And i want to generate 1024 bit - 2048 bit random data to
generate my
>keys ...
>
>i do check the entropy of it, but what are the other possible
tests
>which i must perform to test the output (from hash function or
from a
>PRNG)?
>
>thanks ....
>
Using random bits for a symmetric key you would most likely want
to check that the bits are not serially correlated and that at
the least each octet is equal probable.
If you are using a prng device you want to have the nice balance
between being correlated and non-linear. Shrinking LFSRs are a
good example.
You can use a hash as well, but you have to construct it
properly to avoid all sorts of PRNG attacks (backtracking, low
entropy, ...)
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: New Idea
From: tomstd <[EMAIL PROTECTED]>
Date: Thu, 15 Jun 2000 07:33:59 -0700
In article <[EMAIL PROTECTED]>, Runu Knips
<[EMAIL PROTECTED]> wrote:
>tomstd wrote:
>> Even if a1..a4 were totally random things like
>>
>> B += (A <<< a1) xor (A >>> a2)
>>
>> Is a very bad idea. For example with a prob of 1/32 you have
a
>> weak transform (zero output) and a myrad of other problems.
>>
>> My idea for RC5 was to use four 8x5 sboxes and use those to
calc
>> the rotate.
>
>Hmm you meant TC5, don't you ?
Nope, TC5 is a recursive Feistel. Earlier this year I designed
RC5a which used these sboxes... I can find it again if you want
to see it.
>> However, differntial attacks on the sboxes are all
>> that is stopping cryptanalysis of the entire cipher then.
>> Something like
>>
>> B += ((((A <<< a1) + K1) <<< a2) + K2) <<< a3) + K3) <<< a4
>>
>> If you could make a1..a4 randomly distributed over 0..31
>> (basically 20 bits) that are dependent on the plaintext that
>> should be ok.
>>
>> However, there is a 2^-15 chance of this being totally linear
>> (all rotates the same). In a block cipher it would really
>> depend on how you get those 20 bits.
>
>I found it really helpful to paint a diagram showing the
>operations of my cipher to detect where the problems are.
>For example, when you study IDEA that way, one can see
>clearly that XOR is never followed by another XOR etc.
>
Yeah, it's a good idea todo that. Just mixing different dyadic
operators to break isomorphisms is not a good idea. For example
addition and xor are very close to the same operation (consider
the lsb). Xor and Multiplication in Z(2^w) is a example of
something that really doesn't mix well.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: Comments/analysis requested: stream cipher derived from hash function
(SHA-1)
From: tomstd <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Date: Thu, 15 Jun 2000 07:35:08 -0700
In article <8iaov1$s2d$[EMAIL PROTECTED]>, Lon Willett
<[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> tomstd <[EMAIL PROTECTED]> wrote:
>> A better simpler idea is to maintain the same S1/S2 buffers
and
>> perform this
>>
>> S1' = H(S1 || S2)
>> S2' = H(S2 || S1)
>>
>> Output S1' and replace (S1, S2) with (S1', S2')
>
>I'm not sure why this is better. It looks about the same to me.
Notice I never use S2 in any output....
>> An even better idea is to maintain a counter.
>
>I agree (see other posts in this thread).
>
>> Pick a random 512-bit string r, and a 128-bit counter k.
>>
>> O = H(k || r)
>> k = k + 1
>>
>> Where O is the next output.
>
>But this is susceptible to backtracking attacks (if an attacker
steals
>the state after I've generated 10 values, he can reconstruct
those 10
>values).
True... I should have noted that.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: Good ways to test.
From: John <[EMAIL PROTECTED]>
Date: Thu, 15 Jun 2000 07:35:58 -0700
Yes, that seems to make sense. I have tested two encryption
schems. One passed the chi-squre test, the other didn't. The
one that didn't pass had some runs of 5 characters in the data.
That is, you might get xxxxx as encrypted data. Now, the one
that you think would be good on the tests had a run of 6
characters in the data... xxxxxx. The run is important since I
used all null characters to test the encryption and many
different passwords. The interesting thing in both cases is
that the runs were "random." There was an average of 20-25
characters that "ran" in a test of one-hundred billion
characters. 256^5 is a lot higher than 100 billion, but I can't
get much info from the characters that run.
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: salt length?
Date: Thu, 15 Jun 2000 14:57:15 +0000
Elros wrote:
>
> For use with a stream cipher (e.g. RC4), what's a good length for a salt (S)
> that gets concatenated (&) to the user supplied key (U) before S & U gets
> fed into the cipher?
I wouldn't want to give a general rule for all stream ciphers, but for RC4
I'm happy with 128 bits, and I'd keep it general enough to bounce up to
256, to guard against whatever the big AES numbers guard against.
CipherSaber uses 80 bits, which is long enough for most practical purposes,
though perhaps not for an extremely high-volume correspondence with no key
changes. See http://ciphersaber.gurus.com . Don't make it so long that
the user key doesn't have room to get thoroughly mixed.
While Tom StD's suggestion of hashing them together is fine, I consider
the RC4 initialization a hashing process itself: at least <I> don't know
how to extract information from it if the sum of salt and key length isn't
close to the full 256 bytes. Doing it this way has the advantage of keeping
the total mechanism small -- RC4 has less code and debugging needed than
RC4 + SHA-1.
--
Jim Gillogly
26 Forelithe S.R. 2000, 14:46
12.19.7.5.6, 6 Cimi 9 Zotz, Seventh Lord of Night
------------------------------
From: csybrandy <[EMAIL PROTECTED]>
Subject: Re: New Idea
Date: Thu, 15 Jun 2000 10:43:27 -0400
wrote:
> csybrandy wrote:
> > What gave me this idea was when he stated that data dependent rotates
> > (so far) never use all of the bits in a word.
>
> Damned, you're starting to discover things I'm using in my new version
> of Whirl :) I've to release it soon, I guess ;-)
Don't worry. I don't plan on putting this one in the contest :-) Feel
free to use it if you like.
------------------------------
From: csybrandy <[EMAIL PROTECTED]>
Subject: Re: New Idea
Date: Thu, 15 Jun 2000 10:43:35 -0400
wrote:
> csybrandy wrote:
> > What gave me this idea was when he stated that data dependent rotates
> > (so far) never use all of the bits in a word.
>
> Damned, you're starting to discover things I'm using in my new version
> of Whirl :) I've to release it soon, I guess ;-)
Don't worry. I don't plan on putting this one in the contest :-) Feel
free to use it if you like.
------------------------------
From: [EMAIL PROTECTED] (MagiconInc)
Subject: Re: RIP Bill 3rd Reading in Parliament TODAY 8th May
Date: 15 Jun 2000 15:15:38 GMT
What if the key is material which it is illegal to disclose under the Official
Secrets Act? Is one obliged to disclose it, or not?
Paul Magnussen
Magicon Inc.
Making software simpler
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: salt length?
Date: Thu, 15 Jun 2000 15:09:17 GMT
In article <8iak3p$4ejql$[EMAIL PROTECTED]>,
"Elros" <[EMAIL PROTECTED]> wrote:
> For use with a stream cipher (e.g. RC4), what's a good length for a
salt (S)
> that gets concatenated (&) to the user supplied key (U) before S & U
gets
> fed into the cipher?
I would suggest that the salt be as long as the key.
You should not catenate, you should xor instead. The
user supplied key should therefore be as long as
the steam cipher key also.
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: salt length?
From: tomstd <[EMAIL PROTECTED]>
Date: Thu, 15 Jun 2000 08:20:52 -0700
In article <[EMAIL PROTECTED]>, Jim Gillogly
<[EMAIL PROTECTED]> wrote:
>Elros wrote:
>>
>> For use with a stream cipher (e.g. RC4), what's a good length
for a salt (S)
>> that gets concatenated (&) to the user supplied key (U)
before S & U gets
>> fed into the cipher?
>
>I wouldn't want to give a general rule for all stream ciphers,
but for RC4
>I'm happy with 128 bits, and I'd keep it general enough to
bounce up to
>256, to guard against whatever the big AES numbers guard
against.
>CipherSaber uses 80 bits, which is long enough for most
practical purposes,
>though perhaps not for an extremely high-volume correspondence
with no key
>changes. See http://ciphersaber.gurus.com . Don't make it so
long that
>the user key doesn't have room to get thoroughly mixed.
>
>While Tom StD's suggestion of hashing them together is fine, I
consider
>the RC4 initialization a hashing process itself: at least <I>
don't know
>how to extract information from it if the sum of salt and key
length isn't
>close to the full 256 bytes. Doing it this way has the
advantage of keeping
>the total mechanism small -- RC4 has less code and debugging
needed than
>RC4 + SHA-1.
Your symmetric key should be at least 80 bits, but I would use
128 bits just to be conservative. Also, your salt should be
unique. If you plan on sending alot of messages per second use
a 64-bit random number, if you are sending a single message a
day, the time of day will do. (i.e time(NULL)).
Also by hashing the key+salt you make the RC4 key a bit better.
If you consider a 16 byte key + 4 byte salt, the first 16 swaps
in the RC4 key schedule are always the same. Also if the
initial state is recovered somehow so is your key.
By hashing it the first 16 swaps are not always the same and
recovering the key is not detremental.
Also if you blindly feed ASCII passwords (which is the case for
symmetric tools) hashing is a much better idea. If you consider
a 12 char password and a 4 byte salt, then 192 of the 256 swaps
are not fully "random" since they are derived from ascii
values. Even though there can be at most about 96 bits of
entropy in the 12 char password, by hashing it you don't only
have values 32..127 for swaping. It's a small price to pay for
better security.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: salt length?
Date: 15 Jun 2000 15:23:55 GMT
tomstd <[EMAIL PROTECTED]> wrote:
> In article <8iak3p$4ejql$[EMAIL PROTECTED]>, "Elros"
> <[EMAIL PROTECTED]> wrote:
>
> >For use with a stream cipher (e.g. RC4), what's a good length for a
> >salt (S) that gets concatenated (&) to the user supplied key (U)
> >before S & U gets fed into the cipher?
>
> That's a stupid idea.
No, it's not. For someone who's still a self-confessed beginner, you're
very quick to label others' ideas as stupid. And while the excessive
`humility' of some other regular posters has begun to grate, a certain
degree of politeness and caution wouldn't go amiss.
And if you are going to abuse other posters, at least take a leaf from
Bob Silverman's book and be both (usually) correct and witty with it.
> You should feed the RC4 key schedule the hash of the password and
> salt.
Why? RC4's key schedule can cope with a reasonably-sized password and a
salt just fine. While it's true that RC4 does leak a little bit of key
information, this is easily fixed by spinning the RC4 generator around
for a bit, e.g., by generating and discarding 1024 bytes of output, and
this is recommended practice for using RC4 anyway.
If memory serves, it's the later bytes of key which are more likely to
be leaked in the early output bytes. By submitting the user password
and the salt, in that order, to the key schedule, we make it likely that
the information leaked is the salt, which is sent in the clear anyway.
If you just use the hash, and you do leak key bytes then you reduce the
(fixed) search space of the hash output. For example, if you use a
20-byte (160-bit) hash, like RIPEMD-160, and leak 8 bytes, you're left
with a space of `only' 2^{96} bits to search.
The `right' solution would seem to be to use a pseudo-random function,
keyed from the supplied password and salt, to fill RC4's 256-byte key
space. But we have a pseudo-random function: RC4! (Well, it's at least
as good as RC4 is, anyway.) So why don't we just use that? ;-)
> The salt should be long enough so that's it's never used twice (with
> high probability). If you are sending a message a day then just use
> the time_of_day in seconds.
No. It also needs to be long enough to dissuade precomputed dictionary
attacks. There are 86400 seconds in a 24-hour period; while this is
larger than the Unix password salt space, I'm not sure it's large enough
for now. I'd recommend choosing a 64-bit random string.
-- [mdw]
------------------------------
Subject: Re: salt length?
From: tomstd <[EMAIL PROTECTED]>
Date: Thu, 15 Jun 2000 08:24:09 -0700
In article <8iarid$u33$[EMAIL PROTECTED]>, zapzing <zapzing@my-
deja.com> wrote:
>In article <8iak3p$4ejql$[EMAIL PROTECTED]>,
> "Elros" <[EMAIL PROTECTED]> wrote:
>> For use with a stream cipher (e.g. RC4), what's a good length
for a
>salt (S)
>> that gets concatenated (&) to the user supplied key (U)
before S & U
>gets
>> fed into the cipher?
>
>I would suggest that the salt be as long as the key.
>You should not catenate, you should xor instead. The
>user supplied key should therefore be as long as
>the steam cipher key also.
This will overcome the case of ascii derived swapping in RC4 but
it will not overcome the fact that if I find the key for one
message I have the key for all messages. Again I recommend a
hash for this purpose.
And if the user supplied key (password) is randomly distributed
among the values 32..127, 12 chars will give you a 96 bit key
and 15 chars will give you a 99 bit key. If you can remember 15
char passwords that are fairly random then you are set.
Of course passwords like "th^1N<*(A~hj$.l" are easy to
remember... hehehe..
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,alt.politics.uk,alt.security.scramdisk,uk.telecom
Subject: Re: Observer 4/6/2000: "Your privacy ends here"
Date: Thu, 15 Jun 2000 10:47:30 +0200
Paul Shirley wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> writes
> >The scheme is for use with arbitrary texts from books, e.g. religious
> >ones, and newspapers and such stuffs and doesn't carry any secret
> >messages. Its purpose is only to waste and hopefully exhaust the
> >resources of the interceptors. I originally had that idea in a thread
> >of sci.crypt discussing better ways (than incorporating sentitive
> >words into e-mails) of jamming Echelon and similar machineries.
>
> Then you've missed the point of monkey wrenching RIP. It does not matter
> what the message is, only that its been encrypted. If it has been
> encrypted the options for 'wasting time' are severely limited. Either
> you hand the key over or go to prison.
You didn't read a previous post of mine which had a bit detail saying
that the key, a seed of a PRNG, is sent as a prefix to the ciphertext.
So handing over the key is trivial and I remain outside of the prison :)
M. K. Shen
------------------------------
** 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
******************************
