Re: [cryptography] The next gen P2P secure email solution
On 24/12/13 at 04:20am, grarpamp wrote: Once you know the address (node crypto key), you put it 'To: key', mua hands to spool, p2p daemon reads spool, looks up key in DHT and sends msg off across the transport to the far key (node) when it is reachable. In these months there was a lot of talking about metadata, which SMTP exposes regardless of encryption or authentication. In the design of this p2p system, should metadata's problem kept in consideration or not? IMHO exposing danimoth@cryptolab or my key it's the same, as there is a function between them. I2P and/or Tor adds complexity to avoid such mapping to any non-state-level adversary. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The next gen P2P secure email solution
On 24/12/13 at 04:20am, grarpamp wrote: This thread pertains specifically to the use of P2P/DHT models to replace traditional email as we know it today. There was a former similarly named thread on this that diverged... from the concept and challenge of P2P/DHT handling the transport and lookups... back to more traditional models. This thread does not care about those antique models, please do not take it there. A problem which could rise is the 'incentive' for peers to continuosly providing bandwidth and disk space to store messages. I'm a simple dude, with a mailflow of ~5 email per day. Why I should work for you, with your ~1 mail per day for all your mailing list? Somewhere on this list (or p2p-hackers?) there was a post of mine, regardings an economic incentive between peers, which could be a solution, but as always technical problems arose, like pricing the services and a fair exchange between peers. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] One Time Pad Cryptanalysis
On 02/10/13 at 08:51am, Florian Weimer wrote: There is widespread belief that compressing before encrypting makes cryptanalysis harder, so compression is assumed to be beneficial. Any academic references? Without these, IMHO your sentence is false. Example: http://breachattack.com/ ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] LeastAuthority.com announces PRISM-proof storage service
On 29/08/13 at 11:54pm, zooko wrote: The Least-Authority Filesystem does all of the above. We have some pretty good docs: https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/about.rst http://code.google.com/p/nilestore/wiki/TahoeLAFSBasics https://tahoe-lafs.org/trac/tahoe-lafs/wiki/FAQ I know, and for this point I (IMHO) consider your work as verifiable, without the necessity to take into account the Gödel's theorems (sorry if it wasn't clear from the first post). ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] LeastAuthority.com announces PRISM-proof storage service
On 29/08/13 at 03:09pm, Nikos Fotiou wrote: A suspicious user may wonder, how can he be sure that the service indeed uses the provided source code. IMHO, end-to-end security can be really verifiable--from the user perspective--if it can be attested by examining only the source code of the applications running on the user side. I agree with you and I propose a simply protocol which follows your statement: - encrypt your data with a simmetric cipher and a private and robust key - make an hash of the encrypted data and store it securely (no loss possibile) offline - upload the encrypted data over some service. - download the encrypted data when you need it, check the hash and decrypt with the key used in the first pass. In this (simple) case, what is run server side does not nullify security properties (confidentiality and integrity in this example), provided that what is run user-side is ok. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Potential funding for crypto-related projects
On 30/06/13 at 01:04am, Jacob Appelbaum wrote: Yeah, about that... Have you seen the most recent paper by Egger et al? IMHO that's is unfair. There are many publications on Tor vulnerabilities as well, and this is unavoidable. Are you sure that in the next two months Tor will not be the main actor of a similar publication? You should have pointed us over principles and design, rather than vulnerabilities. By principles, I like i2p more than tor, for its decentralization, and for its focus on providing an anonymous network layer than a exit point to existing internet. But this is completely personal, and each of us as his/her requirements to satisfy. And, by the way, I am aware that the most important bug (which can't be corrected) of any systems is the human who is using it. With respect, danimoth ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Potential funding for crypto-related projects
On 04/07/13 at 04:28pm, Michael Rogers wrote: I think the point is that i2p's decision to use a decentralised directory service led to the vulnerabilities described in the paper. Uhm, I don't consider it a matter of centralization vs decentralization. I think the point is how I2P select peers to communicate with; attacker DoS'd previous high-performance peers, then replace them with nodes under its control, and then do measurements to estimate the victim identity. In the section 5 authors confirm that Tor shares with I2P a number of vulnerabilities (for example, repeated measurements could be made on hidden services). I consider myself a bit stupid, so I could be wrong. You can't separate principles from their practical effects. I agree with you that i2p's principles are great, but that shouldn't stop us from discussing their practical effects (including the bad ones). I don't like the idea that respect == not talking about problems. How are problems with i2p and Tor supposed to get fixed if we don't discuss them? As for personal choice - yes, it's a matter of personal choice whether you prefer i2p's goals or Tor's goals. But whether those systems achieve their goals is not a matter of personal choice - it's a matter of objective fact that should be settled by examining the evidence. I completely agree with you, I only disliked the I2P is flawed, don't use it but instead use Tor which is safe tone used, as we all know that no existing methods or systems are bug-free. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Potential funding for crypto-related projects
On 30/06/13 at 07:32pm, Jacob Appelbaum wrote: I'd love to see a revitalisation of remailer research, focussing on unlinkability (which we know many people would benefit from) rather than sender anonymity (which fewer people need, and which is prone to abuse that discourages people from running mixes). I'd also like to see revitalisation of remailer research. Though anonymity as Tor is designed is specifically about unlinkability. To reduce it to sender anonymity is pretty ... ridiculous. What one does with an anonymous communications channel is up to them - many people do actually want that feature for chatting, web browsing, news, email, etc. Not directly related to remailer, but what about dc nets [1] ? [1] The Dining Cryptographers Problem: Unconditional Sender and Recipient Untraceability (David Chaum) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Keyspace: client-side encryption for key/value stores
On 21/03/13 at 03:07am, Jeffrey Walton wrote: Linux has not warmed up to the fact that userland needs help in storing secrets from the OS. http://standards.freedesktop.org/secret-service/ but maybe I have misunderstood your statement. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Key escrow 2012
Il giorno sab, 31/03/2012 alle 13.03 +1000, James A. Donald ha scritto: On 2012-03-31 1:51 AM, Nico Williams wrote: We don't encrypt e-mail for other reasons, namely because key management for e-mail is hard. Key management is hard because it involves a third party, which third party is also the major security hole. PGP web of trust doesn't address it? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
