Doesn't I2P fit better, considering the design requirements? Tor would require very significant changes to scale better for high volume traffic, but I2P already handles it reasonably well.
I wonder why I2P is getting so small amount of love. I've read somewhere that for some reason it's popular only in Russia. It has two working email systems, working Bittorrent and much more. Maybe it lacks a native (C or C++) implementation?
Try installing it, search for files and watch download speeds. Onion routing and tunnels cost bandwidth. The crowd that is used to Bittorrent speeds (in combo with VPN safety) is not interested in 2 Kbit/sec speeds. Plus the user interface is hard to understand without having attended crypto courses.
My understanding of tribler is that it is going to use onion style routing and use some internal cryptocurrency to incentivize users to provide bandwidth. They hope that with proper incentives people will provide enough bandwidth to enable speeds that are high enough to stream high def video anonymously. They hope to prevent spam by enabling anonymous wiki editing of torrent channels and voting of torrent quality.
Sure, but that's still the reason it isn't as widely used. And because research resources in the anonymous-networking field are so limited the marginalization of I2P tends to be self-reinforcing.
What do you think of Bote mail in I2P, which uses DHT for relaying mail? It is set to hold mail in the DHT for 100 days or until fetched by the recipient. It also uses public keys as addresses (ECDSA and NTRU are the options), and all mail is encrypted. I2P provides traffic anonymization, and Bote mail supports letting mails be relayed with random delays to further anonymize the sender by removing time correlation.
I would love to see someone give i2p-bote a good analysis. I tried using it a couple of times but wasn't able to ever receive messages successfully. They are advertixing some pretty awesome features though; no content or metadata leakage; it is secure against a global passive adeversary if you use delays between relay hops; parties don't have to be online at the same time to communicate.
I've never had problems with receiving messages with it. Had I2P been running for at least 20 minutes or so to be able to establish enough connections? Bote can tell you how many Bote nodes it is connected to.
5460 satoshis is the current default minimum that Bitcoin itself allows (other transactions are valid, but won't be forwarded, thus you need to hand it over to a miner yourself for inclusion in a block).
Some allow larger keys. I once generated an 8192 bit key. It took a loooong time. Never used it. I guess that piece of software would have allowed 16k keys too.
> If you don't trust Gmail, you shouldn't trust it any less if/when they deploy PGP for it.
The problem here might be that people (including Google, I guess) don't want users to trust anything MORE THAN THEY SHOULD, which is a major risk in a case like this. Sometimes security features can be counterproductive since they can lead to the users making bad assumptions and therefore bad decisions that they otherwise wouldn't have made. PGP in webmail implemented just in JS is likely one of these things that could make things worse due to how users treat them.
I'm actually suggesting that if we're going to trust Gmail completely anyway, we might as trust them to encrypt-and-decrypt everything server side. No need for any fancy PGP in JS. Gmail still gets to read your emails and generate ads (though it might not be able to do offline analytics to your emails). The point is that with PGP-in-Gmail we can at least trust that the email in transit is much more secure, and furthermore we can verify the identity of anyone sending us messages, too.
