Subject: Re: [ppsp] questions about merkle hash tree mechanism for integrity protection of content between peers

From: Arno Bakker <[email-masked]>
Date: Tue, 6 Nov 2012 08:17:44 +0100

On 05/11/2012 18:41, 邓灵莉/Lingli Deng wrote:
> Hi Arno,
>
> Thank you for the impressive speech and demos this morning.
>

Hi

thanks, but that was my boss, Johan. I was virtually present in the meeting.

> I have a few questions about the security proposals in current peer
> protocol draft:
>
> 1)Swarm ID, be it the roothash of a merkle-tree in video-on-demand cases
> or a public key of the initiator in live cases, is not straightforwardly
> inferred to a joining peer, which means there has to be some way to
> securely and uniquely derived from the common knowledge of a joining
> peer (for instance, a few vague key words to search what the user
> wants). I understand that, the pollution issue concerns not only serving
> as you asked, but also serving as you expected. What do you do in your
> implementation? Or the user just know what to check in the first place?
>

I'm not sure I get what you mean. The swarm ID is the identifier of the 
swarm, so if a peer wants to join a swarm it must know the swarm ID. As 
the PPSPP swarm IDs are self-certifying, a peer is always guaranteed to 
get what he asked for. The assumption is that the peer gets the swarm ID 
from a trusted source, e.g. a webportal that says "This BBC Top Gear 
episode that you want to watch has roothash X".

> 2)For ECS proposal, I doubt the one-to-one encryption negotiation is
> scalable for a peer serving more than one peers at a time. Since you are
> not targeting DRM requirements, revocable group keys may suite your
> needs, while the data can be encrypted once and for all given the group
> membership remains unchanged.
>

Dusan?

CU,
     Arno

---

From: Dusan Gabrijelcic <[email-masked]>
Date: Wed, 7 Nov 2012 18:43:55 +0100

Hi Deng,

>> membership remains unchanged.

I hope I had understood your questions correctly. According to our tests
and evaluations the ECS cryptographic handshake using plain digital
signature (one-to-one encryption negotiation) should scale reasonably well
for expected peers load (number of peers in swam(s), in connection,
regarding churn and taking in account normal peer settings). Ordinary host
should easily handle few hundreds of ECS handshakes per second (measured
through OpenSSL) which should be sufficient even for large number of
concurrently open connections and, lets say, 1% churn per second.

The group key and encrypting the content (not exchanged data in connection
since it is not always the same) once for all would really decrease the
load on peer but it is regarded as highly insecure, except in very
restricted settings. As you mention static group membership, the ECS
protocol doesn't assume any limitations on group membership; peers can join
and leave at will (but according the credentials they posses). And, the
protocol provides in application data communication protection other
security services besides confidentially (encryption) as well. Nowadays
they are standard in most network protocols, for example in IPSec or
TLS/DTLS.

Things can get harsher on heavily loaded ingest points, but here a swarm
initiator has other mechanisms that can be used to mitigate the load, like
auxiliary peers, cryptographic accelerators (quite common in VPN/SSL
settings), cloud seeding, etc.

Hope this answers your questions.

Kind regards, Dusan.
-- 
~~~~~~~~~~
Dusan Gabrijelcic
e-mail: [email-masked]