Cryptography-Digest Digest #987, Volume #10 Thu, 27 Jan 00 16:13:01 EST
Contents:
Re: *** ECC Strong and Weak combined (Mike Rosing)
Re: DES Hardare - chips/cores (Jayant Shukla)
Re: Reversibly combining two bytes? (Alan Lawrence)
Re: How much does it cost to share knowledge? (wtshaw)
Best Encryption Software? ([EMAIL PROTECTED])
Re: Any Reference on Cryptanalysis on RSA ? (Bob Silverman)
Re: Any Reference on Cryptanalysis on RSA ? (Bob Silverman)
Re: ECC & RSA re: patents, copyrights (Bob Silverman)
Re: RSA v. Pohlig-Hellman (Anton Stiglic)
Re: Strong stream ciphers besides RC4? (Terry Ritter)
Re: Mac encryption algorithm? (wtshaw)
Re: Intel 810 chipset Random Number Generator (Terry Ritter)
Re: Why did SkipJack fail? ("Douglas A. Gwyn")
Simon Sigh Enigm ([EMAIL PROTECTED])
NEC claims New Strongest Crypto Algor (Arthur Dardia)
Re: How much does it cost to share knowledge? ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: *** ECC Strong and Weak combined
Date: Thu, 27 Jan 2000 12:30:49 -0600
Greg wrote:
>
> I was doing some testing recently with my ECC code and I noticed
> that if I have a curve over a large field and a key that has the
> most significant bit set, it takes about one second to complete
> a point operation.
>
> Yet, if I keep the key value very small where, say, the 80% MSBs
> are clear, then the operation is very fast. This makes me think
> that given a very strong public key for a server, a client can
> use a random small private key which can be used to quickly generate
> both the client's public key and shared secret. The client side
> is very fast on these operations because its private key is
> small. The client's public point is then sent to the server
> and the server performs a point operation of its own to derive
> the same shared secret.
>
> While the server takes as long as usual, the benefits of this
> strategy (limiting the client private key size) include:
>
> Faster client key setup
> Faster client secret setup
> Weak secret does not weaken server public key
>
> Any thoughts?
The problem is that it makes finding the client's secret easy. An
attacker
will know that the value to search for is smaller than the whole space,
and
they can brute force search for the right secret. Once they have it, it
will
be easy to create the shared secret using the server's public key.
You can compromise and make the client's key 50% clear. Then brute
force is
harder (assuming you're above 160 bits) than a mathematical search. The
client
only has an 80 bit key, but that's still plenty secure since you're over
a 160
bit field. Anything below 64 bits on the client side (independent of
the field
size) makes brute force search possible. Once you get a field size that
makes
brute force infeasable, the attacker still knows the answer will be half
zeros,
but they won't know how to easily find it and will have to do a full
math attack
(which is order 2^80 for 160 bit field size).
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Jayant Shukla)
Subject: Re: DES Hardare - chips/cores
Date: 27 Jan 2000 18:57:06 GMT
[EMAIL PROTECTED] writes:
>I am trying to find standard chip sets/FPGA cores to perform DES-56
>encryption on a OC-3 (155Mbps) ATM cell stream. I also need to do the
>encryption in counter mode. Can you please recommend commercial chip
>sets / FPGA cores that I can use to do DES-56 in counter mode. I am a
>novice to the encryption world.
look up ADSP-2141 by Analog devices. It should be more than
enough for your application.
~Jayant
------------------------------
From: Alan Lawrence <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.research
Subject: Re: Reversibly combining two bytes?
Date: 27 Jan 2000 12:21:16 -0700
Hi -
Thanks for your suggestions - in particular the use of a balanced Latin
square, that is a 256*256 grid where each row and each column contains
each of the numbers 0..255 exactly once. This seems a good solution
provided a good method of generating such squares can be found.
A method suggested was to generate two byte arrays c[0..255] and
r[0..255], both containing all the numbers from 0.255 once, permuted
randomly (and hopefully differently).; then, the <x>th row of the latin
square contains the numbers in c rotated r[x] spaces to the right. How
about this alternative method: instead make the <x>th row contained the
numbers in c, all multiplied (modulo 257, a byte of value 0 meaning 256)
by r[x]. A third byte array b[0..255] could be used to rotate the rows as
well if this would increase security. (?)
Secondly, Terry Ritter's glossary <http://www.io.com/~ritter/GLOSSARY.HTM>
states that a balanced Latin Square has "massive internal state". The
"state" is presumably the large table of numbers forming said square,
however this state does not change during operation. Would a dynamic
version not be better? After the cipher byte is selected by key and
plaintext bytes, the square could be altered similarly to a dynamic
substitution cipher: swapping the rows of the table indicated by key and
plaintext, and swapping the columns also.
Is this decryptable (given the key)? In the simplest case, yes, but
imagine the case where a plaintext byte is put through such a square twice
to produce a cipher. When decrypting, we have the cipher text - the output
of the second table - and the first table (i.e. before it was altered). To
produce the second table from the first, we need the plaintext or
intermediate bytes; but to produce either of these, we need the second
table....can anyone see a way round this? (the square may even be used >2
times).
Thanks very much for any ideas
Alan Lawrence
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: How much does it cost to share knowledge?
Date: Thu, 27 Jan 2000 13:10:42 -0600
In article <86psu9$esa$[EMAIL PROTECTED]>, Tom St Denis
<[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Jerry Coffin <[EMAIL PROTECTED]> wrote:
> > In article <86nm43$soe$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> >
> > [ ... ]
> >
> > > Well you must be rolling in the dough. where I come from you don't
> > > spend 300 dollars on a meal.
> >
> > Have you checked on what it costs to rent a banquet hall for a day?
> > One that seats a few hundred people that is?
>
> Why does it have to be the hilton though? H'um? Did you think of that?
>
You forget that prime amongst bureaucratic thinking is to impress people,
unfortunately it seems too often to be with how much they can waste. The
first meeting was at NIST itself, for little or no money. The montra was
that we are trying to be agreeable, just doing our job in as fair a manner
as possible. The second was in Ventura, still low stakes poker. The third
was in Rome, for reasons that don't make too much sense, as if foreigners
want to be part of the process, that is their problem. Now, the ante is
higher still.
> >
> > > Call it whining if you want. BTW isn't AES suppose to be open to
> > > everyone? Not just the rich?
There have got to be lots of venues even in New York City that could show
how frugal and merey functional NIST is trying to be. Remember, if you
are not wealthy, you don't count. This is all the more reason to keep
showing them that you do.
> >
> > Sure. Now keep in mind that if they didn't charge the participants
> to
> > defray the cost that it would be us taxpayers here in the US who'd
> > have to pay instead. Why should my taxes be higher to give a free
> > ride to some Canadian high school kid who openly admits he won't
> > understand most of what's going on anyway?
There could be no cost to defray if done right. Besides, the really
interested crowd is not going to be that big, surely not with the head
tax.
> >
> > In all honesty, I wouldn't mind a bit paying that little bit of extra
> > tax, and I certainly don't mean to attack you, but I think you get
> the
> > general idea...
>
> True. I never said it should be free but 450 bucks to sit in a folding
> chair is a bit rough. I would set my limit at around 200 bucks (about
> 137 us).
Bet the chairs will still give you a backache.
>
> Why not host it in Canada then? The govt here loves chucking money at
> non-citizen sponsored ideas. It seems all you need to spend money in
> the canadian govt is 3.12 brain cells. [I speak off the parlimentary
> underground halls, the extra cafts ...etc.. lots of spending on
> politicians]....
In Indiana, you only need three.
>
> That's my opinion, I could be wrong.
>
You are most correct in that loads of places would do it almost free
gratis for the publicity. Come to think of it, that is the *prize* for
winning anyway.
One argument is that NYC allows close monitoring of the event. What's the
matter Freeh, it the Hilton going to let you bug all the rooms? NYC in
genereal, security..not.
--
About injustice, the stronger I get the meaner I feel, or is it the
other way around. Do not respect sacred cows that seek to trample you while preaching
about the good they do.
------------------------------
From: [EMAIL PROTECTED]
Subject: Best Encryption Software?
Date: Thu, 27 Jan 2000 13:54:35 -0600
Can anyone reccomend good encryption software? I need to
transfer data (a database) via an FTP site and need a good encryption
program (and something that will compact it if possible). The data is
very sensitive so I need to feel fairly secure.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Any Reference on Cryptanalysis on RSA ?
Date: Thu, 27 Jan 2000 19:50:56 GMT
In article <86pngs$7s$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Keith A Monahan) wrote:
> Quoting from Bruce Schneier's Applied Cryptography,
>
> Table 7.9
> Symmetric and Public-key Key Lengths
> with Similar Resistances to Brute-Force Attacks
>
> Symmetric Public-key
> Key Length Key Length
>
> 56 bits 384 bits
> 64 bits 512 bits
> 80 bits 768 bits
> 112 bits 1792 bits
> 128 bits 2304 bits
>
> I'm not sure what you mean about legitimate key space vs.
illegitimate,
> but perhaps this helps.
Is this table really in Schneier's book? It is worse than hopeless.
Take for example the entry for 64 bit symmetric. A brute force attack
will take (on average) 2^63 encryptions. For a 512 bit key there are
pi(2^256) ~ 6.5 x 10^74 possible primes to test as a divisor (a brute
force attack is trying the possible divisors)
2^63 and 10^74 are not even close.
So unless Schneier means something strange when he says "brute force",
this table is crazy.
Further, one can lump all "public key" methods together, as
EC and RSA have different security properties.
--
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: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Any Reference on Cryptanalysis on RSA ?
Date: Thu, 27 Jan 2000 19:57:27 GMT
In article <86p785$5ut$[EMAIL PROTECTED]>,
"Ip Ting Pong, Vincent" <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I want to study the relationship of the strength between the key
length of
> RSA and the key length of DES.
Good for you. There is a problem, however. It is generally
impossible. Breaking DES requires time only. Breaking RSA requires
lots of time and MASSIVE space.
If breaking both took 10 hours, but DES required 2KB RAM while RSA took
10 Gbytes, one might say RSA is harder [at the very least one has to
spend more on hardware]. But suppose DES took 10 hours while
RSA took "only" 8 hours but required 1 Tbyte of memory. Which would
you say is harder?
You can't easily compare the two. The dimensions which measure the
difficulty of the two problems are not compatible.
> For example,
> Currently, 1024 bit RSA and 64 bit DES are the de facto strong key
length.
There is no such thing as 64 bit DES.
>
> I want to know if the "legitimate" key space of 1024 bit RSA key is
more or
> less equal to 64 bit key?
The security of RSA has NOTHING to do with the size of the key space
since the best attacks are not brute force. I don't know what you
mean by "legitimate".
--
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: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: ECC & RSA re: patents, copyrights
Date: Thu, 27 Jan 2000 20:01:58 GMT
In article <86pv1n$rls$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Uri Blumenthal <[EMAIL PROTECTED]> wrote:
>
> >Jerry Coffin wrote:
> >> Certicom has a couple of patents on specific
> >> methods of carrying out some of the operations in ECC, but it's
> >> entirely possible to implement ECC without using them.
>
> >1. I don't know for sure, but I heard that Certicom is not the
> > only patent holder wrt. ECC.
>
> >2. Are you *sure* that it is entirely possible to implement
> > ECC without using Certicom patents and still INTEROPERATE
> > with a Certicom implementation?
>
> Am extremely interested in Uri's second question regarding
> interoperability with Certicom's implementation. Can you implement
> ECC without licensing their implementation (legally) and still be
> interoperable?
Yes in general, (you don't HAVE to use an ONB for example; the
representation for the underlying field can differ, yet still yield
the same encryption).
However, if their implementation uses point compression you may not
be able to interoperate without a license, since they hold a patent
on compression.
--
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: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: RSA v. Pohlig-Hellman
Date: Thu, 27 Jan 2000 15:18:23 -0500
Roger Schlafly wrote:
> Anton Stiglic <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > It is recommended that both (p-1) and (q-1) have at least
> > one large prime factor, so as to guard against Pollard's
> > p-1 factoring algorithm. See section 3.2.3 of the Handbook
> > of applied cryptography.
>
> Read a little farther. In section 3.2.7, it tells about the general
> number field sieve. Pollard's p-1 method is nearly always a
> lot slower, and there is no need to worry about it.
Well yes, I agree with you on that point. The subject of
using, or not using, strong primes is still an open question do.
Evidence might tend to prove that strong primes don't give
any added security (because of the argument you gave).
On the other hand, the fact that specific algorithms have
been designed to factor non strong primes, and that they
were efficient for their time, leads to some suspicion (even
do number filed sieve give the same results on rsa modulus
of any type now adays).
So you have Schneier on one hand who wrote that you should
just pick primes of random structure, in case some specific
factoring algorithm is created on some other specific structure,
and then you have the Handbook that says that you might as
well just continue to use strong primes since they don't cost
much to generate and non-strong primes are suspicious.
I happen to think that you should just continue using strong
primes for that last reason, untill someone prooves that you
should not. But that's just my humble opinion :)
Anton
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Strong stream ciphers besides RC4?
Date: Thu, 27 Jan 2000 20:21:07 GMT
On Wed, 26 Jan 2000 12:09:08 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (John Savard) wrote:
>[EMAIL PROTECTED] (Terry Ritter) wrote, in part:
>
>>You can wish and hope all you want, but Algorithm M is still not
>>secure. Sorry.
>
>The attack used in those Cryptologia articles required that the entire
>pseudo-random output from the linear congruential generator be used.
Well, no.
Certainly the first article by Retter (1984) did attack a system with
weak generators. But I argue that the whole point of the
MacLaren-Marsaglia (M-M) combiner was precisely to provide strength
the generators lacked, and M-M failed. The more telling second
article (1985) does not assume weak generators. I suppose the best
thing to do is to just quote some of it:
"The idea of combining multiple pseudo-random number generators in
order to produce a more secure keystream sequence has been proposed in
various forms [fn]. Most of these methods are intended to create
nonlinear sequences by using linear generators, since linear sequences
are easily invertible."
"The MacLaren-Marsaglia algorithm [fn] is a somewhat more complex
method of combining two generators."
"It is the purpose of this paper to show that the algorithm can be
attacked by searching for the key to one of its generators while
ignoring the other."
"The MacLaren-Marsaglia algorithm operates as follows: One
pseudo-random generator is used to produce the values for the final
keystream sequence, but the values are first saved in a table. The
second generator is used to produce pointers into the table."
"The problem for the cryptanalyst in this case is to find the initial
states of the pointer generator and the value generator, given a
reasonable amount of keystream sequence."
"In evaluating the cryptographic usefulness of the MacLaren-Marsaglia
algorithm, it is important to distinguish between the security
provided by the pointer and value generators, and the additional
security provided by the combining algorithm. A previous paper [fn]
described a successful attack against a system which used weak pointer
and value generators. This paper considers strong generators.
Specifically, the pointer and value generators are assumed to generate
sequences which can be broken only by exhaustive search of their
keys."
"The effectiveness of the algorithm in improving the security of the
value and pointer generators can be described in terms of the increase
in times required to search all keys. The most effective combining
algorithm would require searching all combinations of two keys, which
would take a time proportional to the product of the times to search
for individual keys. A weak combining algorithm, on the other hand,
would allow a search for one key independent of the other, so that the
total time required would be proportional to the sum of the individual
search times. In either case, the algorithm might also affect the
amount of time required to test each key. It will be shown in the
following sections that the MacLaren-Marsaglia algorithm is a
relatively weak combining algorithm, because it is generally possible
to search for the key to the value generator independent of the
pointer generator."
>Just use the most significant byte, and a sufficiently large integer
>to make the required arrays impractical (16-bit arithmetic is no good,
>but 128-bit arithmetic works nicely) and such attacks on a simple
>MacLaren-Marsaglia generator fall apart.
One weakness is that the values produced by the M-M table are
constrained in distance within the sequence by the size of the table.
Generators have their own constraints, and it may be possible to show
that a generator of the known form could not produce values with the
known distance relationships. I have zero confidence that that is the
only exploitable weakness.
>Use the XOR of the output of two MacLaren-Marsaglia generators with
>different periods.
>However, since these attacks were shown against a weak version of
>MacLaren-Marsaglia, there's been very little study of that method when
>used properly, so one should perhaps use a better-studied method, if
>that is how one seeks confidence. Except for the slow Blum-Blum-Shub
>method, I can't think of anything offhand.
Note that every M-M system in the literature (that would be 2 systems)
has been shown weak.
Now, it is obvious that things can be added to weak systems to improve
strength. But it is also obvious that simply using M-M does not
produce strength. As a consequence, every use needs a serious
analysis to assure that M-M is not being "improperly used."
>Using, for encryption, the _whole integer_ produced by a linear
>congruential generator, to my mind, is like using a rotor machine that
>enciphers one letter using all five rotors, the next one using only
>the first four rotors, and so on until the fifth letter is enciphered
>using only the first rotor, and *then* steps the rotor mechanism.
>(Remember, the last bit has period 2, the second-last bit has period
>4, and so on.) Which is why I didn't feel that attack really proved
>much about MacLaren-Marsaglia when used properly.
Personally, I find these attacks telling, and suggest that they reveal
fundamental cryptographic weakness in the M-M method. When we find
fundamental weaknesses, we can patch them, and then patch the patches
and so on, or we can just move on.
Further, I doubt the entire range of M-M weakness has so far been
exposed, and so doubt that weakness would be avoided in new systems
just by reviewing the previous attacks.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Mac encryption algorithm?
Date: Thu, 27 Jan 2000 13:27:22 -0600
In article <86pmie$7s$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Keith A Monahan) wrote:
>
> "good encryption algorihm that is easily
> implementable on a mac"
>
> Based on the context, I'm fairly sure he meant "mac" as in shorthand for
> an Apple Macintosh computer.
>
> Your use of the word "mac" was an acronym for a keyed hash function,
> used for message authentication, "Message Authentication Code"
>
This has be an funny thread, since someone made the setup without
realizing it, and someone else jumped to the conclusion I quietly
predicted to myself.
And yes, I can talk even about a MAC on a Mac. Seriously now, and I know
we can be, there are loads of Mac implemented things about. As a language
to result in things Macish, I suggest Future Basic, Original or the New
PPC Native Version from Staz, 1-800-348-2623.
Get interested, and let's talk about some crypto coding that works, scores
of applications done and registered by me, from the sublime to the easy,
fun stuff.
--
About injustice, the stronger I get the meaner I feel, or is it the
other way around. Do not respect sacred cows that seek to trample you while preaching
about the good they do.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: Thu, 27 Jan 2000 20:21:15 GMT
On Thu, 27 Jan 2000 08:53:01 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt [EMAIL PROTECTED]
(Scott Nelson) wrote:
>[...]
>This is sort of what I had in mind:
> ______
>20 Mhrtz | |
>----------D| |Q------
> |74F401|
>1 Mhrtz | |
>---------CP| |
> |______|
>
>The select lines S0, S2, MR, and ground are tied low
>CWE, /P, and VCC are tied high
>
>I'm Ignoring the conversion from crystal to logic levels,
>since it's conceivable that you already have the two circuits
>around. And I'm also assuming the two signals are independent
>(i.e. the 1 Mhrtz signal isn't a divided version of the 20,)
>and that the crystals are physically isolated enough that they
>do not "tune" each other (yet another reason not to use them.)
>
>Since D is gated on the rising edge of CP,
>the "window" is approximately equal to one gate delay.
>5 nano-seconds is pushing it, but within tolerance
>for modern ICs.
I don't think this is what I would call a "window." Jitter may change
the position of an edge by only a tiny amount, but there is *some*
position of the sample before which it will have one value, and after
which it will have another. The effect of the jitter is thus to
change the value of some sample that otherwise would not quite make
that invisible edge.
But no matter how fast the logic may be, we will frequently violate
setup and hold timings in this deliberately asynchronous circuit. In
practice, this will have the effect of skewing what otherwise would be
an ideal 0 / 1 balance, and probably will have much more of an effect
than the jitter. But this will not *be* random, even though it may
*look* random.
>After only 1 million pulses of the CP line, Q will produce
>one reasonably unbiased and unpredictable bit.
>(Assuming that the figure of 1 pico-second of jitter is accurate,
>and I didn't make any mistakes.)
OK, first of all, we note that Q is going to be flopping up and down
quite a bit. This happens even if we assume ideal jitter-free clocks.
That is the natural result of sampling one clock with another. Our
task, then, is to distinguish or detect the rare unexpected
jitter-based sample value from a massive pile of expected ideal sample
values that nevertheless may appear irregular.
The obvious approach is to take the parity of all the samples, which
we can do with another FF. But since this signal also will be
changing frequently, the external sample time becomes critical to
detecting a noise effect, and variations in external sampling times
are likely to have much more of an effect than the detected noise.
This is especially the case when we realize that noise can affect both
edges, and even heavy noise may generally balance out.
I think it would be very difficult to certify such a circuit. There
are so many random-like things going on which are not random that the
presence of fundamentally random effects is obscured. That is not
what we want.
Why are we going through all this? If we want to detect fundamentally
random noise, why don't we just produce some baseband noise and square
it up?
>[more snip]
>>And all this is vastly more than we need if we just want to detect
>>noise.
>>
>Absolutely.
>But there are things like Niko's random number generator,
>so it would be nice to have a quantifiable measure of
>how much (or more precisely, how little) entropy there
>really is in such a thing.
The whole point of understanding how things work is to be able to
predict how they will work in different applications or situations.
"Niko's RNG" is simply not what it is claimed to be. We have a
design, the effect is random-like data, but it is claimed that this
comes from fundamentally random noise. That claim is false. In fact,
the observed effect comes from perhaps unexpected but still quite
deterministic computer operations which are then randomized and
obscured in other deterministic ways. Now, if that is sufficient,
then fine. But if we foolishly believed the original propaganda about
the source being fundamentally random, we might well "turn our back"
on the RNG problem as being absolutely solved and theoretically
secure, and we would be wrong.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Why did SkipJack fail?
Date: Thu, 27 Jan 2000 20:48:50 GMT
Jerry Coffin wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> > True, but what would it be that couldn't be bought more cheaply?
> Oh, let's see: assume some large bank ...
You missed the "bought more cheaply" part. I'm pretty sure
that for less than $200,000,000.00 one could bribe enough bank
officers to accomplish the same effect.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: fido7.crypt,fr.misc.cryptologie
Subject: Simon Sigh Enigm
Date: Thu, 27 Jan 2000 20:35:41 GMT
In the Italian version of the book you have to
decypher 4 texts and find 4 key words.
I have found the first and the second:
OTHELLO
NEUTRON
Can you help me with the others?
Thanx
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: NEC claims New Strongest Crypto Algor
Date: Thu, 27 Jan 2000 15:52:42 -0500
Apparently NEC thinks they've developed the strongest crypto in the
world. In addition, they claimed that they've met and surpassed the AES
standards. The algorithm is backwards compatible with DES and AES as
well. It's a rather interesting read, but I'd like to see some source.
I highly suggest you check it out.
http://www.currents.net/newstoday/00/01/25/news4.html
--
Arthur Dardia Wayne Hills High School [EMAIL PROTECTED]
PGP 6.5.1 Public Key http://www.webspan.net/~ahdiii/ahdiii.asc
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: How much does it cost to share knowledge?
Date: Thu, 27 Jan 2000 20:57:04 GMT
Tom St Denis wrote:
> Math always existed we are just *finding* it.
Very many mathematicians would disagree with you!
> That's why patents must be abolished.
If expensive development costs cannot be recouped by a legal
claim on the process, you can be *sure* that the process is
*not* going to be openly published. The purpose of the patent
system is to ensure publication of new ideas by guaranteeing
that the inventor can be rewarded for his work.
> It's analogous to patenting a new found island because you
> found it first. That's silly.
"Straw men" are always silly. Islands are *claimed* for
possession, not patented. And claiming newly discovered
territory is *not* silly, it is standard historical practice.
I know that schools don't teach much these days, but surely
they must have covered *that*.
> Common we are suppose to be evolving as a society yet we
> cling to some paper with printing on it. that's very primitive.
Taking somebody's property without permission or compensation
is *not* primitive? Where do you get your ideas??
------------------------------
** 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
******************************
