The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [OFFTOPIC] RC5 Challenge: We're in the top 15!!

> > that you need some way to authenticate that the client has *really* searched
> > their keyspace.  This is difficult to do without actually getting the client
>
 
> Actually, it's impossible to do that way as well. 

Impossible to do what way? I think I said that the server would have to retest 
everything the client had done, this is of course very possible and totally 
insane ;)

> (The nice thing
> about the MPQS/GNFS large-composite RSA cracks is that you can *check*
> the "factoids" you get from each client on input, and there is no
> "keyspace" there's just critical mass of relationships... but I
> haven't seen any product-cipher crackers that have a property like
> that.)  So you *still* end up having to trust people -- you might as
> well actually *ask* them to take responsibility -- or make it
> unnecessary (by *not* having a directed keyspace, you only get about a
> factor of 2 increase in search time -- see Peter Trei's excellent
> paper on searching for DES keys, the other RSA contest running
> concurrently.)

Yup, valid point except that the word "only" in "only a factor of 2 increase" 
is strictly relative.  If the cypher-text only needs to have a secure life of 
3 months and a non-directed keyspace attack takes 5 months, "only" takes on a 
whole new meaning.

>  If they're not going to trust me with a potentially
> $10K chunk of keyspace, why would I trust them with a lot more than
> $10K worth of my time/business if they *have* any nasty bits in their
> code?  (Alternatively I could set up a no-syscalls trusted environment
> for this code -- which would have the side effect of trapping the
> successful key reports anyway -- but that's more time than it's worth...)
> 

I agree, I probably wouldnt run the code on anything that held info that was 
a) secret/confidential and/or b) not backed up.

The server guys are *probably* trustable, but it would be foolish to trust a) 
the security of their host [trojan clients] b) that they havent inadvertantly 
put holes in the client that someone may reverse engineer.


> Sorry to rant, I just wanted to make sure people didn't make the
> mistake of *believing* the key-space-safety issue :-)
> 								_Mark_


I still think its reasonable not to trust people on this one, based on 
key-space-safety. If your talking about "potentially $10k" (and I personally 
think "potential" loss/gain is somewhat of a bogus notion) its not $10k 
potential that is lost if someone spoofs their keyspace, its the "potential" 
value of everyone elses processor time that needs to be factored in [yes, yes 
this time would normally have been idle but historically that has been ignored 
when making these types of calculations in the past].

Richard Jones.


--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com