Cryptography-Digest Digest #816, Volume #12 Mon, 2 Oct 00 18:13:00 EDT
Contents:
Re: is NIST just nuts? (David Schwartz)
Re: It's Rijndael (Will Janoschka)
Re: Comments on the AES winner (Tom St Denis)
Re: is NIST just nuts? (Tom St Denis)
Re: is NIST just nuts? (Tom St Denis)
Re: Avoiding bogus encryption products: Snake Oil FAQ (David Schwartz)
Re: is NIST just nuts? (Paul Rubin)
Re: Question on biases in random numbers & decompression (Ray Dillinger)
Re: is NIST just nuts? (Tom St Denis)
Re: NIST Statistical Test Suite (David Rush)
Re: Comments on the AES winner (John Myre)
Re: is NIST just nuts? (Tom St Denis)
Re: is NIST just nuts? (Paul Rubin)
Re: Comments on the AES winner (John Myre)
Re: is NIST just nuts? (SCOTT19U.ZIP_GUY)
Re: What am I missing? (Sagie)
Any products using Rijndael? ([EMAIL PROTECTED])
Re: Any products using Rijndael? (Tom St Denis)
Re: Avoiding bogus encryption products: Snake Oil FAQ (Sagie)
MyFish Cipher Update (Tom St Denis)
Re: MyFish Cipher Update (Tom St Denis)
Re: is NIST just nuts? (David Schwartz)
Re: Avoiding bogus encryption products: Snake Oil FAQ (David Schwartz)
Re: Shareware Protection Schemes (Jeffrey Williams)
Re: is NIST just nuts? (Mark Carroll)
----------------------------------------------------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: is NIST just nuts?
Date: Mon, 02 Oct 2000 13:18:24 -0700
Albert Yang wrote:
> It wasn't the best at anything... So no Tom, twofish shouldn't have
> won.
The best algorithm is not necessarily the best at any particular single
thing.
For example, the car with the best power will have 12 or more
cylinders. The car with the simplest design will have only one cylinder.
The best car for the real world is not the 'best' in either of these
categories. Engineering is a series of trade-offs.
DS
------------------------------
From: [EMAIL PROTECTED] (Will Janoschka)
Subject: Re: It's Rijndael
Date: Mon, 02 Oct 2000 19:53:33 GMT
Not a flame
Does someone know if the Rijndael key to encript
****RIJNDAEL**** to *AES*WINNER*AES*
does exist? Thought it wouls be a nice test vector.
-will-
on, 2 Oct 2000 14:46:09, Helger Lipmaa <[EMAIL PROTECTED]> wrote:
> David Lesher wrote:
>
> > Now all the flaming can start, right?
>
> No, why? Rijndael was objectively the favorite.
>
> Helger
>
>
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Comments on the AES winner
Date: Mon, 02 Oct 2000 20:21:11 GMT
In article <[EMAIL PROTECTED]>,
JCA <[EMAIL PROTECTED]> wrote:
> I understand that the original Rijndael (i.e. with 10
> rounds) seemed to be dangerously close to be broken,
> in the sense that an 8 round Rijndael has already been
> broken. I have been unable to find information in this
> respect so I assume that the are no additional rounds
> in the newly-elected AES.
Goto www.counterpane.com/labs.html
> As an aside, in my browser the number of possible
> 128-bit key for Rijndael, as mentioned in the AES
> fact sheet, appears as 3.4*101038. Can anybody see it as
> it should (3.4*10^38)?
128 bit key = 2^128 possible keys... why convert it to base 10? Do you
know how many 10^38 is? the number is too big to imagine... so why be
inaccurate?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: is NIST just nuts?
Date: Mon, 02 Oct 2000 20:18:20 GMT
In article <[EMAIL PROTECTED]>,
Albert Yang <[EMAIL PROTECTED]> wrote:
> I don't think Twofish should have won. Twofish is WAY too complex,
and
> complexity in crypto is like a cat in a rocking chair store..
First off Twofish is not impossible to code, there are several good
sources already.
> It wasn't the most secure or had the most security margain (Serpent
wins
> that)
I didn't say it was the most secure, I said "Rijndael is not the most
secure". Twofish is however, more secure then Rijndael.
> It wasn't the most elegant (RC6, hands down)
>
> It wasn't the easiest to cryptoanalyse (Serpent, RC6, and Rijndael)
Um Twofish is not that hard to analyzer either. It's structure is
rather straight forward. The keyschedule is still a bit foggy for me,
but the round function is simple (note: I used it in my design of
MyFish).
> It wasn't the fastest on software (Rijndael, RC6)
I thought Twofish ran at 16.1 cycles per byte, that's 258 cycles per
block which is 30 cycles slower then RC6. I think your speed claim is
grossy disproportionate.
> It wasn't the fastest on hardware (Serpent, Rijndael)
Hardware is *not* where we will see alot uses of it.
> It wasn't the best at anything... So no Tom, twofish shouldn't have
> won.
>
> I thought Rijndael with 16 rounds for all key sizes would have been
> better, but oh well...
Ah, but Rinjdael doesn't have 16 rounds, it has 10/12/14 rounds. Also
You are very independent... Twofish is good in more areas then Rijndael
is. Twofish is fast, versatile (can be implemented in a plethora of
mannors), it's secure. You claim it's slow, but it's not. You claim
it's hard to code, but it's not. You claim it's insecure? It's not.
Sure Rijndael/RC6/Serpent may be better in some ways but when it boils
down to it "security" is the primary concern. I would have been much
happier if Twofish or Serpent won. Just because Rijndael may be fast
doesn't mean it's the right choice.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: is NIST just nuts?
Date: Mon, 02 Oct 2000 20:19:52 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> Tom St Denis wrote:
> >
> > As if that was picked... From what I understand it's not at all
close
> > to the securest block cipher. Will aes specify that cipher with
more
> > rounds? What a shame...
> >
> > I demand a recount! Twofish should have won!
>
> I guess that there are lots of people at NIST having
> superior crypto knowledge than you. If they are nuts .....
Oh shut up. Rijndael has had more rounds broken then any of the other
finalists. And when you give Rijndael the 18 rounds it requires it's
no better performance wise then Twofish.
Granted the attack against Rijndael doesn't break all the rounds and is
in no way practical, but then again when NBS decided on DES they
thought 56 bit keys were ok. Am I the only one to notice a pattern
here?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Avoiding bogus encryption products: Snake Oil FAQ
Date: Mon, 02 Oct 2000 13:27:13 -0700
Robert Davies wrote:
> Isn't time some-one updated this. E.g. hasn't the US government
> relaxed its export rules a little?
>
> Robert
Yeah, exportability is no longer a way to judge strength. Products that
classify as 'retail' (or which are open source) can be exported
regardless of strength.
DS
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: is NIST just nuts?
Date: 02 Oct 2000 13:40:26 -0700
Tom St Denis <[EMAIL PROTECTED]> writes:
> I didn't say it was the most secure, I said "Rijndael is not the most
> secure". Twofish is however, more secure then Rijndael.
Is that so? Do you have a break for Rijndael but not for Twofish?
------------------------------
From: Ray Dillinger <[EMAIL PROTECTED]>
Subject: Re: Question on biases in random numbers & decompression
Date: Mon, 02 Oct 2000 20:44:04 GMT
Ray Dillinger <[EMAIL PROTECTED]> wrote:
: Well, you could definitely bite it off in larger chunks. If you pull
: bits out of your Random Number Stream 32 at a time, you can just
: convert it to ternary notation and take those trits. In this case,
: because it doesn't come out exactly, the first trit won't have the
: full range of possibilities -- the odds of a "2" won't be as high
: as for the other trits, or perhaps a "2" won't even be possible and
: the odds of a "1" won't be as high. If it's the first case, you
: can discard any 2's and push back an 0 or 1 result as one of the
: next batch of bits. If it's the second case, just discard the first
: trit. Depending on which case it is, you should be able to waste
: either just a bit more, or just a bit less, than one bit out of
: every thirty-two, and you will *always* get a valid trit in a
: bounded time.
Excuse me, I wasn't thinking straight here. If the first trit is
of skewed distribution possibilities, and the abnormal possibility
actually *comes up*, then the next trit will also be of skewed
distribution possibilities. Thus, there is a possibility you will
have to discard the second trit as well -- and the third, etc....
Which makes the following approach better for all cases, even
though there is the (however rapidly attenuating) possibility of
an "unbounded" time to get the next trit.
: 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
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: is NIST just nuts?
Date: Mon, 02 Oct 2000 20:49:02 GMT
In article <[EMAIL PROTECTED]>,
David Schwartz <[EMAIL PROTECTED]> wrote:
>
> Albert Yang wrote:
>
> > It wasn't the best at anything... So no Tom, twofish shouldn't have
> > won.
>
> The best algorithm is not necessarily the best at any
particular single
> thing.
Well given that the requirement of a block cipher is primarily
security, i think the fact that Twofish is more secure makes my
complaint quite valid.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: David Rush <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: NIST Statistical Test Suite
Date: 02 Oct 2000 11:56:48 +0100
"bubba" <[EMAIL PROTECTED]> writes:
> I built it last night using Microsoft VC6.0 for x86.
> I got plenty of warnings. Some suggest SUN's
> compiler missing questionable code.
Don't even get me started. Sun used to have one of the best commercial
development platforms. This past year I have been finding out that it
just sucks. What a waste...
david rush
--
Java is a WORA language! (Write Once, Run Away)
-- James Vandenberg (on [EMAIL PROTECTED])
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Comments on the AES winner
Date: Mon, 02 Oct 2000 15:06:21 -0600
JCA wrote:
<snip>
> As an aside, in my browser the number of possible
> 128-bit key for Rijndael, as mentioned in the AES
> fact sheet, appears as 3.4*101038. Can anybody see it as
> it should (3.4*10^38)?
<snip>
It's just wrong at the server. Jim Foti says they're
in the process of fixing it.
JM
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: is NIST just nuts?
Date: Mon, 02 Oct 2000 21:05:36 GMT
In article <[EMAIL PROTECTED]>,
Paul Rubin <[EMAIL PROTECTED]> wrote:
> Tom St Denis <[EMAIL PROTECTED]> writes:
> > I didn't say it was the most secure, I said "Rijndael is not the
most
> > secure". Twofish is however, more secure then Rijndael.
>
> Is that so? Do you have a break for Rijndael but not for Twofish?
Well I said earlier that in terms of practicallity Rijndael was not
broken. But in that case why not just design a fast block cipher that
takes say 2^60 work... cuz that's stupid?
Square was broken because of it's structure, the same attack works on
Rijndael with limited success (7~8 rounds). Again the best attack
against Twofish barely breaks half of the rounds.
At anyrate a block cipher is suppose to be secure, I would have enjoyed
Serpent being picked over Twofish, but at the least Twofish.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: is NIST just nuts?
Date: 02 Oct 2000 14:16:52 -0700
Tom St Denis <[EMAIL PROTECTED]> writes:
> Well given that the requirement of a block cipher is primarily
> security, i think the fact that Twofish is more secure makes my
> complaint quite valid.
Where is your evidence that Twofish is more secure? Apparently NIST
and the NSA didn't think it was more secure.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Comments on the AES winner
Date: Mon, 02 Oct 2000 15:15:27 -0600
Tom St Denis wrote:
>
> In article <[EMAIL PROTECTED]>,
> JCA <[EMAIL PROTECTED]> wrote:
<snip>
>
> > As an aside, in my browser the number of possible
> > 128-bit key for Rijndael, as mentioned in the AES
> > fact sheet, appears as 3.4*101038. Can anybody see it as
> > it should (3.4*10^38)?
>
> 128 bit key = 2^128 possible keys... why convert it to base 10? Do you
> know how many 10^38 is? the number is too big to imagine... so why be
> inaccurate?
Who are you talking to, Tom? What has your response to do
with JCA's question? He merely pointed out that the
government-furnished FAQ (it is clearly for non-experts)
isn't formatted well. He's wondering if it is the fault
of his browser (which it is not).
(You can see what he is talking about, if you check before
NIST fixes it. From the AES home page click AES Fact Sheet
and look at #15 and #16.)
JM
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: is NIST just nuts?
Date: 2 Oct 2000 21:13:14 GMT
[EMAIL PROTECTED] (alex) wrote in <8rajuk$r1h$[EMAIL PROTECTED]>:
>you could email monika lewinsky, she could perhaps ask the President for
>that.
>
>
>Tom St Denis <[EMAIL PROTECTED]> a �crit dans le message :
>8raips$vsd$[EMAIL PROTECTED]
>> As if that was picked... From what I understand it's not at all close
>> to the securest block cipher. Will aes specify that cipher with more
>> rounds? What a shame...
>>
>> I demand a recount! Twofish should have won!
>>
>> Tom
>>
I guess Tommy still does not understand. Real security has
little to do with the contest. I am not sure two fish is secure
but the government has to pick a cipher the NSA could break or they
would not allow it to be used. I just hope it modivates him to find
a break. It is even possilble the NSA may yet want another alogorithm
so we may magically see a break in this cipher or a weakness so that
another one of there choice could be placed out there.
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: Sagie <[EMAIL PROTECTED]>
Subject: Re: What am I missing?
Date: Mon, 02 Oct 2000 21:20:06 GMT
> Okay, but the idea of watermarking is that removing the scheme
> requires distorting it into the ground. Sufficiently low
parameters
> will damage the music, and at that point you can keep the music.
Obviously. Question is, what is their criterion for "low".
> A compressor must keep its hands off something unless it is
> fair game to change in ALL, or at least MOST music.
So does watermarking, as long as I pay the price for the product. I
don't want anything that is deformed or defective.
> Here's a less stupid example: spread spectrum. Take the
> FFT of the music, and lightly (but not too lightly) tweak
> 100 different low-frequency components. The tweaking is
> done by a 100-element key vector: freq_i = freq_i * vector_i,
> where each vector_i is close to 1.
>
> The watermark is detected by correlation.
Yes but if the tweaking is so slight, you'll have to do it over a large
portion so the correlation will have sufficient data to build up on. I
don't think this will be used. Either way, all compressions nowadays
tweak frequencies (in fact, MP3 files contain FFT representation of the
music, which was maimed to fit in the bitrate). I think that unless the
spread-spectrum key is aggressively applied, it will not slip through
any modern compression scheme at streaming quality (e.g. MP3 at 96-
128kbps).
> The simple fact is that you can tweak music much more,
inaudibly,
> than any compressor can inaudibly remove any correlation. This
> may sound paradoxical, but is due to the fact that you are
> using a secret key vector. The compressor has no idea what
your
> vector is, and chances are any mild changes it makes to the low
> frequency bins will be almost orthogonal to your vector.
> In order for the compressor's orthogonal change to be so strong
that
> your mark isn't detected, the bins would have to be greatly,
audibly,
> distorted.
>
> I don't know who does this with audio, but it's a common
approach
> in image marking. Compressing out a particular watermark is
> easy; compressing out the ENTIRE space of ~2^100 watermarks is
> impossible.
>
That's true, but the more damage the correlation suffers, the more
signal it needs to correlate, and we're talking about finite-signals
here. Plus, the receiving end has got its limits, and were not talking
about big video/picture editing stations, but normal computers and even
portable audio devices, where resources are scarce and no one would
sacrifice them to correlate a large chunk of audio for any
organization. So maybe if the watermark will somehow be detected on
PCs, it will probably not be detected on portable devices, which is
really THE issue, because cracking PC software to disable the SDMI
rules would be easy (well much easier then cracking portable devices).
> >If the changes are so sublte and undetectable by the human ear you
can
> >count on it that compression methods will use those tricks for the
> >compression process (if they create a more effective representation
of
> >the signal, obviously) or remove these changes as part of the
> >optimization.
>
> You can imagine this in theory, but not count on this in
> practice. Stretch any image you own by 1% in width.
> This is subtle and practically undetectable by most users,
> w/o reference to the original. But no image compression scheme
> will know to undo it. No image compression scheme will take
> all images around 480 pixels wide and scale them to 480 pixels
> to wipe out that undetectable change. Width is off-limits.
Stretching the width will not benefit you anyway. This is not a
watermark. Anyway, the point is not to "undo" the watermark, but rather
to hurt the correlation enough so it would not be detected.
> >You're forgetting that we have the "before" and the "after". We
already
> >have the exact watermark signal that was introduced to the audio, we
> >don't have to "find" it.
>
> First, you don't necessarily have _the_ signal. It can be
> different from clip to clip, so different that the difference
> tells you nothing about what will be found in the next audio
clip.
>
> Second, the difference will not necessarily betray a
> "watermark signal." If a watermark is embedded in a wacky
> non-additive way, the difference is best described as a signal
> that hints that one method was used, but which itself might
> not contain the mark information.
>
> Instead, the difference gives vital clues, but is not itself
the
> watermark, unless you trivally define "the watermark" as the
> object X such that Original + X = Marked. This is not a good
> model for a lot of schemes.
We have the signal for this clip. We can see how it is related to the
original signal, maybe see some tricks that are performed, I suppose.
If there is a certain key, we might be able to figure it out, as we
have the before and after. For instance, say they implemented the
spread spectrum method you have suggested, which is essentially:
Original * X = Marked. We have original, we have marked, we can find X.
This is of course a general notation, because it should be performed
for each bin of the FFT. Either way, doing this is stupid because once
they'll decide on a certain method they'll have to publish it. So
instead of wasting time on cracking the suggested technologies (which
might be possible even with this small amount of information), I think
waiting for the specs of the chosen one, then cracking it would be much
more efficient.
> > We don't have to crack the technology -- all we have to do is cause
enough
> > inaudible (or slightly audible) damage to the signal to render the
watermark
> > undetectable and get the 10K$ paycheck...
>
> Exactly. Tho, you have to be sure that your inaudible damage
works
> not just on this clip but on others as well. If you have
cracked
> the technology, you're much more likely to be certain of this.
Obviously. This is a tedious procedure, which is why I would wait for
the specs.
> >> Also see the work of Lisa Marvel et al, who developed a spread-
> >> spectrum stego scheme that can conceal about 5 kilobytes very
> >> robustly (and error correction is all taken care of) in a
512x512
> >> monochrome image.
> >
> >That's very impressive, but one should wonder what artifacts are
> >introduced to the image as a result (we are talking about 1-bit depth
> >per pixel, right?).
>
> No, more like 8-bit depth. But you'd be shocked by what spread-
> spectrum techniques can survive! Dither that puppy down to 1
bit,
> print it out, run it through a copy machine, rescan it....
...and it will definitely not survive it... Come on... A copy
machine??? Most of the times *I* can't make up anything from a copy
machine copy.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Any products using Rijndael?
Date: Mon, 02 Oct 2000 21:19:43 GMT
I wonder if there is any product that actually use this new AES?
Im looking for disk encryption.
T.I.A
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Any products using Rijndael?
Date: Mon, 02 Oct 2000 21:23:58 GMT
In article <8rau57$afr$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I wonder if there is any product that actually use this new AES?
> Im looking for disk encryption.
> T.I.A
So because it uses AES it must be a good tool right?
See: It's starting already. People are buzzing towards AES.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Sagie <[EMAIL PROTECTED]>
Subject: Re: Avoiding bogus encryption products: Snake Oil FAQ
Date: Mon, 02 Oct 2000 21:24:33 GMT
> classify as 'retail' (or which are open source) can be exported
> regardless of strength.
.... to non-embargoed countries. It's just that now, instead of
stating "this product may not be exported", it reads "may not be
exported to embargoed states".
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: MyFish Cipher Update
Date: Mon, 02 Oct 2000 21:28:07 GMT
I updated my MyFish code to use a new gf_inv() routine (square-multiply
basically) which is 18 times faster. I also changed the key schedule
to avoid weak keys in the sense that a multiplicand could be zero. I
realize the lost of entropy in the sboxes in Myfish, but seriously
there is log2(255*255*255*255)=31.98 bits of entropy instead of 32 so I
doubt the effect is dramatic.
Also because the inversion can be done much quicker (14 gf_multiplies)
in some applications the g-functions do not have to be fully
precomputed. Although MyFish is intented for bulk data encryption on
a PC. I get about 109.05mbits/sec on my PIII 550mhz which is a tad
slow but no slower then Serpent (this is about 660 cycles per block).
In assembler I would bet that MyFish is faster then Twofish primarily
because of the lower number of instructions. I am not the best asm
coder though so I will leave that for now.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: MyFish Cipher Update
Date: Mon, 02 Oct 2000 21:32:40 GMT
In article <8rauku$avi$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> I updated my MyFish code to use a new gf_inv() routine (square-
multiply
> basically) which is 18 times faster. I also changed the key schedule
> to avoid weak keys in the sense that a multiplicand could be zero. I
> realize the lost of entropy in the sboxes in Myfish, but seriously
> there is log2(255*255*255*255)=31.98 bits of entropy instead of 32 so
I
> doubt the effect is dramatic.
Arrg... "loss in entropy" and it's log2(255*255*256*256)..
Sorry.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: is NIST just nuts?
Date: Mon, 02 Oct 2000 14:34:28 -0700
Tom St Denis wrote:
> Well given that the requirement of a block cipher is primarily
> security, i think the fact that Twofish is more secure makes my
> complaint quite valid.
>
> Tom
If security was the only factor, they could have picked any cipher
(almost) and just quadrupled the number of rounds. While security was
allegedly the primary factor, it was never even claimed to be the only
factor. Personally, I do believe that Rijndael has too few rounds. Four
more rounds would make me much happier.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Avoiding bogus encryption products: Snake Oil FAQ
Date: Mon, 02 Oct 2000 14:39:34 -0700
Sagie wrote:
>
> > classify as 'retail' (or which are open source) can be exported
> > regardless of strength.
>
> .... to non-embargoed countries. It's just that now, instead of
> stating "this product may not be exported", it reads "may not be
> exported to embargoed states".
I believe that this requirement does not exist for products that
qualify as 'retail mass market'. And I'm pretty sure it doesn't apply to
products produced by compiling publically available source code. I've
scanned the relevant bits of the regulations and I can't find the usual
exclusion from embargoed nations.
DS
------------------------------
From: Jeffrey Williams <[EMAIL PROTECTED]>
Subject: Re: Shareware Protection Schemes
Date: Mon, 02 Oct 2000 16:42:34 -0500
Well, assuming that I *knew* that that was the protection scheme being used, *I*
would certainly think twice before allowing someone to have a copy of my legal
copy. Then again, if I *knew* about the protection scheme before I bought the
software, I'd think twice about buying the software in the first place
On a slightly different, but related, angle, I'm a bit confused (duh). I was
under the impression that one was supposed to be able to share shareware with
others (essentially, word of mouth being the means of distribution). I do not
understand this concept of having a key within the confines of the software.
Could someone fill me in?
Jeff
Darren New wrote:
> Ichinin wrote:
> > - What would stop anyone from distributing the software WITH
> > a (stolen or compromised) legitemate key?
>
> I saw an interesting mechanism once that just put the credit card number
> used to pay for the software into the "About" box. Encrypted in the
> executable, of course. And it wasn't worth it to me to try to track down how
> to remove it, since I'd paid for the software. A simple thing like is likely
> just as much a hinderance to people trying to steal it as anything more
> complicated, for all the reasons already mentioned here.
>
> --
> Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
> San Diego, CA, USA (PST). Cryptokeys on demand.
> The tragedy of the commons applies to monitizing eyeballs, too.
------------------------------
From: [EMAIL PROTECTED] (Mark Carroll)
Subject: Re: is NIST just nuts?
Date: 2 Oct 2000 21:53:06 GMT
In article <[EMAIL PROTECTED]>,
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
(snip)
>little to do with the contest. I am not sure two fish is secure
>but the government has to pick a cipher the NSA could break or they
>would not allow it to be used. I just hope it modivates him to find
(snip)
Uh? That's why they made DES more resistant to differential
cryptanalysis by changing the S-boxes even though leaving it as it was
would have given the NSA an advantage over the public in breaking it,
as differential attacks weren't public knowledge then?
-- Mark
------------------------------
** 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
******************************
