[cryptography] The next gen P2P secure email solution

[rysiek]

OHAI,

Dnia czwartek, 15 maja 2014 16:39:51 Cathal Garvey pisze:
> >>>>> Little proprietary walled gardens are absolutely not the answer
> >>>>> for this problem.
> >>> 
> >>> How could we make a secure solution that plays nicely with the
> >>> current tools without disturbing too much what is already
> >>> established?
> >> 
> >> By writing a gateway (i.e. between RetroShare and e-mail)?
> > 
> > The gateway idea is interesting, but it has to be efficient enough
> > and low cost enough for people to switch over. Something like
> > bitmessage is not.
> 
> I actually think, having used it for some time and liking it on the
> whole, that Retroshare isn't suited to this.
> 
> The primary reason is RS only receives mail if the sender and recipient
> are online at the same time. There's no store-and-forward, even though
> all messages are PGP encrypted to recipients.

Wouldn't that be possible to change? For example by creating store-and-forward 
servers that would not be *required* for RS operation, but would add this as 
an added feature?

> RS also has a lot of feature-bloat; it's better thought of as P2P
> Facebook than a simple communication system.

That is very true.

> Finally, RS is engineered to a simple and admirable purpose which makes
> it unsuited to email replacement; it's Friend to Friend. That's great in
> its use-case, but I think email should be:
> 
> 1) Rapid and censorship-resilient routing
> 2) Single canonical addresses for each participant, which are
> human-readable.
> 3) Churn-tolerant
> 4) Expensive to send, to deter spam otherwise facilitated by to (1)
> 5) Practical for payloads between 10M and 20M, no greater.
> 
> I do *not* think the core of a replacement email should guarantee
> anonymity, but the protocol should make allowances for that if possible.

It should at least guarantee pseudonymity, IMHO.

> I think the above could be satisfied using a pseudo-blockchain for
> name->key mappings, and a key-routed DHT for creating routes for mail
> delivery. Credit is earned by routing other people's mail in
> store-and-forward fashion, like email. Credit can be spent to
> register new mail address:key mappings and to pay for routing of larger
> messages, or to prolong retention of messages before they bounce (if
> your intended recipient does not run a high-uptime mailserver and may
> need a day or two to log in).

Interesting.

> That resembles Twister, the coupling of DHT:Blockchain, but may be
> better suited to the model than twister is (because twister hit problems
> with scaling DHT use to many followers, I think),

https://github.com/miguelfreitas/twister-core/issues/24
https://github.com/miguelfreitas/twister-core/issues/165

> because email is slower and stabler than microstatus systems; more amenable
> to P2P-isation, whereas rapid updates coupled with mass-queries to other
> feeds is a setup better suited to a client:server interaction. The
> blockchain would need tweaking, because Twister is using scrypt, which
> is now apparently ASIC-able, e.g. useless. I think a password encrypting
> function whose parameters are set dynamically by the value of the prior
> block might help fix matters; the goal is for the ideal "ASIC" for the
> function to be a consumer CPU, not a GPU or dedicated ASIC.

Makes sense.

> Anyway, sorry for the wall of text. Killing/replacing email is often on
> my mind.

Yeah, I also have a love-hate relationship with this communication medium.

-- 
Pozdr
rysiek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20140515/6cb51bfd/attachment-0002.sig>