Cryptography-Digest Digest #546, Volume #10 Thu, 11 Nov 99 15:13:02 EST
Contents:
Re: Can the SETI@home client be protected? (Richard Herring)
SAFER+ Sample Data ("thomas.howley")
Re: NOVA Program (AIfred E Neuman)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Steve McGrew)
For all lions --- (Markku J. Saarelainen)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Coen Visser)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Richard Herring)
Re: Re: Re: How protect HDisk against Customs when entering Great Britain (CoyoteRed)
RC4 in Kremlin US version 2.21 can be cracked !! ("Alexander PUKALL")
Ultimate Crypto Protection? (BigJim44)
RC4 in Kremlin 2.21 can be cracked 2 ("Alexander PUKALL")
Re: Ultimate Crypto Protection? (Sundial Services)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Lincoln Yeoh)
Re: Compression: A ? for David Scott (Tim Tyler)
Re: Sarah Flannery (the story and the paper!) (Quisquater)
Re: What sort of noise should encrypted stuff look like? (Lincoln Yeoh)
Re: Can the SETI@home client be protected? (Paul Crowley)
Re: Can the SETI@home client be protected? (Paul Crowley)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Subject: Re: Can the SETI@home client be protected?
Date: 11 Nov 1999 14:18:26 GMT
Reply-To: [EMAIL PROTECTED]
In article <809hn0$[EMAIL PROTECTED]>, Guy Macon ([EMAIL PROTECTED])
wrote:
> Interesting ideas! Does it help to know that the server knows the IP
> address (so it can send work units)
Not much: people connecting via a dialup ISP may well have a different
IP address for every transaction. Conversely, different users
connecting from behind a corporate firewall may appear to be at the
same IP address.
> and the email address (so it can
> credit the right person)?
Trivially forged. The server could check that the domain name of
the address corresponds to the IP address, but there are plenty
of legitimate reasons why it might not match.
> Right now those are both created upon
> installation of legit or hacked versions. Right now I can download the
> client and install it on multiple PCs. Maybe SETI should make the
> software so that it only installs from the SETI@home server,
Not easy. Web-based installation usually consists of two steps:
(a) download a program, (b) run it. There's nothing to prevent
a hacker from replacing step (a) by copying the program from elsewhere.
And "installation" merely copies a set of files into certain
locations and sets some entries in a database. There's nothing to
stop the hacker imitating those operations.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: "thomas.howley" <[EMAIL PROTECTED]>
Subject: SAFER+ Sample Data
Date: Thu, 11 Nov 1999 14:45:59 +0000
Hi,
I am looking for sample data to test an implementation of the SAFER+
algorithm using a 128 bit key. As well as the final result of the
encryption, I would like to be able to see the results of each of the
eight rounds of encryption executed for the 128 bit key.
Thanks for your help,
Tom Howley.
------------------------------
From: [EMAIL PROTECTED] (AIfred E Neuman)
Subject: Re: NOVA Program
Date: 11 Nov 1999 15:00:46 GMT
>It was exceptionally interesting to see the interview with the radioman
>of the U-150. They seemed to want to be sure you understood, and HE
>certainly wanted you to understand, that he did not abandon his duty
>when ordered by his captain to "abandon the papers and get out."
I agree with that. I almost felt sorry for that guy, seemed kinda like he felt
like the onus of defeat was completely upon him.
------------------------------
From: [EMAIL PROTECTED] (Steve McGrew)
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Thu, 11 Nov 1999 15:19:03 GMT
This debate is reminiscent of debates over my favorite problem, which
is:
"How can we construct the best algorithmic model of the
contents of a black box, given that the black box accepts inputs and
returns outputs, but that we have no other access to its contents?"
It appears that there is no way at all to determine with
certainty whether or not the box contains a deterministic algorithm, a
deterministic algorithm that uses a TRNG, nothing but a TRNG.
We should, though, be able to estimate the likelihood that the
box contains one or another of these, especially if we are given the
additional knowledge that the box contains only N bits of memory and M
logic gates. However, I don't know of any procedure that is available
to make the estimation.
The way this relates to the TRNG vs RNG debate, and to the
random string vs string generator debate, is that it highlights the
fact that the output of an RNG, "T" or not, *is* a single string, even
if the string is formed by concatenating a series of substrings. It
suggests that the only practical difference between a TRNG and an RNG
is that an RNG with the ability to perfectly emulate a TRNG would need
to have either an infinite memory capacity or an infinite number of
logic gates. On the other hand, an RNG of very modest size (say, a
memory of a few kilobytes) would still have enough capacity that it
could emulate a TRNG perfectly for all practical purposes, and could
produce an output string that, over the lifetime of the universe,
would not give us any reason to suspect that it is an RNG instead of a
TRNG.
However: if for some reason we wanted a TRNG, quantum
mechanical systems like radioactively decaying atoms appear to fit the
bill. The trick is to make sure that equipment used to measure the
QMSs output doesn't run the random output through a nonrandom filter,
biasing the randomness of the results.
Steve
Steve
------------------------------
From: Markku J. Saarelainen <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.nsa,alt.math,alt.security
Subject: For all lions ---
Date: Thu, 11 Nov 1999 15:10:24 GMT
For all lions ...
"Encryption and many cryptography technologies are very important for
any future electronic commerce applications and implementations. It is
the recommendation to decline the acceptance of any Wassenaar Agreement
(http://www.wassenaar.org) terms on encryption controls and to support
the strongest cryptography in all commercial Internet communications
globally. The role of the Internet is already critical in most
international enterprises and corporations. However, due to the open
infrastructure and individuals' principal lack of the security knowledge
and consciousness, quite often critical business messages are sent
without any encryption protection, which makes corporations extremely
vulnerable. It is a common public knowledge that some specific
intelligence agencies are using the Internet and other intelligence
collection methods to acquire and collect specific technology and
business intelligence for specific commercial and business enterprises.
Some of most popular encryption applications have backdoors and their
development projects have been supported and influenced by certain
specific intelligence-interest groups. In the future's electronic
commerce environment these encryption methods and technologies shall
become even more important for any corporation anywhere around the world
and it is highly recommended to avoid using any of the most popular
and/or free encryption applications for any business and commercial
purposes."
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Coen Visser <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Thu, 11 Nov 1999 15:48:05 +0000
Patrick Juola wrote:
> >If you want to define it that way. But this leads to a useless
> >definition -> A TRNG produces strings that are "unpredictable"
> >(we can not use the word random anymore, it is reserved for
> >the generators and not the strings). So we have no other means to
> >qualify the strings other than to say that they are produced by
> >a TRNG and therefore are "unpredictable". But we have no means to
> >qualify the TRNG (is it really truely random?) because we can not
> >talk about the degree of randomness of the strings it produces
> >(that was not allowed).
> That's because talking about the individual strings is meaningless
> in a statistical sense. Given a string, you can't tell anything about
I agree that the bickering about randomness of strings of size 1
is a waste of time or at best purely academic. But there is a *lot*
of (statistical) information in a random string of size ~ 2E1024 whether
you look at it as a single string or as 2E512 strings of size 2E512.
> the process by which the string was generated or the alternate
> strings that *might* have been generated but weren't. It's rather
> like trying to describe a football game on the basis of a single
> frame from the telecast, but without the rest of the telecast.
> Or of trying to determine if a roulette wheel is biased by watching
> a single play.
Those two examples are equivalent to the size 1 string case.
Btw I think it is very usefull to investigate the process by
which a string is generated in order to say something about
the degree of randomness/quality of the producer. You should
use all information that you can get your hands on.
> We can talk meaningfully about the *distribution* of strings, which
> may or may not be a random distribution. But a single element
> is almost never "random," even in a non-cryptographic context.
Almost all finite strings are highly incompressible (that is easy
to prove) and have therefore a high degree of randomness.
Randomness itself is just not proveable of an individual string.
Regards,
Coen Visser
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: 11 Nov 1999 16:40:19 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Douglas A. Gwyn ([EMAIL PROTECTED]) wrote:
> "james d. hunter" wrote:
> > That's one criterion that's used for a pseudo-random sequence.
> > "Scientists" call them pseudo-random sequences for the same
> > reason that they call some forces, "pseudo" forces. They are
> > just basically clueless, clueless, clueless about the universe.
> and
> > But, the statistical tests for randomness are subject to the
> > whims of the statistitians.
> He's wrong on both counts.
He's some sort of engineer with a scientist complex.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (CoyoteRed)
Subject: Re: Re: Re: How protect HDisk against Customs when entering Great Britain
Date: Thu, 11 Nov 1999 16:46:32 GMT
Reply-To: this news group unless otherwise instructed!
On Thu, 11 Nov 1999 01:24:17 GMT, JD <[EMAIL PROTECTED]> wrote:
>
>Read the licenses that you agreed to when you purchased or downloaded
>any of these software products. For example, in the "about:license"
>URL of Netscape Navigator, section 10 reads, in part:
Yeah, but who reads all those licenses and stuff. When I'm installing
something I just go "yeah, yeah, let's get on will it." If it didn't
all say the same thing and take you 15 minutes to read the /same
thing/ everytime (and only occasionally they throw something else in
there.)
I don't think I've read any licensing agreements for years other than
those of these free homepage websites.
Besides, if you are not taking it out of the country for resale then
it's not for export. (Of course, not by the strictest of definitions,
but export generally means to take out of a country to sale in other
country.)
So, you can just say, "Hey, I'm not exporting, I'm using."
--
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
------------------------------
From: "Alexander PUKALL" <[EMAIL PROTECTED]>
Subject: RC4 in Kremlin US version 2.21 can be cracked !!
Date: Thu, 11 Nov 1999 17:54:53 +0100
RC4 with CBC encryption mode not selected ( RC4 is not a block cipher ) is
like a VIGENERE cipher, even RC4-128 bits or more
I encrypted a file containing same byte 'A' with the key 'sanke-oil?' and
options :
RC4 encryption (selected)
Compress source code before encryption (not selected)
CBC encryption mode for block algorithms (not selected)
Not selected because RC4 is a stream cipher and used not CBC
The output was :
2425:0250 4B 2A 2A 6B 3C 29 C2 62-4B 2A 2A 6B 3C 29 C2 62
K**k<).bK**k<).b
2425:0260 4B 2A 2A 6B 3C 29 C2 62-4B 2A 2A 6B 3C 29 C2 62
K**k<).bK**k<).b
2425:0270 4B 2A 2A 6B 3C 29 C2 62-4B 2A 2A 6B 3C 29 C2 62
K**k<).bK**k<).b
6B 3C 29 C2 62-4B
Then RC4 is only used to produce 8 random bytes and theses bytes are XOR
with the plaintext : There is NO SECURITY
It's like a VIGENERE cipher.
Second example with same options, same password in kremlin text, with a text
'AAAAAAAAAAAA ....
=====BEGIN KREMLIN TEXT 2.21 MESSAGE=====
-&!!!1H!!3J7!$IC$O9W)'O7`#KXR^)<^(QQ/S%L3QEG(>UR!VM"W4=X##(&\/'+"47`>:
E#9-<S/[`OK?1E"<0\^1JZ4W[&VNDO?0)91W(Q644!N*)?/L:4"9C*PQ8ZZ`"+=ZA)N'7F
.-P&E<%4.JU.>9/L1\KZ4R0_J+K@3-OJ>S;V[$L5))N85`Q=1KIIB#S83:L^'842L*B3-H
:N-\'Z8^VQ.%*2])5@$RC0[?*QH4AK,.\Z4=-=ZNE6=,D+.80`:JI'-*B"@6F(H?B<`;5C
<D+>G@\+6/$L$09_ZOVDP14/1@T=H9%RN4<?"0MP-Z5U7].*H\?'?<6'TG0`#\'WA>:`^O
M\(MP\*,="S(NB!X4`0/3&`7$X6R!75G4)XM/I#'S<78G8`?4'-L^PUBS*?4-;L^U]BS?F
4-LL^UBSS?47-L^PUBS*?4-;L^U]BS?F4-LL^UBSS?47-L^PUBS*?4-;L^U]BS?F4-LL^U
BSS?47-L^PUBS*?4-;L^U]BS?F4-LL^UBSS?47-L^PUBS*?4-;L^U]BS?F4-LL^UBSS?47
-L^PUBS*?4-;L^U]BS?F4-LL^UBSS?47-L^PUBS*?4-;L^U]BS?F4-LL^UBSS?47-L^PUB
S*?4-;L^U]BS?F4-LL^UBSS?47-L^PUBS*?4-;L^U]BS?F4-LL^UBSS?47-L^PUBS*?4-;
L^U]BS?F4-LL^UBSS?47-L^PUBS*?4-;L^U]BS?F4-LL^UBSS?47-L^PUBS*?4-;L^U]BS
?F4-LL^UBSS?47-L^PUBS*?4-;L^U]BS?F4-LL^UBSS?47-L^PUBS*?4-;L^U]BS?F4-LL
^UBSS?47-L^PUBS*?4-;L^U]BS?F4-LL^UBSS?47-L^PUBS*?4-;L^U]BS?F4-LL^UBSS?
47-L^PUBS*?4-;L^U]BS?F4-LL^UBSS?47-L^PUBS*?4-;L^U]BS?F4-LL^UBSS?47-L^P
UBS*?4-;L^U]BS?F4-LL^UBSS?47-L^PUBS*?4-;L^U]BS?F4-LL^UBSS?47-L^PUBS*?4
-;L^U]BS?F4-LL^UBSS?47-L^PUBS*?4-;L^U]BS?F4-LL^UBSS?47-L^PUBS*?4-;L^U]
BS?F4-LL^UBSS?47-L^PUBS*?4-;L^U]BS?F4-LL^UBSS?47-L^PUBS*?4-;L^U]BS?F4-
LL^UBSS?47-L^PUBS*?4-;L^U]BS?F4-LL^UBSS?47-L^PUBS*?4-;L^U]BS?F4-LL^UBS
S?47-L^PUBS*?4-;L^U]BS?F4-LL^UBSS?47-L^PUBS*?4-;L^U]BS?F4-LL^UBSS?47-L
^PUBS*?4-;L^U]BS?F4-LL^UBSS?47-L^PUBS*?4-;L^U]BS?F4-LL^UBSS?47-L^PUBS*
?4-;L^U]BS?F4-LL^UBSS?47-L^PUBS*?4-;L^U]BS?F4-LL^UBSS?47-L^PUBS*?4-;L^
U]BS?F4-LL^UBSSYO8O5R((<5`)UF4[5Z=BI#L61@[S_5Y2$K2J?XLRP=I$&W(QII%S;I+
'[<I
=====END KREMLIN TEXT 2.21 MESSAGE=====
With CBC encryption mode for block algorithms (selected) the bug is not
present.
But why ??? are the 8 random bytes used in some dark new CBC mode for a
stream cipher ???
Alexander PUKALL
November 11, 1999
------------------------------
From: [EMAIL PROTECTED] (BigJim44)
Subject: Ultimate Crypto Protection?
Date: 11 Nov 1999 17:06:23 GMT
I'm just a rookie at this. It would appear that if I encipher a message using
one of the better crypto programs out there and then take that enciphered
message and encipher it a second time using an entirely different program (one
that employs a different algorithm) I would have a system that would be very
difficult to crack. It would envolve a lot of work though.
I have a friend who tells me that the Russian military used double enciphered
OTP all through the cold war and that NSA, with all it's expertise and computer
hardware never had much success breaking it.
Is double encipherment really all that effective?
Thanx...
- Jimbo
------------------------------
From: "Alexander PUKALL" <[EMAIL PROTECTED]>
Subject: RC4 in Kremlin 2.21 can be cracked 2
Date: Thu, 11 Nov 1999 18:00:23 +0100
Kremlin 2.21 can be found at :
http://www.mach5.com/download/krem221.exe
------------------------------
Date: Thu, 11 Nov 1999 10:37:43 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Ultimate Crypto Protection?
Adam Durana wrote:
> > I have a friend who tells me that the Russian military used double
> enciphered
> > OTP all through the cold war and that NSA, with all it's expertise and
> computer
> > hardware never had much success breaking it.
> >
> > Is double encipherment really all that effective?
>
> No one has ever broken an OTP. Double OTP just seems like an overkill. A
> single OTP provides perfect security.
Not if one of their spies is at the bottom of the Danube and the enemy
stole a copy of his pad before shooting him. A system involving two OTP
streams would be resistant to either one of them being stolen, and would
further introduce the question of how the streams were combined; the
random nature of OTP streams offering no clues.
Spy organizations think like that.
========================================================================
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:[EMAIL PROTECTED] (PGP public key available.)
> Got Paradox/Delphi database headaches? ChimneySweep{tm} can help, FAST!
> http://www.sundialservices.com/cs3web.htm
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Thu, 11 Nov 1999 17:36:04 GMT
Reply-To: [EMAIL PROTECTED]
On 9 Nov 99 14:40:12 GMT, [EMAIL PROTECTED] () wrote:
>Douglas A. Gwyn ([EMAIL PROTECTED]) wrote:
>: "Steven B. Harris" wrote:
>: > No kidding?
>
>: Not only "no kidding", but the original hex-digit-only algorithm
>: has been augmented by further work and now we can produce any
>: arbitrary decimal digit of pi. It shouldn't take long to locate
>: more info via a Web search.
>
>Now _that's_ news.
Not really. In fact a reference was posted here in sci.crypt in 1998 by
Paul Rubin see message-id <[EMAIL PROTECTED]>. I found it
interesting and saved it back then.
I found certain sections of this thread mentioning using Pi as a random
number rather amusing.
Sure you can pick ANY digit in the stream, and yes so far the Pi stream
appears to be infinite.
But:
1) You are ALWAYS using the same stream. The stream is well known and can
be recreated up to the nth digit.
2) Where do you start, and how do you specify where to start? You could use
huge offsets. But then how do you decide those offsets?
3) You end up having to pick a REAL random number to decide the offsets.
e.g. offset=random num x max used length x big safety margin.
And if the attacker knows your offset algorithm, the randomness will end up
being determined by the REAL(TM) random number anyway. Doh.
4) you need more CPU power to find the nth digit.
No need for fancy math terminology, it doesn't look good to me. Why waste
time trying to generating unknowns from knowns? Might as well start with
blatant unknowns.
I figure just grab a whole bunch of random stuff from some noisy source:
white noise TV/radio set or something. So what if it doesn't look 100%
random to the statisticians, and the entropy may not be even 90%. If you
use it in crypto the statisticians will be hard pressed to figure that out.
Coz it's unknown, and definitely more unknown than Pi.
If I flip 2^256 coins to generate a random number so what if 2^32 coins are
slightly biased? Not as if attackers would know which ones are biased and
how they are biased. And do you think they will be lucky enough to get
enough samples to determine the bias? And there's still the other 224 bits
mocking em.
Here we go again: about "what's random". IMO, for crypto purposes random is
just what the attacker can't predict or know.
Cheerio,
Link.
p.s. You could still use Pi as a PRBS, where seeds = very random and huge
offsets. But that would be a lot slower eh? Why bother?
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Compression: A ? for David Scott
Reply-To: [EMAIL PROTECTED]
Date: Thu, 11 Nov 1999 17:43:18 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Okay, here is my take on "one-on-one" compression:
[snip why compress]
: However, one should already not be using a cryptosystem that is
: appreciably susceptible to such an attack.
Alas, nobody knows which cyphers have been broken.
Consequently, adding security might well be worth it.
: That explains why there hasn't been a lot of professional interest
: in the idea.
...while the fact that implementations of one-on-one compression algorithms
have only just become available has nothing to do with it...?
: Any practical encryption algorithm that might be cryptanalyzed
: by some means better than brute-force key search would be more
: resistant to cryptanalysis if the plaintext were compressed
: before encryption, so long as the compression does not
: *concentrate* its added information (e.g. in a header).
You think the /only/ way an analyst can make use of this information
is if it is "concentrated" in a header!?!?
Known-plaintext which is distributed evenly throughout a file is /still/
an avenue for analysts.
Methinks you underestimate your opponents ;-/
: You might as well use "one-on-one" compression, but it has
: no special advantage over some other schemes in this context.
Aw, cobblers! ;-)
You appear to neglect the issues associated with the possibility
of attacks based on systematically added information.
Chopping "headers" from existing compression formats is one of the
"other available schemes in this context". You think this is sufficient?
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Mackerel; salmon; plaice; tuna; haddock; cod.
------------------------------
From: Quisquater <[EMAIL PROTECTED]>
Subject: Re: Sarah Flannery (the story and the paper!)
Date: Thu, 11 Nov 1999 19:05:45 +0100
Do you remember Sarah Flannery and her new cryptoalgorithm?
(complete version)
Here are some links:
http://jya.com/flannery.htm
http://www.intel.com/pressroom/archive/backgrnd/co51198a.HTM
(including Gordon Moore and George Bush!)
http://www.girlscientist.org/links.html
See also comp.risks 20.16 (15 J. 99)
Subject: 16-yr-old Irish girl's crypto system
With comments by "Peter G. Neumann" <[EMAIL PROTECTED]>
(Wed, 13 Jan 1999 08:20:21 -0800 PST)
The story continues:
http://www.esat.ie/youngscientists/new/students/eu.htm
http://www.cordis.lu/improving/src/hp_ys.htm
http://europa.eu.int/comm/dg12/press/1999/pr2509en.html
http://europa.eu.int/comm/dg12/press/1999/pr2509en_ann.pdf
And the paper
http://cryptome.org/flannery-cp.htm
thanks to John Young.
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Subject: Re: What sort of noise should encrypted stuff look like?
Date: Thu, 11 Nov 1999 17:59:19 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 9 Nov 1999 19:04:55 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>Lincoln Yeoh wrote:
>> If that is the case if I try to decrypt stuff and fail,
>> should the result still be "white noise"?
>
>Not necessarily. For example, a system with precompression
>before encryption might take a random ciphertext (with wrong
>key) and decrypt it to garbage that has approximately normal
>plaintext statistics.
Would this be likely to happen? Say I precompress something (say LZ or
huffman) and then encrypt it with DES. If I decrypt it with a wrong key,
what are the chances of the result not being white noise?
How about if I don't precompress it. Just as unlikely/likely?
Should there really be a difference if the cipher is strong?
Shouldn't it be unlikely to get normal plaintext statistics with a strong
cipher?
Cheerio,
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Can the SETI@home client be protected?
Date: 11 Nov 1999 08:30:40 -0000
Justin <[EMAIL PROTECTED]> writes:
> > If this is a concern, issue a unique key to each client which they
> >must sign their results with.
>
> I'm pretty sure there's not enough processing power on the seti@home
> servers to verify signatures on every result that comes in.
I suspect you might be wrong there, but if CPU time is a concern,
negotiate a shared secret with each client and then use a MAC - that
would be hugely faster.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Can the SETI@home client be protected?
Date: 11 Nov 1999 08:28:18 -0000
[EMAIL PROTECTED] (David Wagner) writes:
> > I've thought about this one a little, and it seems like it might be
> > difficult to meet both this condition and the obvious requirement that
> > the extra burden of generating the transcript be small compared to the
> > main computational load. However, if the condition can be met, I
> > don't see why the server needs to explicitly challenge the client for
> > the transcript: since it's deterministic, the server can simply
> > generate the transcript itself and see if it matches.
> Two reasons:
> 1. You only want to probabilistically check a small fraction of
> the transcripts, otherwise the server has to duplicate all of
> the work anyway, and we might as well ignore the clients.
> [2]. Transcripts may be lengthy, and if we're only going to check
> a small fraction of them, we'd like to avoid wasting bandwidth
> on transcripts we won't check. The `commitment + probabilistic
> challenge' technique gives us this for free.
I agree with your points; I just don't understand why transcripts need
to be transmitted *at all*. You've sent me 1000 hashes of transcripts
for work that you've done; I pick 10 of the work blocks at random,
repeat the work, generate the transcripts, hash them and check that
the hashes match, and we're done. No transcripts cross the wire -
only hashes.
Now if checking a transcript is cheaper than generating one, then it's
worth asking them to send them to me. For example, if the transcript
is a list of keys such that the output ciphertext and the target
ciphertext match in the first 32 bits...
Incidentally, the only opponent we've considered is the one wishing to
boost their rankings by pretending to do work they haven't done. A
second opponent will be harder to detect: one who wishes to bias our
final result by misreporting the output only of particular, rare
workunits, such as those that contain key matches or signs of alien
life.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
** 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
******************************
