All,

I've read the guff and I know it's a bit early to get right into putting
ciphers in place, but I want to raise something here.  You may have
discussed this already (apologies if so), but here it is...

There's a cryptanalysis of the Rijndael algorithm at
http://www.counterpane.com/rijndael.html.  I haven't got into detail, but
it looks a little worrying.

This brings me to... The issue of what ciphers to use.  Has anyone given
thought to the idea of allowing nodes to negotiate what ciphers they want
in the same way as TLS (a.k.a SSL) does?

And also... What if a cipher we have deployed gets broken in future?

This thought led me on a bizarre tangent...  In TLS, if a commonly used
cipher is broken, then every server on the Internet would have to be
upgraded (or at least re-configured).  I think we can do better than that.  
We'd store a file on freenet that was a list of withdrawn ciphers (a bit
like a bad credit card list).  Nodes would periodically check the file,
and stop using any ciphers mentioned in it.

How do we stop this creating a huge denial-of-service attack I hear you
ask?  Well, we could use the idea mentioned in section 9.3 of 'The Paper'
("Use of digital signatures to allow updating of information"), whereby a
certificate is associated with a certain key, and nodes will only forward
updates that are signed by the real publisher for that key.  
(Incidentally the document says "there is no guarantee that all copies of
the data can be updated in this way" - I think there can be:  When the
file is published in the first place, it could be given an expiry date.  
Nodes will delete the file once its expiry date is passed.  Perhaps all
documents on Freenet could have optional expiry dates.  We could even make
the specification of an expiry date mandatory to reduce namespace clutter
or lack of foresight by publishers.  Lots to think about here.)

I hear you ask something else:  If the cipher revocation list is signed by
someone, then doesn't that constitute centralized control of Freenet?

I think this can also be avoided:  Perhaps Freenet could have a list of
administrators who are all authenticated by certificates.  An initial
group of administrators could have their keys embedded in the software
(just like root CA certificates embedded in browsers).  Ideally the number
of administrators would be very large.  A mechanism could even be
concocted to allow the addition of new administrators (this could be
tricky).  Whenever a decision has to be made, the administrators are
called upon to vote.  The results of a vote are broadcast in the form of a
file on Freenet, signed by those who voted in favour (all sorts of
algorithmic possibilities here).  Administrators would be 'pinged'
periodically to make sure they haven't burnt all their computers and gone
to live on a mountaintop.  'Dead' administrators could otherwise collect
up, and it would be impossible to reach a majority.

Obviously this mechanism is applicable to all sorts of other things, like
security holes discovered in certain implementations.  (The way this issue
is handled on the Internet generally is not satisfactory.)  It could even
be used to bring in changes in the protocol by allowing an old protocol to
be 'phased out'.  This latter idea is probably too easily misused, but I'm
just exploring the idea.  But - Surely we can't make this thing completely
un-upgradeable?

The idea is that rapid decisions can be made that affect the whole
network, but they are made in a democratic fashion.  I hope you can at
least see the need for a cipher revocation mechanism of some kind.  
Ultimately freenet node administrators will mostly be home users with a
little client they downloaded that lets them get MP3s ("Hey, this is
cool!").  If someone said "security alert!  Calling all freenet users -
you HAVE to replace your clients", nobody actually would bother unless
Freenet stopped working.  And, once it's out there, it certainly won't be
under OUR control any more!

Another way to put this:  We have to look VERY VERY FAR into the future
when we design this thing.  Your thoughts, ...

(I'm sure there's something I don't understand in all this, being very new
to it, so please correct me.  And of *course* I don't know whether this is
actually feasible:)


Steve


_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev

Reply via email to