Cryptography-Digest Digest #829, Volume #11 Sun, 21 May 00 13:13:00 EDT
Contents:
Re: AES final comment deadline is May 15 (Mark Wooding)
Re: QUESTIONS About ALGOS !! (tomstd)
Re: Q: Recording on magnetic cards (Mok-Kong Shen)
Re: Re: Who has got RSA simple program (sources on C/C++)? (tomstd)
Re: Interpretation of Hitachi patent claims ("Lyalc")
Re: Q: Recording on magnetic cards (Troed)
Re: Encrypting random data (Tim Tyler)
Re: Encrypting random data (tomstd)
Again about Fast RC5 (tomstd)
Re: Probabilistic Encryption (David A Molnar)
Re: quantum crypto breakthru? (Tim Tyler)
Re: Q: Recording on magnetic cards (Francois Grieu)
Re: Is OTP unbreakable? (Paul Schlyter)
Access Encryption ("John E. Kuslich")
Re: Compare 3DES's. (long) (Was: Mixmasters encrypt how?) ("Trevor L. Jackson, III")
Plain simple (?) question (Alain CULOS)
Re: Interpretation of Hitachi patent claims ("Trevor L. Jackson, III")
Re: More on Pi and randomness ("Trevor L. Jackson, III")
Re: Compare 3DES's. (long) (Was: Mixmasters encrypt how?) (David A. Wagner)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: AES final comment deadline is May 15
Date: 21 May 2000 10:34:11 GMT
Scott Contini <[EMAIL PROTECTED]> wrote:
> You are assuming single block encryption. RC6 seems to do quite
> well on many modern 32/64-bit processors if you simulataneous encrypt
> multiple blocks. You just get a lot more freedom on how to schedule
> the multiplies, which makes the timings much better than single block
> encryption. Rijndael, Serpent, and Twofish do not get nearly as much of
> a benefit from this as RC6 does.
In other words, to get reasonable performance out of RC6 you need to
start using nonstandard encryption modes.
> There is a lot to say for having a simple cipher that is easy to analyze,
> like RC6. For example, consider this: when RC6 was submitted to the
> AES, it was suggested that 16 rounds could be attacked using linear
> cryptanalysis, and such an attack was described. Nobody has improved
> on this result.
Yet.
> Moreover, RC6 bases its security on the data dependent rotation (which
> is "strengthened" through the f(x) = 2*x^2 + x function) which has
> been well studied from 6 years of public research on RC5.
Don't forget that the first sensible attack against DES's S-boxes --
Biham and Shamir's differential cryptanalysis -- came about fifteen
years after the cipher was introduced. I don't think that six years is
really long enough for us to say that a particular new component is
`strong'. Any clever new attacks directed specifically against data
dependent rotations leave RC6 hanging out to dry.
> When NIST suggested that simplicity of a cipher was important, it was
> so that the cipher could be readily analyzed and people can get a good
> feeling for the security the cipher offers. Many of the comments I am
> reading on this newsgroup just seem to ignore the value of this.
I'll grant you that Twofish and MARS are complicated, and this is a
legitimate point against them. I think MARS is ugly and kitchen-sink-
ish in a way that Twofish isn't, though. But I don't see how you can
claim that Rijndael and Serpent are less simple than RC6. Serpent, in
particular, is based on very simple concepts: substitution tables (an
idea which has been analyzed longer than data-dependent rotations) and a
linear transformation for diffusion.
-- [mdw]
------------------------------
Subject: Re: QUESTIONS About ALGOS !!
From: tomstd <[EMAIL PROTECTED]>
Date: Sun, 21 May 2000 03:39:02 -0700
In article <8g7lbp$2sa$[EMAIL PROTECTED]>, "Scott
Fluhrer" <[EMAIL PROTECTED]> wrote:
>
>tomstd <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> In article <8g78oq$fm2$[EMAIL PROTECTED]>, "Scott
>> Fluhrer" <[EMAIL PROTECTED]> wrote:
>> >
>> >Jerry Coffin <[EMAIL PROTECTED]> wrote in message
>> >news:[EMAIL PROTECTED]...
>> >> In article <8fu3it$osb$[EMAIL PROTECTED]>,
>> [EMAIL PROTECTED]
>> >> says...
>> >>
>> >> > 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 ?
>> >>
>> >> No. Rather the opposite: DES is fairly slow and 3DES is
>> about one
>> >> third that speed.
>> >
>> >Actually, before we make the pronouncements "DES is fairly
slow
>> and 3DES is
>> >slower", we need to ask the question: how fast does the OP
need
>> them to be?
>> >His definition of "very fast" may be drasticly different then
>> our definition
>> >of "very fast". If 3DES is fast enough for the OP (and none
of
>> the rest of
>> >us know enough to say), then 3DES may be a fine choice.
>>
>> 3des is not a bad choice, just not a good one for many tasks.
>> It's cumbersome and slow.
>
>3DES is sufficiently fast and sufficiently secure for many
tasks. The OP
>has not posted his definition of "fast enough", it might
be "encrypt a short
>message in less than 10 milliseconds. We would realize this to
speed a
>"speed is not important" situation, but the OP is not crypto-
savvy, and may
>not realize that.
>
>For that matter, the same goes for the security requirement.
Maybe he
>really is hiding things from his kid sister. In that case, DES
has plenty
>of security.
>
>And, in terms of security, I would, at the present state of the
analysis,
>trust 3DES over any of the AES candidates -- DES has had a
*lot* of
>analysis.
So has blowfish, rc5, cast and IDEA. Big deal.
>> >
>> >> > I've been told that Blowfish algorithm was very fast and
>> secure.
>> >> > What do you think about it ?
>> >I agree with Mr. Coffin: there is little reason to use
Blowfish
>> when Twofish
>> >or the other AES finalists are available. You may want to
>> avoid RC/6, for
>> >intellectual property reasons as noted by others.
>> >
>> >If they aren't fast enough, then you probably need to look
at a
>> stream
>> >cipher (they tend to be a bit faster), faster hardware, or
>> figuring out how
>> >to make your application work with encryption that isn't
quite
>> as fast as
>> >you wanted it...
>>
>> I disagree, just as an example I have RC5 code with 12 rounsd
>> [1] that runs at 135 cycles/block [2]. If this is not fast
>> enough then tough...
>Actually, 16 cycles/byte is fast for a block cipher, a stream
cipher can go
>much faster. If you can get the rights to Seal (a nontrivial
prospect),
>that can do 4 cycles/byte. IIRC, ARC4 can do about 7-8
cycles/byte. (And,
>I don't remember the details of RC5: is 12 rounds a reduced
round version?
>That's not recommended unless you know exactly what you are
doing).
12 rounds is the original proposal (which is why they list it in
the paper specifically). The attack requires 2^53 pairs, so
it's not practical.
I worked on my code [1] to include a hardware timer read (RDTSC)
and found my code to run at 11.625 cycles/byte on my brothers
Athlon, and 16.25 cycles/byte on my K6-2. If that is not fast
enough, then I don't know what is.
>Of course, if you use an additive stream cipher, you have a
number of things
>to be concerned about: you should never re-use keystream, and
(unless
>otherwise protected against), ciphertext modification attacks
become much
>more effective.
Always can use a MAC.
[1] http://www.tomstdenis.com/rc5asm.zip education use only.
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]>
Subject: Re: Q: Recording on magnetic cards
Date: Sun, 21 May 2000 12:48:08 +0200
Francois Grieu wrote:
> > lots of coins between the cards and the read/write station
>
> I believe this rules out magnetic stripe; your cards are IMHO
> induction-coupled IC card. This explains the at-a-distance operation.
> Such cards are used, for example, in fare collection or access control.
> Some are dual mode (contact as of ISO 7816, contactless as of
> ISO 14443), some are only contactless.
>
> There is no problem with selecting the approriate card; they act
> like computers on a network, with individual ids and everything.
It is unfortunate that I can't present the card physically
to you because of the distance that separate us. But I
can assure you that I can't detect the presence of any
chip on it and that it has a black stripe on its back. It
must work on the same principle like some others, e.g.
cards used for doing copies at copy machines (which are
made of paper not plastic however).
M. K. Shen
------------------------------
Subject: Re: Re: Who has got RSA simple program (sources on C/C++)?
From: tomstd <[EMAIL PROTECTED]>
Date: Sun, 21 May 2000 03:41:34 -0700
In article <[EMAIL PROTECTED]>, Maxim L <maxim-
[EMAIL PROTECTED]> wrote:
>Hello tomstd,
>
>Thank you VERY MUCH,
>
>This sources files very useful for me. Your test-program works
>properly.
Glad to hear it. From time to time I update the library.
Currently I am concentrating on portability and better
interfaces to the symmetric ciphers. So stay tuned.
Enjoy CryptoBag :)
Tom
--
CryptoBag: http://www.tomstdenis.com/cb.html
* 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: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Interpretation of Hitachi patent claims
Date: Sun, 21 May 2000 21:41:22 +1000
snip
>> It could also mean defined by any deterministic method (e.g. Rx = 3+4, or
>> the 37th digit of PI, the time of day, or whatever)
>
>Then use of a dynamic value is not covered.
I'm not sure this is a valid conclusion
------------------------------
From: [EMAIL PROTECTED] (Troed)
Subject: Re: Q: Recording on magnetic cards
Reply-To: [EMAIL PROTECTED]
Date: Sun, 21 May 2000 11:58:30 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>It is unfortunate that I can't present the card physically
>to you because of the distance that separate us. But I
>can assure you that I can't detect the presence of any
>chip on it and that it has a black stripe on its back. It
>must work on the same principle like some others, e.g.
>cards used for doing copies at copy machines (which are
>made of paper not plastic however).
No visible chip is needed, that's probably why you can't see one :)
And the magnetic stripe is probably there because the card is
dual-purpose.
___/
_/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Encrypting random data
Reply-To: [EMAIL PROTECTED]
Date: Sun, 21 May 2000 10:52:19 GMT
tomstd <[EMAIL PROTECTED]> wrote:
: Tim Tyler <[EMAIL PROTECTED]> wrote:
:>Tom St Denis <[EMAIL PROTECTED]> wrote:
:>: [EMAIL PROTECTED] wrote:
[sending a pad of random data under encryption]
:>: You seem like a very confused individual. [...]
:>
:>It does make some sense. This protocol even gets di[]scussed in
:> BS's AC. [...]
:> *If* the source of randomness is good, it has some advantages
:> over vanilla RC4. For example, consider the implications of a
:> chosen-plaintext attack on both schemes.
[...]
: At best you have RC4 there, no matter how you look at it.
...but consider the implications of a chosen-plaintext attack on RC4.
With vanilla RC4, you could just leak a document to the enemy, and watch
as he forwards it back to HQ, recovering the key. With RC4 plus the
"random pad", such an attack would fail - as you could not control the
input to RC4.
Unfortunately, I said a false thing in my last post. Bruce Schenier
discusses this protocol - with the significant addition of encrypting
the XOR'd message with a second algorithm (AC, 2nd edition, p. 382).
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Goodbye cool world.
------------------------------
Subject: Re: Encrypting random data
From: tomstd <[EMAIL PROTECTED]>
Date: Sun, 21 May 2000 05:38:43 -0700
In article <[EMAIL PROTECTED]>, Darren New
<[EMAIL PROTECTED]> wrote:
>Tom St Denis wrote:
>> You seem like a very confused individual.
>
>Just ignorant, really. :-)
Well don't be negative. It's ok to make mistakes (follow my
posts long enough and you will see what I mean).
>
>> So you cannot share random bits over an insecure medium at
all, unless
>> you are willing to sacrifice randomness at the hands of
deterministic
>> finite algorithms.
>
>My thought was more along the lines of sharing a hardware RNG
over a LAN,
>rather than necessarily what I do with the random numbers
afterwards. I
>didn't have any particular application in mind. I was just
trying to figure
>out if something like really random numbers encrypted with a
decent
>encryption were at all breakable by someone listening in on the
LAN. Of
>course, if they get both the encrypted random numbers and the
message
>encoded with the decrypted OTP, it'll be easier to break, and I
realize now
>I'm confused as well as ignorant, having forgotten that the
final recipient
>is going to need the OTP to decrypt, too.
>
>My thoughts were really about using a hardware RNG over a LAN,
rather than
>what one does with the bits afterwards. I.e., if I securely
transmitted a
>RC4 key to HotBits, would that keep people from sniffing my
random numbers
>from their machine? Would there be any way for people to break
that if those
>numbers never left my machine again?
>
>Thanks for your thoughts!
The reasons it doesn't work is this.
I have plaintext P, and a otp K1, a rc4-key K2... and Ciphertext
C = P xor (rc4k2(k1))
I.e encrypt the otp and xor it against P to get a stream
cipher. All I have todo is try every single possible K2 (rc4-
key) and then try the resulting stream against C.
Or something to that effect, actually I doubt that would work,
but still I wouldn't use that method. Against a known plaintext
attack I could recover K1 by brute forcing K2, yeah that would
work. Then you have no more pad...
You have C = P xor (k1 xor RC4k2)
(assuming RC4 just output bytes we xor together...)
Which means if I know P and Rc4k2, then I can find K1 really
easily. If I just know rc4k2, and not K1 or P then I am lost.
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: Again about Fast RC5
From: tomstd <[EMAIL PROTECTED]>
Date: Sun, 21 May 2000 05:41:56 -0700
I clocked my updated routine (moved some instructions around to
pair better) at (encrypt) 126 cycles/block and (decrypt) 134
cycles/block. This equates to 15.75 cycles/byte and 16.75
cycles/byte respectively.
On a K7 it gets 93 cycles/block either way (well pretty close to
each other) which is about 11.4 cycles/block.
On a PIII it gets about 14 cycles/block encrypt, 12 cycles/block
decrypt.
The code is available at http://www.tomstdenis.com/rc5asm.zip
and a test executable (if you just want to try it out) is at
http://www.tomstdenis.com/test.exe. For the paranoids in the
group (who don't run the exe, which is in retrospect a good idea
not to) you need DJGPP and NASM to build it.
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: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Probabilistic Encryption
Date: 21 May 2000 14:11:07 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> you send e-mail to [EMAIL PROTECTED] asking about
> availability of the paper; perhaps he'll send you a hard copy.
^^
It's actually "she."
I did not know this for several years, and then saw a picture of
her in some MIT flyer or other. It surprised me a great deal at the time,
which I suppose is unfortunate. :-\
Thanks,
-David
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: quantum crypto breakthru?
Reply-To: [EMAIL PROTECTED]
Date: Sun, 21 May 2000 14:20:00 GMT
Francois Grieu <[EMAIL PROTECTED]> wrote:
: "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
:> Measuring the state (interceptor's receiver) interferes with the
:> state, and the quantum-cryptographic protocol used by the
:> legitimate communicants detects that interference has occurred.
: I do understand why passively eavesdropping a communication link
: is made impossible with QC (eavesdropping destroys the message
: being transmitted)
: However, what about active eavesdropping ? [...]
That also fails for /exactly/ the same reasons. Alice and Bob can detect
a man in the middle during the verification stage.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Goodbye cool world.
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Q: Recording on magnetic cards
Date: Sun, 21 May 2000 17:17:36 +0200
Mok-Kong Shen <[EMAIL PROTECTED]> wrote :
> I can't detect the presence of any chip on it
The IC can be embeded inside the card. Try to look thru the card with
a bright light behind, you'll probably see a dark area where the IC
is, and a moreless rectangular coil at the periphery of the card.
Be sure
- not to look at the bright light unless it is hidden by the card
- not to let the light melt the card
Francois Grieu
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Is OTP unbreakable?
Date: 21 May 2000 16:15:23 +0200
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Guy Macon schrieb:
>
>> Paul Schlyter ([EMAIL PROTECTED]) wrote:
>>>> Still, OTP has two weaknesses though:
>>>>
>>>> 1. An eavesdropper can figure out the length of the message. This
>>>> can be countered by adding random garbage to your actual message.
>>>>
>>>> 2. An eavesdropper can figure out that a message has been sent.
>>>> This can be countered in two ways: either by steganography (which
>>>> hides the message somehow), or by sending many extra messages
>>>> containing nothing but garbage.
>>>>
>>>3. An attacker can modify the message. If he knows the position of
>>>some item within the plaintext, he can change it to any other string
>>>with the same length.
>>
>> It seems to me that adding a random length of random garbage at the
>> start and end of your message would counter 1 and 3.
>
> A slight disadvantage could be that the receiver can't surely know
> whether part of the random partions may be errors due to transmission
> or manipulated, I guess. But generally it should work.
This problem can be solved by an agreed-upon convention between
sender and receiver. For instance:
1. The valid message starts at the beginning and lasts until some
agreed-upon end-of-message mark, which must never appear in the
actual plaintext. Anything beyond that is to be considered random
garbage.
2. An arbitrary number of space characters are inserted in the
plaintext at the beginning or the end of the message. The receiver
will surely know to skip spaces! And with a true OTP key, adding
extra spaces to the plaintext will be just as secure as adding
random garbage.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Access Encryption
Date: Sun, 21 May 2000 09:34:20 -0700
Michael (michka) Kaplan <[EMAIL PROTECTED]> wrote in
message news:u7vwROzw$GA.197@cppssbbsa04...
<snip>
> For a fee and an NDA that would keep a person from ever using it and
> disclosing it, I can prove to the most diehard security fan that in ANY
file
> server db under Windows -- where you have access to both the engine dlls
and
> the db itself -- can be hacked by someone with sufficient time and
> knowledge. I even managed to do it without actually giving people the key
to
> the safe.... just definitively proving that a smart enough locksmith can
> find a way in.
<snip>
Glad to see you have seen the light. There is so much misinformation
regarding Access security spread by Microsoft lackeys. Just yesterday while
perusing the books shelves at Fry's electronics I read a startling statement
in an Access help - book claiming that if the database password on an mdb
file were to be forgotten, there would be no possibility of ever recovering
the database!!!
It is hard to believe that anyone with enough smarts to write a 1000 page
Access database How - To book could possibly be that ignorant of the
security flaws in Access.
Reading your quote, however, the Microsoft attitude toward security comes to
the fore: "Security through obscurity". Hide the security vulnerabilities
of Microsoft software. Discourage any security revelations on Microsoft
newsgroups by periodically censoring security related posts. Let the secret
knowledge never be known.
Microsoft and its lackeys need to get off that horse and start doing what
the Unix and Linux community has been doing for years; that is, positively
promoting knowledge about security vulnerabilities and exploits so that the
user community can come to terms with the problem and so solutions can be
generated.
This notion of NDA's and secret knowledge is classic Microsoft - Monopoly -
Think that will eventually lead to the downfall of the Redmond Behemoth as
corporations get burned again and again by "Melissa" and "I Love You"
hackinations.
Stop hiding the truth and start building solutions for these
vulnerabilities. And stop signing Microsoft NDA's. NDA's are for wimps.
So here is the truth: 1) mdb passwords are so easy to recover, your 8 year
old can do it. 2) User Level security is so easy to defeat your nine year
old could do it (given the mdw file - not a huge restriction). 3) Anyone
skilled in the art and/or properly motivated can defeat Access security
under almost any circumstances as you indicate in your post (this time).
So why not out the truth, reveal the vulnerability so Microsoft again will
be forced to fix the problem!!! Oh yeah - that pesky NDA... :--))
JK http://www.crak.com Password Recovery Software
Note to the Microsoft.public.access.security censor...You can find this post
on the sci.crypt newsgroup also so please don't censor it, ok?
------------------------------
Date: Sun, 21 May 2000 12:53:28 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Compare 3DES's. (long) (Was: Mixmasters encrypt how?)
Paul Schlyter wrote:
> If K1, K2 and K3 are all different, there are ways to attack 3DES
> which effectively reduces the key space to a 16-byte key. Therefore
> using K1 different from K3 offers little security advantages over
> using K1=K3.
>
> 24-byte keys aren't much stronger than 16-byte keys, due to that
> attack on 2DES which reduces a 24-byte key to a 16-byte key.
These comments ignore the storage costs of the attacks. You've claimed that a
requirement for 2^59 bytes of storage "offers little security advantage". I
think that's a little cavalier with respect to storage costs.
For instance, one can assemble a large collection of processors distributed in
an arbitrary arrangement to address the work factor requirements. But AFAIK,
no such collection capability can be used to address the storage
requirements. Certainly one can imagine an organization of 50 million
workstations each with 10 Gb drives, but it's certainly not a practical
technique now, nor do I expect it to become a trivial requirement in the near
future (~25 years).
------------------------------
From: Alain CULOS <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Plain simple (?) question
Date: Sun, 21 May 2000 17:53:36 +0100
Hi all,
I'll accept if you tell me (politely) to get lost, but hey I'm damn too curious
so I'll ask the experts at the risk of being flamed.
Anyone here knows which encoding algorithm/implementation uses only those
printable ascii characters except lowercase letters ?
What about something that contains a left quote and a right quote (that could
pass, there are ascii equivalents), but now, what about left double quote and
right double quote, this ain't ascii ??? The whole lot of the rest is ascii.
In case you wonder what I'm trying to decipher, I'm talking about some text
pages in the french translation of the novel tilted microserfs. I don't know
whether the codes are a hoax (like just varnish for the novel) or for real.
Later on in the novel there is also a binary session, that I'll try to decode,
but it does not even fall on a byte boundary (short 3 bits) so either this
really is a hoax, or this is a fragment badly terminated.
Thanks for your attention,
Regards,
Alain.
------------------------------
Date: Sun, 21 May 2000 13:11:51 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Interpretation of Hitachi patent claims
Lyalc wrote:
> We are all capable of discovering these things. The question is - did we,
> and did we doing anything about formalsing some claim to being the initial
> 'discoverer' of these things?
>
> I think the issue is the specific application of bit rotation to a specific
> type of data manipulation that has been considered novel by a patent office.
>
> It is very important to read the entire document before discounting the
> patent claims.
Most patent systems are careful to exclude a vast collection of techniques from
the domain of patent protection. Two of the most important areas that cannot be
patented are things one can do "in your head" and things that are "obvious".
The former are protected because it is impossible to prove that a patented
technique was used or not used if the critical process occurs inside a single
skull. The latter are protected to avoid the "land rush" effect of
registration. Domain names experienced something of a land rush in the
registration of existing trade/servicemarks and company names precisely because
those areas were not initially protected.
Under US patent law a technique that is "obvious" to an average practitioner in
the relevant field is not patentable. So any thing that "we are all capable of
discovering" cannot be patented. Such things as drawing and undrawing with XOR
can only gain patent protection because the examiners are not practitioners in
every field. This lack of expertise affects both novelty and unobviousness.
What may appear novel to a patent examiner may not be novel to someone fully
aware of prior art. This is why patent apps have to disclose prior art. Such
disclosures inform the examiners in areas they cannot be expected to be
adequately informed. Unobviousness it not as easy as novelty. The ISO unit of
measure for prior art is the second. There is no unit for unobviousness, so a
patent application cannot support the unobviousness requirement with objective
information. Thus disputes about the obviousness of patent applications resolve
down to subjective evaluations.
------------------------------
Date: Sun, 21 May 2000 13:14:05 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: More on Pi and randomness
Guy Macon wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> >I understand the Nth hexit of pi, irrespective of the value of N, to be
> >calculable using the equation derived by Borwein, Borwein and Plouffe.
> >The 400 billionth hexit of pi has been thus calculated.
>
> Really?!? (not questioning you, just suprised). Does the time to compute
> the answer get larger as N gets larger? Linearaly? Exponentialy?
Since the formula is based upon N, it's implementation grows as the log of N.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Compare 3DES's. (long) (Was: Mixmasters encrypt how?)
Date: 21 May 2000 10:04:17 -0700
In article <8g5g80$7s9$[EMAIL PROTECTED]>,
Paul Schlyter <[EMAIL PROTECTED]> wrote:
> > . How much stronger is use of 24 bytes of key as compared with 16
> > bytes? That is, how does E(K1,D(K2,E(K3,x))) compare to
> > E(K1,D(K2,E(K1,x)))?
> > at least 2**64 longer to crack than 16 bytes, but this assumes that no
> > attack more efficient than brute force is available.
>
> 24-byte keys aren't much stronger than 16-byte keys, due to that
> attack on 2DES which reduces a 24-byte key to a 16-byte key.
Half right. There's an attack on 2DES that has O(2^56) complexity,
so there's an attack on 3-key 3DES that has O(2^112) complexity --
that's all correct. But, what you didn't say is that there is also
a different attack on 2-key 3DES that is much faster than 2^112 work.
(I don't remember the exact complexity, but see, e.g., Applied Crypto.)
So, 3-key 3DES does appear to be safer than 2-key 3DES.
And I see little reason to prefer the 2-key variant...
------------------------------
** 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
******************************
