Home › Blogs › fungus_b's blog

Distribution of signed code...

Sun, 2006-06-11 09:27 — fungus_b

Arguing the nuances of your favourite programming language is fine, but a MUCH bigger problem is code distribution.

Unless every single scrap of code is signed and verified then spammers will be able to inject malware into the system. The slightest bug or flaw could gring down the entire system or even convert all the users into spammers(!)

What mechanisms are in place to avoid this? How do you propose to securely get the initial "bootstrap" program onto users machines?

Asking users to verify the signature of a downloaded program isn't enough because:

a) A spammer can buy up misspelled/lookalike certificates and many users will be fooled by them.

b) A spammer can copy your entire *process* with copycat programs. How will the average user know that "Black Frog=good" and "Yellow Frog=bad" if both programs come with similar instructions for download, checking file signatures, installation, etc.? A spammer could even start sending out spam promoting Pink Frog and users will end up with the idea that "Colored Frogs=bad". How do you combat this?

Next, who does the signing? You can't give the keys to more than a handful of trusted people. How do you stop spammers from attacking those people (electronically, physically, or otherwise)?

Comments

Tue, 2006-08-01 14:00 — morphius

How to eliminate this problem

I think you should take a look at the discussion on the forums and the wiki. It addresses all of the above issues.

-------
"I thought about building you a boat to survive the river of tears I'm crying for you, but the world's smallest violins just aren't a reliable source of lumber, and that cross you're nailing yourself to seems bouyant enough anyways" - Dr Gregory House, M.

Wed, 2006-08-02 05:27 — fungus_b

Issues

morphius wrote:
I think you should take a look at the discussion on the forums and the wiki. It addresses all of the above issues.

I haven't looked recently.... but when I wrote that all the posts seemed to be Java vs. C++ vs. Perl vs. "...."

All of the above have solutions, obviously, but the design needs to be very careful - you're basically building a botnet and you don't want its power to end up in the wrong hands.

Tue, 2006-07-18 09:21 — oli32de

Different problems - different solutions

(I'm German, sorry for my English ...)

I see three major problems and maybe also solutions here ...

1. Find a way that the main (initial) source code is ok and not infected my "bad" program segments with backdoors etc.
--> imho this can be done with trusted "core" programmers checking the coding of other code segments (double check) from other programmers to avoid backdoors, traps or other malware.

2. Distribution of the Frognet-Executable using good established sources like computer magazines (CDs) and their download areas, official Okopipi page and avoid downloads from suspicios private sites.
--> imho people trust more official sites, sites they already know and their friends. And once the first programs are out and running people will spread the word (and code) to their friends but only if they are convinced. In the last few years I installed so many times anti-virus, ad-aware, spybot etc. on my friends machine and they're still using and spreading it (and were shocked, what sort of software they had before those programs did their work).

3. Secure the frog's network so no "special ham version" or other malware can attach to it and spread it's own code on innocent targets.
--> no idea here, strong encryption may help but is definitely not the key for success here. If I see, how many versions of emules, edonkeys and specialized versions are available it looks like that this a point to think a lot of. Imho there should be a seamless network with homogeneous clients that can't be faked (but how ?).

Well we'll see ...
Oliver

Wed, 2006-06-28 00:25 — drdrott

Well... I don't think this

Well... I don't think this will be easy on a P2P structure. And I don't know how Okopipi will work, but...

Why not implement a md5hash verifier in Okopipi, to automatically validate the code?

Wed, 2006-06-28 01:38 — fungus_b

Yes, but first...

drdrott wrote:
Why not implement a md5hash verifier in Okopipi, to automatically validate the code?

First you have to be sure that "Okopipi" (the thing doing the md5hash) can be trusted.

Mon, 2006-06-26 14:26 — m1t0s1s

strong cryptography.

strong cryptography.

Tue, 2006-06-27 04:47 — fungus_b

strong cryptography

m1t0s1s wrote:
strong cryptography.

Care to elaborate?

The problem with cryptography isn't its "strength", it's the implementation. You can have the strongest crypto in the world but if your key distribution is flawed or the users type "123456" as a password then it's not much good.

Black Frog's cryptographic problem is to ensure that every piece code running on the Black Frog network can be trusted.

How do you propose to solve this problem for the average Wintel PC/user?

Thu, 2006-08-03 09:35 — Rxke

password calculator

fungus_b wrote:

How do you propose to solve this problem for the average Wintel PC/user?

Password calculator: upon entering a password, calculate its robustness on the fly, and if it is below a certain treshold, you simply have to use a stronger one?