Cryptography-Digest Digest #870, Volume #11 Sat, 27 May 00 12:13:01 EDT
Contents:
Re: Another sci.crypt Cipher (tomstd)
Re: list of prime numbers (tomstd)
Attack on SC6a (sci.crypt cipher) (tomstd)
Re: Attack on SC6a (sci.crypt cipher) (tomstd)
Re: The Code Book / Are factor techniques really that secure? (DigiboyCiPHER)
Re: Attack on SC6a (sci.crypt cipher) (tomstd)
Re: HTML encryption (DigiboyCiPHER)
Re: RSA/PK Question (tomstd)
Re: Enigma reflectors (John Savard)
Re: list of prime numbers (DJohn37050)
Re: Attack on SC6a (sci.crypt cipher) ("Scott Fluhrer")
Re: RSA/PK Question ("Trevor L. Jackson, III")
Re: RSA/PK Question ("Trevor L. Jackson, III")
Re: Encryption within newsgroup postings (zapzing)
Re: RSA/PK Question (tomstd)
Re: Retail distributors of DES chips? (zapzing)
----------------------------------------------------------------------------
Subject: Re: Another sci.crypt Cipher
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 27 May 2000 03:47:11 -0700
In article <8gnnmv$dma$[EMAIL PROTECTED]>, matthew_fisher@my-
deja.com wrote:
>In article <[EMAIL PROTECTED]>,
> tomstd <[EMAIL PROTECTED]> wrote:
>> In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
>> (Mark Wooding) wrote:
>....
>
>A nice attack. I had trouble reproducing it, though.
>....
>
>> If I were to implement this on reduce rounds (for the fun of
>> it), would I just take a plaintext (A,B) and (A,B xor
00010000)
>> and look for the output difference of (A xor 00030000, B)
after
>> 3 or 4 rounds? I am not clear on this part.
>>
>> BTWx2 Thanks for the info, I really want to learn from this.
>> BTWx3 I designed this cipher so I could break it. So I am not
>> disappointed it was broken, just that I didn't do it first.
>>
>> Tom
>
>Tom,
>
>Here is even a better attack, I believe. The code is at the
end, make
>sure you reduce the rounds to 6!
>
>The differential is 00 00 00 0c -> 00 00 00 0c 4/256 for box 0.
>
>I noticed that all of the entries in sbox 0 ended in 0,4,8 or
C. I
>though it might be possible to get a truncated differential of
the
>form 00 00 00 xx -> 00 00 00 xx. Sure enough 0x0c does just
that.
I copied your source code onto of my ref source code and
http://www.tomstdenis.com/tc1mf.c
Is the result. I don't see your "trait" for both words even
after 2 rounds. I do see the 0x0000000c in the first word, but
it's gone after 4 rounds...
Maybe I did it wrong?
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: list of prime numbers
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 27 May 2000 03:57:14 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Daniel) wrote:
>On Thu, 25 May 2000 21:50:00 GMT, [EMAIL PROTECTED] (Dan Day)
wrote:
>
>
>>Daniel, what were you hoping to do with the list? If you'll
>>explain your application, we can help you address your problem
>>more directly, since keeping a "list" of primes is likely to
>>be a poor way to get the job done, whatever it is.
>>
>>
>Thanks for all the replies.
>
>I'm trying to understand RSA and want to be able to factor a
given
>'public modulus'. Or try it at least ;-)
>
>If one has a large number (say 150 digits), what are the ways
to try
>and break this up into its factors? Where does one start? I
think
>that there can only be a limited list of possible prime numbers
which
>will actually (when multiplied) come up with the correct public
>modulus. Or am I wrong about this? All information is greatly
>appreciated.
You are right there is a finite number of prime factors of the
modulus. Problem is there is over 2^400 of them for a 300 digit
number. Just trying them all is a bad idea.
There is a lot of wierd math, but if you want to look at it, get
the hand book of applied crypto and read the section on QS.
That's a good starting point I guess.. or maybe fermats method
they are somewhat related in their usage of N^2 - N...
It's all wierd math though...
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: Attack on SC6a (sci.crypt cipher)
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 27 May 2000 04:02:47 -0700
>From his paper:
One round of SC6a is as follows:
in1 = a ^ c
in2 = b ^ d
(out1, out2) = f(in1, in2)
a = a ^ out2
b = b ^ out1
c = c ^ out2
d = d ^ out1
swap (b, c)
--
Well if I can find pairs such that a ^ c = a' ^ c' then I can
run a difference thru his F function, and have a zero out with a
probability of zero. There are 2^16 ways to get this difference
too.
His 'swap(b, c)' won't fix it either because (b, d) have a zero
difference anyways (you change the (a, c) input and keep (b, d)
the same).
So this difference should go thru all rounds with prob=1.
I conclude (if I got it right) his cipher is broken.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: Attack on SC6a (sci.crypt cipher)
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 27 May 2000 04:04:27 -0700
In article <[EMAIL PROTECTED]>, tomstd
<[EMAIL PROTECTED]> wrote:
>From his paper:
>
>One round of SC6a is as follows:
>
>in1 = a ^ c
>in2 = b ^ d
>(out1, out2) = f(in1, in2)
>a = a ^ out2
>b = b ^ out1
>c = c ^ out2
>d = d ^ out1
>swap (b, c)
>--
>
>Well if I can find pairs such that a ^ c = a' ^ c' then I can
>run a difference thru his F function, and have a zero out with a
>probability of zero. There are 2^16 ways to get this difference
>too.
Err. that is 'zero output difference' with prob one. Sorry.
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: DigiboyCiPHER <[EMAIL PROTECTED]>
Subject: Re: The Code Book / Are factor techniques really that secure?
Date: Sat, 27 May 2000 11:22:05 GMT
In article <8gh46o$l9s$[EMAIL PROTECTED]>,
Bob Silverman <[EMAIL PROTECTED]> wrote:
> The Singh book is replete with errors. Many of them. And he does
> not seem to understand the subject.
>
> This should not be surprising. His book about Wile's proof of FLT
> was equally bad.
:) Well from my perspective they were taking maths that I had
previously found to be pretty useless and making it interesting -
putting faces and stories behind the maths. Less technical perhaps but
more interesting than some of the books I've had to read.
> > Surely there are speedier ways to factorise large numbers than going
> > through _every_ possibility.
>
> Of course there are.
> See:
>
> H. Riesel Prime Numbers and Computer Methods for Factorization
> Birkhauser
Thanks for the suggestion. I'll see if I can get my hands on a copy.
> > Enough of that! :) My point being that it is probably wrong to
> > assume that even humungously larger numbers are unfactorable
> > within a normal
> > time-span...
> You have no basis for making such a statement. Indeed, you yourself
> admit that you know nothing about factoring algorithms.
> And you are grossly wrong. Read Riesel's book.
>
> --
> Bob Silverman
> "You can lead a horse's ass to knowledge, but you can't make him
think"
Yep, I have no experience in factoring algorithms. :) I'll read the
book.
Thanks.
--
======
Marcus
======
www.cybergoth.cjb.net
Techno gothic cyberculture
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: Attack on SC6a (sci.crypt cipher)
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 27 May 2000 04:30:25 -0700
In article <[EMAIL PROTECTED]>, tomstd
<[EMAIL PROTECTED]> wrote:
>From his paper:
>
>One round of SC6a is as follows:
>
>in1 = a ^ c
>in2 = b ^ d
>(out1, out2) = f(in1, in2)
>a = a ^ out2
>b = b ^ out1
>c = c ^ out2
>d = d ^ out1
>swap (b, c)
>--
>
>Well if I can find pairs such that a ^ c = a' ^ c' then I can
>run a difference thru his F function, and have a zero out with a
>probability of zero. There are 2^16 ways to get this difference
>too.
>
>His 'swap(b, c)' won't fix it either because (b, d) have a zero
>difference anyways (you change the (a, c) input and keep (b, d)
>the same).
This doesn't work so nicely in reality. But we can also
cryptanalyze his round function itself.
>t = x * k[i]
>u = y * k[i+1]
This does not follow SAC, nor is it non-linear and it suffers
bad differences for some keys, let's call this 'conditionally'
and 'totally' crypto-broken.
>rotateright(x, u>>27)
>rotateleft(y, t>>27)
Again the "randomness" in rotation depends heavily on the key
value used. For example all keys under 2^24 will not have the
lower eight bits of the input affect the rotation. All keys
under 2^16 the lower 16 bits, etc. There is of course a 2^-10
chance that the rotations don't even occur (rotate of zero) and
the rest of the F function becomes wickedly linear. Thru four
rounds this has a 2^-40 prob of being totally linear. Thru
eight it has a 2^-80 probability. Which means I can break it
faster then brute force by finding a 'good' pair.
>x = ((x >> 11) | (x << 21)) + (x ^ t)
>y = ((y << 13) | (y >> 19)) + (y ^ u)
These steps not so great either. (x ^ t) is guaranteed to be
zero in the lsb, which means the lsb of the output is equal to
bit (11+rotation(u>>27)) of the input. Similarly for 'y'.
>pht(x, y)
Wickedly bad differences... namely (128, 0) -> (0, 0) (I think
that's it)
>x += k[i+2]
>y += k[i+3]
Totally linear.
Main problems with his F function
1. Has bad conditional properties (values of k[0..1])
2. Doesn't follow SAC
3. Some parts are much too linear
etc.
I think the pro's can use this to attack the full cipher.
Taking into account the 'linear' attack I have as well, I really
think this cipher is broken.
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: DigiboyCiPHER <[EMAIL PROTECTED]>
Subject: Re: HTML encryption
Date: Sat, 27 May 2000 11:26:38 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Niklas Frykholm) wrote:
> Encryption is impossible in this case. JavaScript doesn't help.
> Since the page must be decrypted to be viewed in the browser,
> an attacker can simply capture the decrypted data.
Ah, I see...
> The best you can hope to achieve is obscurity. This will probably
> stop some people, but noone who is serious about stealing your
> source.
>
> Example (which will probably not pass a validator but looks OK
> in NS and IE):
>
> <!--- <tiTlE 8scuobscure&#> scure&
> </tITlE>--><tITLe 8scur
 1d p& <!-- >
