Cryptography-Digest Digest #844, Volume #12 Thu, 5 Oct 00 00:13:01 EDT
Contents:
Re: GNFS and the Cipher Challenge (Jim Gillogly)
Re: Requirements of AES ("Paulo S. L. M. Barreto")
Re: It's Rijndael ("Paulo S. L. M. Barreto")
Re: It's Rijndael ("Paulo S. L. M. Barreto")
Re: Requirements of AES ("Paulo S. L. M. Barreto")
Re: Question on biases in random numbers & decompression (Benjamin Goldberg)
TC8 -- Yet Another Block Cipher (Tom St Denis)
Re: Choice of public exponent in RSA signatures ("Joseph Ashwood")
Re: Choice of public exponent in RSA signatures (Benjamin Goldberg)
Re: OPEN LETTER ABOUT Rijndael to sci.crypt (SCOTT19U.ZIP_GUY)
Re: Encryption problem ("Joseph Ashwood")
Re: Choice of public exponent in RSA signatures ("Joseph Ashwood")
Re: The best way to pronounce AES [was OT now even further, now almost humor?]
("Joseph Ashwood")
Re: is NIST just nuts? (Benjamin Goldberg)
Re: Signature size (David Hopwood)
Re: The best way to pronounce AES (Dido Sevilla)
Re: Encryption problem (David Hopwood)
Re: Question on biases in random numbers & decompression (Benjamin Goldberg)
Re: Newbie question to practical brute-force analysis ("r.e.s.")
----------------------------------------------------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Crossposted-To: rec.puzzles
Subject: Re: GNFS and the Cipher Challenge
Date: Thu, 05 Oct 2000 02:20:57 +0000
Paul Rubin wrote:
> You've got to be kidding :). I don't begin to understand GNFS. I'm
> just boggled to hear that Singh's challenge calls for it. I guess I'm
> not supposed to ask for details just yet. But given how stage 9
> already needed Deep Crack, if you're going to need GNFS next, you're
> probably looking at a big parallel implementation and a lot of iron to
> run it on. Wow!
In fact, Stage 9 didn't really <need> Deep Crack -- only one of the
at least four teams that have solved it used Deep Crack. Seems like
Stage 10 might not need GNFS either if it's been weakened in some
way, but I haven't found a shortcut yet, so doing GNFS while we keep
looking for a shortcut maximizes our chance of getting there first.
--
Jim Gillogly
Highday, 14 Winterfilth S.R. 2000, 02:17
12.19.7.10.18, 1 Edznab 1 Yax, Second Lord of Night
------------------------------
Date: Wed, 04 Oct 2000 22:34:34 -0200
From: "Paulo S. L. M. Barreto" <[EMAIL PROTECTED]>
Subject: Re: Requirements of AES
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Tom St Denis wrote:
<blockquote TYPE=CITE>In article <[EMAIL PROTECTED]>,
<br> [EMAIL PROTECTED] wrote:
<br>> Tom St Denis <[EMAIL PROTECTED]> wrote:</blockquote>
[snip]
<blockquote TYPE=CITE>
<br>> There /was/ a 10-round attack suggested in the original Twofish paper.
<br>> Apparently it fails to work.
<p>Maybe I am just a troll, but doesn't that mean people *tried* to break
<br>Twofish?</blockquote>
Actually that means people -- even the fishing team -- can far too easily
draw wrong conclusions about the security of Twofish. It's too complex
for its security to be properly assessed in so short a period of time.
<p>Paulo "htp di nswt Inpw" Barreto.
<br> </html>
------------------------------
Date: Wed, 04 Oct 2000 22:46:04 -0200
From: "Paulo S. L. M. Barreto" <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Mok-Kong Shen wrote:
<blockquote TYPE=CITE>Runu Knips wrote:
<br>>
<p>> Tripple-Something is always very inefficient, and only
<br>> an option if key size is too short, which isn't the
<br>> case for Rijndael.
<p>Dumb question: Would tripling with hardware also lead
<br>to essential inefficiency? There could be a pipelining
<br>effect, isn't it?
<p>M. K. Shen</blockquote>
Before resorting to triple encryption, you must prove the cipher is not
a group (otherwise triple encryption is plain waste of time). I doubt
this has been done for any of the AES candidates (I mean any of the 15
original ciphers, not only the finalists); if you know better, please share
the proof (or a link to it).
<p>Cheers,
<p>Paulo.
<br> </html>
------------------------------
Date: Wed, 04 Oct 2000 22:21:04 -0200
From: "Paulo S. L. M. Barreto" <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
lcs Mixmaster Remailer wrote:
<blockquote TYPE=CITE>For those whose primary interest in AES is high security,
the emphasis
<br>might have been placed elsewhere.</blockquote>
For those whose primary interest in AES is high security, using Twofish
is more inadequate than you might think. Given this cipher's complexity,
there has been absolutely insufficient public analysis. The difficulty
in assessing the security level of Twofish is atested by the several "retreats"
made by the fishing team. It's hard to believe that someone would
consider this "high security" -- it's more likely "good marketing".
<p>BTW, aren't the "retreats" a counterexample to the claim that "attacks
can get worse, never better"? :-)
<p>Cheers,
<p>Paulo Barreto.
<br> </html>
------------------------------
Date: Wed, 04 Oct 2000 22:42:38 -0200
From: "Paulo S. L. M. Barreto" <[EMAIL PROTECTED]>
Subject: Re: Requirements of AES
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Volker Hetzer wrote:
<blockquote TYPE=CITE>Tom St Denis wrote:
<p>> Why wasn't Serpent or Twofish picked?
<br>My 2 cents:
<br>Remember, they wanted an algo for non classified data.
<br>That means, they didn't *have* to choose some ultra safe
<br>and technologically over-ripe candidate.
<br>Perhaps one of the reasons was that Rijndael is new and
<br>nice to analyze so one can learn more about cipher design?
<br>And if it gets broken, hey, you were not supposed to encrypt
<br>secret stuff with it anyway!
<p>Greetings!
<br>Volker</blockquote>
Peter Gutmann et al. pointed out recently in some mailing lists that NSA's
algorithms for protecting classified data actually relies on a combination
of techniques rather than a pure symmetric cipher. For instance,
it seems at least two of them -- BATON and JUNIPER -- accept signed keys
only; this implies they are only used in NSA-approved hardware, which verifies
the key signature and rejects non-authorized ones.
<p>It was said that NSA likes other kind of "hardware protection" also,
including self-destructing devices; this may sound funny, but it's difficult
to decide its verossimilitude.
<p>As you see, you might easily convert any AES finalist -- or even most
of the original candidates -- in an algorithm suitable to encrypt "classified
data" by merely attaching a bomb to them.
<p>Paulo.
<br> </html>
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: com.compression
Subject: Re: Question on biases in random numbers & decompression
Date: Thu, 05 Oct 2000 02:15:20 GMT
David Schwartz wrote:
>
> Benjamin Goldberg wrote:
>
> > Hmm:
> > Method a: use 2 bits at a time, discard 25% of bitstream.
> > 3 trits uses 3*2 bits minimum, 4*2 bits on average.
> > Method b: use 4 bits at a time, discard 6.25% of bitstream.
> > 3 trits uses 3*4 bits minimum, more on average (but I'm not going to
> > bother to calculate how much more).
> >
> > Since I want to discard as little of the stream as possible, why the
> > HELL would I want to use method b?
>
> Because it discards very little of the bitstream, only 6.25%
But method b uses more bits minimum per trit than method a uses on
average. The redundancy of 5 bitstrings that mapping to each trit
outweighs the fact that less is discarded outright. If you view
redundancy as throwing away of bits, then method b throws away more.
--
... perfection has been reached not when there is nothing left to
add, but when there is nothing left to take away. (from RFC 1925)
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: TC8 -- Yet Another Block Cipher
Date: Thu, 05 Oct 2000 02:42:42 GMT
This cipher is designed after CS-Cipher but is much simpler and uses
little ram/rom. It's a cute cipher and I would appreciate any comments.
This cipher has awesome diffusion amongst the bytes (64-bit block
cipher) and is very simple to look at.
I noticed very little comments on MyFish... oh well...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Choice of public exponent in RSA signatures
Date: Wed, 4 Oct 2000 15:19:26 -0700
> Which is fine, but that is not the same as saying that
> n-prime is necessarily *weaker*.
We agree on that point, my entire stand is that n-prime cannot be stronger
than 2-prime. According to another thread, the gain will be approximately
9/4 for private key operations (assuming 3-prime vs 2-prime), since public
key operations remain the same speed, the average is that 3-prime will be
62% faster than 2-prime. We can amplify the situation a bit, would you buy a
car that got 62% better gas mileage, but had a 50% chance of exploding
within 3 years? I personally would not only not buy that car, I would go out
of my way to avoid being around them. This situation is very much the same,
we are creating a construct that works 62% faster, but if you follow the
advances in factoring we will within 3 years likely see another advance, and
there's a ~50% chance that it will be faster with smaller factors. I
wouldn't accept the risk in the car I drive, why would I accept it with my
data?
Joe
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Choice of public exponent in RSA signatures
Date: Thu, 05 Oct 2000 02:53:24 GMT
David Wagner wrote:
>
> Yes, I am familiar with those attacks. As I said, with proper use of
> random padding (e.g., OAEP), the attacks do not apply. Thus, I do not
> see why they should provide a justification to prefer e>3.
>
> And, in real life, everyone uses random padding, and the random
> padding is large enough to avoid Coppersmith's attack. Hastad's and
> Coppersmith's attack are of great theoretical interest, but they do
> not apply to any real-world implementation that I know of.
Doesn't the security of using OAEP depend on the security of the hash
function, H, and the generator, G? The paper on OAEP which I read
simply used a random oracle model for H and G... practical
implementations need to use real functions, like SHA1 for the hash, and
RC4 or SEAL or <pick-your-favorite-cipher>-OFB for the generator. How
much does this affect security?
--
... perfection has been reached not when there is nothing left to
add, but when there is nothing left to take away. (from RFC 1925)
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: OPEN LETTER ABOUT Rijndael to sci.crypt
Date: 5 Oct 2000 02:52:58 GMT
[EMAIL PROTECTED] (John Savard) wrote in
<[EMAIL PROTECTED]>:
>On Wed, 04 Oct 2000 22:15:21 GMT, [EMAIL PROTECTED] (Michael
>Elkins) wrote, in part:
>
>>How do you propose that the impelemtations of a crypto algorithm be
>>tested if there are no test vectors to work with? In general,
>>algorithms which rely on the nondisclosure of the logic are a bad idea.
>
>True, but that is *one* charge that cannot be levelled against David
>Scott. His source code is available.
>
>He is not talking about a secret algorithm. Simply a chaining mode
>that turns the whole document, effectively, into a single block.
>
>Doing CBC mode twice, once forwards and once backwards, would do that,
>as an example, although Mr. Scott's mode is different from that.
>
>
Actually doing CBC twice once back and once forward does not
come close to doing what I think needs to be done. The claissic
proof that what you say is wrong is this. Take any big file encrypt
it with CBC in forward direction. do the same with a different key in
the reverse direction. Change a single byte in center of file. Cut off
both ends of file a few blocks in length. Know decypt using the same
passwords in the opposite order that you applied them a few blocks
at front are not recoverd and at back and around where the change
occurred.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Encryption problem
Date: Wed, 4 Oct 2000 15:38:26 -0700
1) Pick a trusted entity, this person MUST be trusted absolutely and if
compromised will destroy the entire game
2) Have the trusted entity kep the price hidden (sicne this value is hidden
the entity may offer a future compromise
Alternate crypto way:
1) pick a permanently trusted entity E
2) E gathers a random number from each individual Ri
3) E chooses a random price P, and a random value RE
4) E generates Hi = SHA1(Ri, RE, P) for each Ri
5) E publishes all Hi for all to see
6) E encrypts RE with 3DES using a random key K and publishes the
ciphertext C
7) E accepts guesses and informs the guesser of correctness
8) when a person has guessed correctly, E publishes the key K that changes C
to RE
9) all competitors have the option of checking that SHA1(Ri, RE, P') ==
SHA1(Ri, RE, P)
10) If there is a conflict of values, you KNOW either E was compromised or
competitor i was compromised (in their verification)
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Choice of public exponent in RSA signatures
Date: Wed, 4 Oct 2000 15:51:17 -0700
I have reached a conclusion. We are both using the same information, and
combining them with our own biases, my bias is a slightly better gaurentee
of security, your bias is towards better speed. There is no resolution to
this, at least not until somone proves they have the ultimate factoring
algorithm (aka not any time soon), so how about we simply stop this
conversation before we go another round of us both saying the same thing as
the other.
Joe
"John Myre" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Joseph Ashwood wrote:
> <snip>
> > factoring algorithms come in three
> > general types, those that factor is the same time regardless of factor
> > sizes, those that factor faster numbers with smaller factors faster, and
> > those that exploit some artifact of the prime choosing methods. Only the
> > first two matter for this decision (the third is in the generation which
is
> > seperate).
>
> Ok.
>
> > The 2-prime version clearly has an advantage against n-prime RSA
> > simply from the fact that the primes cannot be larger than the primes
for
> > 2-prime when the factoring algorithm works faster with smaller factors.
>
> It has the advantage when considering just the algorithm(s) that
> get faster with smaller factors.
>
> > When
> > the algorithm takes the same time regardless of factor size, the 2
proposals
> > are equal.
>
> Right. And if that is the fastest algorithm in all cases
> of interest, then of course the proposals have equal security.
>
> > I have no proof that it must remain this way, but I have seen
> > evidence only that numbers with 2 factors must be at least as hard to
factor
> > as n-prime, therefore lacking evidence to the contrary I will retain my
> > stand that 2-prime RSA is at least as strong as n-prime RSA.
> <snip>
>
> Which is fine, but that is not the same as saying that
> n-prime is necessarily *weaker*. The contention has been
> that, in the range of moduli that might be considered
> secure (say, 1024 bits), that (for example) 3 primes are
> just as secure. Since 3 primes can be faster, it has the
> advantage.
>
> The factoring method that gets faster as the factors get
> smaller is slower than the method which ignores factor
> size when there are two factors; and the slower method
> *does not catch up* with only three factors. So it is
> still slower, and so factoring is still just as hard, and
> so RSA is still exactly as secure as before with three
> factors instead of two. At some point, too many primes is
> bad. But two primes is not the optimum.
>
> JM
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: The best way to pronounce AES [was OT now even further, now almost humor?]
Date: Wed, 4 Oct 2000 15:58:39 -0700
> > Side question: As far as I know, the 'standard' British
> > English is the Oxford English. Which is the corresponding
> > one for American English? Thanks.
>
> Bamma, I reckon.
Come on now, you and I both know that Alabama ain't got nothin'. It's us
over here on the West Coast, we've got the money, we get to choose the
English. Considering the choice of musical entertainment, I'd have to say
that Rap, and phrases like "Yo what up n***a" are the real american
english. Of course if you go 400 miles south of here you end up with
Spanglish, which is even worse. Now since I'm white (as opposed to some
shade of green) I'm not permitted to actually speak those languages if I
value such things as keeping my blood inside my body. In all honesty I don't
think America is evolved enough yet to have an American English per se.
Joe
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: is NIST just nuts?
Date: Thu, 05 Oct 2000 03:41:08 GMT
John Savard wrote:
[snip]
> To give DES a 128-bit key would have doubled the time for key setup:
> but to make DES still work with a 128-bit key (given cryptanalytic
> results that allow an attack in 2^65 time against DES with independent
> subkeys reported in AC, so this is, of course, hindsight) I've
> suggested one way of modifying DES that (and it also takes into
> account David Wagner's boomerang attack, again hindsight) should allow
> it:
>
> Simply move the initial permutation and the inverse initial
> permutation to where they can do some good: after rounds 4 and 12.
> That is: four rounds, IP, eight rounds, IIP, four rounds.
The reason that the IP and reverse IP were put into DES was ONLY because
a hardware implementation with them was simpler, and no less secure,
than the version without them. Keeping the idea of how it's wired in
mind, is moving the IP and IIP arbitrarily really a good idea? Or would
some other kind of permutation (or whatever) have a better (or equally
good) effect on security, than IP and IIP, possibly without the hardware
complications that using them might have if they were put in someplace
other than the very first and very last steps?
--
... perfection has been reached not when there is nothing left to
add, but when there is nothing left to take away. (from RFC 1925)
------------------------------
Date: Thu, 05 Oct 2000 02:19:21 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Signature size
=====BEGIN PGP SIGNED MESSAGE=====
Joseph Ashwood wrote:
> What is your exact requirement? Would is be acceptable, for
> example, to perform a 32-bit CRC of the data, encrypt the
> result with a secret shared Blowfish key, and send that? the
> result would be a 64-bit message where as long as the
> Blowfish key remains secret will be strong (altering the
> encrypted block will void the CRC with high probability).
In that case a signature on M will also be a signature on M plus any
multiple of the CRC polynomial. Given one signature, a attacker could
forge a signature on any message, in which all but 32 bits are chosen
by the attacker.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOduraDkCAxeYt5gVAQHEWgf/VKHcjO38RQ0M2gKucQXJg5l6i6O1MQTT
vsVDT3+ozUjHZW4f7NodNWwOqLSXzn97jS9HnoZHdLe+kLx0vvIrFimziAB5xjzb
I5Pu65OnN4ttrQOyWjjVoUBrRW6j7lSe9+cd8XmVXIwoCyhhLDDhj5PrCR4lc0oh
DQfmDd4vAw+rjD9foKltNZkhM6tYWRfUyL06QPntRJe+ZpdtBz9WTVY0bOmjeoLO
mO0FFhNL3nTH48/+tZR9qszOK0JZnIKXS9hHcMRKLgG1vNTt/xp1VoOUDVAfOz5C
AqCvHwnrgcwyKBtv1FZROvVjxhR2PplLEwXggjL6QdXgLITbWjo4+A==
=TZEc
=====END PGP SIGNATURE=====
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: The best way to pronounce AES
Date: Thu, 05 Oct 2000 11:46:36 +0800
Scott Craver wrote:
>
> I know I have no authority to decide these things, but I
> strongly feel that "AES" should be pronounced, "uh-YES."
>
> Like Mr. Dingle or whoever it was from the train station in
> the old Jack Benny radio show. "auhYEEEEEEEEEEEEEEEEEEEEEESSSS????"
>
Maybe you should just call it by its True Name: "Rain Doll"...
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
Date: Thu, 05 Oct 2000 02:20:24 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Encryption problem
=====BEGIN PGP SIGNED MESSAGE=====
ed dominguez wrote:
> We were toying with the idea of creating a small "price is
> right" game at work. We have a hefty prize and we were deciding
> how to give it away and we thought about giving the price to
> that one that found out what the price is.
>
> Problem is, some always knows the price. So we decided
> to make this price random, although realistic.
Suppose the price is to be uniformly distributed between M and M+N-1.
Each participant chooses a uniform random number between 0 and N-1,
as well as their guess of the price. They write both of these in
different colours on a piece of paper, and fold it up. All the papers
are collected (if any are spoiled, repeat the protocol). The price is
the sum of the random numbers modulo N, plus M.
If there are at least two people not acting together whose "random
numbers" were actually chosen uniformly at random, then the price will
be unpredictable by all participants.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOdvVLDkCAxeYt5gVAQFh2AgAttO0FeEp4NQ1cLRzSJZu3bRhFrPrXa+w
iKmgYn1F6e/E/9r2v5w7Nz1M+heRIjaSeinnrfIHuGDB/1/vbpB2EXL31YwxTOxI
hsSoHqJcSjmA6mXC0446j66HAOj6p0Pt9h75EYkuBUtTY2WTlbUBPaj0c2Ncze+g
klBCoFaGM7oLphemWgI3BLODvFzN3VbWSsByiiaTyY4v6pFhJGD+ylOBvim+TmyQ
cI+5RcRAq09TSjiFmwqze/3n7otFdPrxcQ4Bp//6Q6hZwHgUQFUsyH5AoW8eBHSx
IXQW5izBPljVYqO/dO0YcLPMW1RkxFlsKyWF7oQnW7MbzQgkpDpXxQ==
=nUga
=====END PGP SIGNATURE=====
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Question on biases in random numbers & decompression
Date: Thu, 05 Oct 2000 03:56:46 GMT
Ray Dillinger wrote:
>
> Ray Dillinger <[EMAIL PROTECTED]> wrote:
[snip]
> : or, you could try coming up with something sneaky... eight bits
> : is a range of 256 numbers, and five trits is a range of 243 numbers.
> : 256 = 243 (5 Trits) + 9 (2 trits) + 4 (2 bits). So you could take 8
> : bits at a time and behave like this:
>
> : 0-242 -- straight conversion to 5 trits, with no losses.
> : 243-251 -- subtract 243, convert the difference into 2 trits
> : 252-255 -- subtract 252, use these 2 bits in your next batch
>
> An analogy of this in 32 bits exists, of course. It's just annoying
> to find it.
>
> 2^32 = 4294967296
> 3^20 = 3486784401
>
> so if the 32 bit number is 3486784401, you can take 20 trits out of it.
>
> 2^32 - 3^20 = 808182895
> 3^18 = 387420489
>
> so if the 32 bit number is in the range 3^20 to 3^20 + 3^18,
> you can push back a zero into your reserve of bits and get 18 trits.
>
> if the 32 bit number is in the range 3^20+3^18 to 3^20+(2* 3^18)
> you can push back a 1 and get 18 trits.
>
> Et cetera.... the more you are willing to remember and work
> with, the less throwing away you'll have to do. This approach
> will actually "salvage" trits out of the reservoir of bits that
> would otherwise be thrown away. It may be possible to make the
> system yield more trits out of these thrown-away bits, but it
> would be pretty hard to make sure in that case that the trits it
> yielded were in fact unbiased.
>
> Ray
>
> Bear
Thanks, this looks pretty cool. I think this is what I'll use for the
part where I need to generate random trits.
--
... perfection has been reached not when there is nothing left to
add, but when there is nothing left to take away. (from RFC 1925)
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Newbie question to practical brute-force analysis
Date: Wed, 4 Oct 2000 21:04:07 -0700
"Jim Gillogly" <[EMAIL PROTECTED]> wrote ...
| Roger Gammans wrote:
[...]
| > What sort of differences would one expect to see in the output
| > of different modern block & stream ciphers?
[...]
| Not much for the ciphertext itself.
[...]
| When I say "not much" I'm leaving out things like the observation
that
| RC4 has been reported to have a very small but significant bias when
| viewed on very long files.
[...]
Is it true that more than a gigabyte of ciphertext
is likely to be required to detect the bias in RC4?
Does RC4's bias become a problem only in ciphertext
generated using a single key?
In other words, is the "RC4 bias problem" solved by
never using a single key for more than, say, a few
megabytes of text?
--r.e.s.
------------------------------
** 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
******************************