> An obscured page </TiTlE <!--
> 98scur> <!-- ITLe 8scur
 1&#bscured
> ur&TITLE 8s	 --> <p <!--->Obs<!-- 98s p cur&TITLE 8scur

> 1ded  -->cure</p scur <!-- -->
>
> // Niklas
So I guess from the other replies that this is the only way like I had
previously thought. Thanks. :)
Judging from past experience on the people I'd like it to stop, it
shouldn't need to be far too advanced to work.
--
======
Marcus
======
www.cybergoth.cjb.net
Techno gothic cyberculture
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: RSA/PK Question
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 27 May 2000 05:20:58 -0700
In article <[EMAIL PROTECTED]>, David Blackman
<[EMAIL PROTECTED]> wrote:
>Bob Silverman wrote:
>>
>> In article <[EMAIL PROTECTED]>,
>> Jerry Coffin <[EMAIL PROTECTED]> wrote:
>> > In article <[EMAIL PROTECTED]>,
>> > [EMAIL PROTECTED] says...
>> >
>>
>> > For example, if you want some information to remain secure
for at
>> > least the next 50 years, you'd _better_ not depend on an
RSA key of
>> > 768 bits, even though that's (AFAIK) unbreakable at the
present time.
>> > In 50 years, an average hand-held calculator is likely to
have more
>> > than enough resources to break a 768-bit key.
>>
>> Typical inane sci.crypt technobabble.
>>
>> I will give you a hint: Think about the *power* requirements
to drive
>> a processor that fast. Think about the power needed to
refresh
>> a terabyte of memory.....
>>
>> --
>> 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.
>
>Jerry seems very sure that either Moore's law is going to hold
for
>another 50 years, or a major improvement in algorithms will
happen.
>
>Bob seems very sure that Moore's law will give up before that,
and no
>major improvement in algorithms will happen.
>
>Either way is a brave prediction if you're looking that far.
>
>There's no obvious physical reason why you can't fit a terabyte
and a
>few million MIPS into a handheld and run it off less than a
watt.
>Currently no-one knows how to do this. Guessing whether it will
or will
>not be done in 50 years is just guessing.
>
With current technology we can't do that even if we wanted to.
We would have to use some newer medium say Chemical or DNA etc.
As for the memory, well it grows to fast anyways, so I attacks
for over 1024 bits will most likely occur in a very very long
time.
As for the algorithms, it's entirely possible that a RSA
specific type factoring algorithm be invented, just not very
likely.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Enigma reflectors
Date: Sat, 27 May 2000 14:26:39 GMT
On Sat, 27 May 2000 04:44:15 GMT, "Thomas M. Sommers"
<[EMAIL PROTECTED]> wrote, in part:
>When a new reflector became available, did it completely supercede the
>earlier one, or did the reflector become another part of the key?
>From what I've read, it appears that it did supercede, even though the
opposite happened with the regular rotors. However, that was true only
the first time the reflecting rotor was replaced, before the war.
After that, the reflecting rotor was not changed, for the Army and
Navy at least, except by replacing it by either a rewirable reflecting
rotor, or by replacing it with a set of two rotors. These two thin
rotors could be set to simulate the old reflecting rotor, or to other
settings.
There was more than one set of thin rotors, but I am not sure that the
set used was ever part of the daily rotor order.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: list of prime numbers
Date: 27 May 2000 14:50:46 GMT
Handbook of Applied Cryptography. Most of it is on the web for free.
Don Johnson
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Attack on SC6a (sci.crypt cipher)
Date: Sat, 27 May 2000 07:52:14 -0700
tomstd <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> From his paper:
>
> One round of SC6a is as follows:
>
> in1 = a ^ c
> in2 = b ^ d
> (out1, out2) = f(in1, in2)
> a = a ^ out2
> b = b ^ out1
> c = c ^ out2
> d = d ^ out1
> swap (b, c)
> --
>
> Well if I can find pairs such that a ^ c = a' ^ c' then I can
> run a difference thru his F function, and have a zero out with a
> probability of zero. There are 2^16 ways to get this difference
> too.
>
> His 'swap(b, c)' won't fix it either because (b, d) have a zero
> difference anyways (you change the (a, c) input and keep (b, d)
> the same).
>
> So this difference should go thru all rounds with prob=1.
>
> I conclude (if I got it right) his cipher is broken.
To make this observation work, assume the same differential on all four
words. That is, you start with a differential (x,x,x,x), for some x. Or,
to write it out explicitly:
a^a' = x b^b' = x c^c' = x d^d' = x
Then, if you go through a round, you get an output differential of (x,x,x,x)
with probability 1.
Now, this implies that if
Encrypt( a, b, c, d ) = ( e, f, g, h ),
then for all x:
Encrypt( a^x, b^x, c^x, d^x ) = ( e^x, f^x, g^x, h^x )
Now, this is certainly is a certficational weakness, and if the attacker has
one plaintext-ciphertext pair, this gives him 2**32-1 more "for free". It
is difficult to see how to turn observation into a key-recovery attack.
--
poncho
------------------------------
Date: Sat, 27 May 2000 11:25:30 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: RSA/PK Question
Bob Silverman wrote:
> In article <[EMAIL PROTECTED]>,
> Jerry Coffin <[EMAIL PROTECTED]> wrote:
> > In article <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] says...
> >
>
> > For example, if you want some information to remain secure for at
> > least the next 50 years, you'd _better_ not depend on an RSA key of
> > 768 bits, even though that's (AFAIK) unbreakable at the present time.
> > In 50 years, an average hand-held calculator is likely to have more
> > than enough resources to break a 768-bit key.
>
> Typical inane sci.crypt technobabble.
>
> I will give you a hint: Think about the *power* requirements to drive
> a processor that fast. Think about the power needed to refresh
> a terabyte of memory.....
This _is_ worth thinking about. Remember that in 1900 NYC was supposed to be
covered in horse dung 100' deep by 1950, and everyone in the city was going to
be working as telephone operators by 1930. Remember that IBM projected a
worldwide market for computers of six units (and they were right -- then).
Remember when another RSA spokesperson addressed the strength of their cipher
by saying it would take "40 quadrillion years" and it didn't even last 40
years.
Remember Somebody's Law (Clarke?) to the effect that when an authority in a
field states that something is possible, he's nearly always correct, but when
he states that something is impossible, he's nearly always wrong.
To address the question posed in detail, there is _no_ lower limit on the
amount of energy required to perform a calculation. So the power requirements
are completely irrelevant to the theoretical question of computation rates far
in the future.
As for terrabyte memories, I have it on good authority (cirra 1975) that they
are impossible because the ionization due to radioactive contamination of the
substrate and the carrier will raise the error rate unacceptably high as the
amount of charge in each cell drops below 5e5 electrons per bit. But they
didn't use ECC widely, and didn't have access to low radiation substrates and
carriers then. Remember?
-- Babble on, Bob
------------------------------
Date: Sat, 27 May 2000 11:31:38 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: RSA/PK Question
tomstd wrote:
> As for the algorithms, it's entirely possible that a RSA
> specific type factoring algorithm be invented, just not very
> likely.
Can you give us your calculations as to the likelihood?
As a background observation, it is difficult for a young adult to comprehend the
natural rate of change of technology because they haven't had their nose rubbed
in it as more mature (elderly) adults have. As a benchmark, my grandfather was
born before the proof of power flight (wright bros 190x), and died after we
landed on the moon (1969). Quite a lifetime.
I suspect the rate of change has been increasing, so I'd expect it to be very
likely that an RSA-specific factoring algorithm be invented within Tom's
lifetime.
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Encryption within newsgroup postings
Date: Sat, 27 May 2000 15:18:21 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> Anton Stiglic wrote:
> > Now is that realy english?
>
> Now it is..
>
> Seriously, although the original "ciphertext" was probably
> gibberish and not really enciphered natural-language text,
> one does need to be careful when deciding whether or not a
> putative plaintext sample is consistent with the assumed
> natural language. Although the combination QZYXCB has never
> before been seen in English text, that doesn't mean that the
> best estimate of its probability is zero. (In fact, now it
> *has* occurred in English text! Bother! For the purposes
> of this discussion, choose a similar string that hasn't yet
> appeared.) If one mistakenly attributes probability 0 to
> the event, then its occurrence in putative plaintext causes
> one to decide *with certainty* that it cannot really be
> plaintext, which is overly pessimistic. Somewhere in MilCryp
> (preparation of digraph tables, as I recall) the authors
> assign "one-half of an occurrence" to any combination that
> was not seen in the sample, in a simplistic effort to avoid
> this problem. The question of what the best assignment of
> probability is for an as-yet unseen event is an interesting
> puzzle; around 1940 Alan Turing came up with a method at GCCS
> that was classified for a long time, but eventually appeared
> in writings by I. J. Good; original open publication was an
> article in Biometrika, around 1950 as I recall. (There have
> been recent further developments in this area in the open
> literature, but I don't have references close at hand.)
> If you don't already know a good solution, it may be
> instructive to try to figure one out.
>
Well, I fghle really think that theur
is a proooblem with y'er idea. Dat is dat
wunce the skeem is published, Der's
probablee gunna be a way around it.
Sooo Sorrry .....
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: RSA/PK Question
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 27 May 2000 08:39:00 -0700
In article <[EMAIL PROTECTED]>, "Trevor L. Jackson,
III" <[EMAIL PROTECTED]> wrote:
>
>
>Bob Silverman wrote:
>
>> In article <[EMAIL PROTECTED]>,
>> Jerry Coffin <[EMAIL PROTECTED]> wrote:
>> > In article <[EMAIL PROTECTED]>,
>> > [EMAIL PROTECTED] says...
>> >
>>
>> > For example, if you want some information to remain secure
for at
>> > least the next 50 years, you'd _better_ not depend on an
RSA key of
>> > 768 bits, even though that's (AFAIK) unbreakable at the
present time.
>> > In 50 years, an average hand-held calculator is likely to
have more
>> > than enough resources to break a 768-bit key.
>>
>> Typical inane sci.crypt technobabble.
>>
>> I will give you a hint: Think about the *power* requirements
to drive
>> a processor that fast. Think about the power needed to
refresh
>> a terabyte of memory.....
>
>This _is_ worth thinking about. Remember that in 1900 NYC was
supposed to be
>covered in horse dung 100' deep by 1950, and everyone in the
city was going to
>be working as telephone operators by 1930. Remember that IBM
projected a
>worldwide market for computers of six units (and they were
right -- then).
>
>Remember when another RSA spokesperson addressed the strength
of their cipher
>by saying it would take "40 quadrillion years" and it didn't
even last 40
>years.
I think he was being a bit precautious then.
>Remember Somebody's Law (Clarke?) to the effect that when an
authority in a
>field states that something is possible, he's nearly always
correct, but when
>he states that something is impossible, he's nearly always
wrong.
>
I can't sprout wings, and it's impossible for me to sprout
wings. I would love to be wrong on that one.
>To address the question posed in detail, there is _no_ lower
limit on the
>amount of energy required to perform a calculation. So the
power requirements
>are completely irrelevant to the theoretical question of
computation rates far
>in the future.
There is an *upper* limit. You can't for example run thru an
entire 256 bit counter once, no matter what you do, there is not
enough energy in the universe. So it's possible for example to
use 256 bit symmetric keys and have "provable" security
(assuming the cipher is made of "provable" parts which is
another story).
So if the NFS will take 2^256 steps to factor a n-bit composite,
then it's provably secure, unless a new NFS or Sieve comes
along, which is possible but not very likely.
>As for terrabyte memories, I have it on good authority (cirra
1975) that they
>are impossible because the ionization due to radioactive
contamination of the
>substrate and the carrier will raise the error rate
unacceptably high as the
>amount of charge in each cell drops below 5e5 electrons per
bit. But they
>didn't use ECC widely, and didn't have access to low radiation
substrates and
>carriers then. Remember?
Yea the problem is the memory has to be tightly coupled, so you
can use the memory of a million computers. You need one
computer (with many processors) with a huge amount of ram.
>-- Babble on, Bob
While I do think he is speaking for RSA alot, I would like to
also believe he is a person of science and he knows what he is
doing.
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: zapzing <[EMAIL PROTECTED]>
Subject: Re: Retail distributors of DES chips?
Date: Sat, 27 May 2000 15:35:54 GMT
In article <8gneja$c1l$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Paul Rubin) wrote:
> In article <8gnd50$g6s$[EMAIL PROTECTED]>,
> Paul Rubin <[EMAIL PROTECTED]> wrote:
> >In article <8gn72l$2vq$[EMAIL PROTECTED]>, zapzing
<[EMAIL PROTECTED]> wrote:
> >
> >>Yup. tamper resistance is the point. I can't find your stuff about
> >>"java buttons" but that doesn't mean much since deja has been so
> >>flakey lately.
> >
> >http://www.ibutton.com/java/
>
> Oops. Better URL: http://www.ibutton.com/ibuttons/java.html
>
iButtons sound really cool. I think that this
is the sort of thing that would be needed for
truly secure digital cash (and truly secure
assets cannot, by their very nature, be
anonymous).
But the iButton is useful primarily for
communicating with others and proving who you
are to others (incidentally, I wonder why they
called it a challenge/response protocol
instead of a zero knowledge protocol -
marketing perhaps?).
What I would ultimately want would be secure
communications with *myself* (storage) and
with other *individuals* with whom I have
communicated personally and therefore have
exchanged secret keys. Authentication is of
course not a problem in those instances.
Oh, the heck with it, I'll admit it.
I really just want to make something myself.
The iButtons were cool though and I may end up
using them for stuff like internet purchases.
It sounds much better than a credit card.
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
