Re: [cryptography] SSL session resumption defective (Re: What project would you finance? [WAS: Potential funding for crypto-related projects])
On Tue, Jul 2, 2013 at 1:52 PM, Ben Laurie b...@links.org wrote: On 2 July 2013 16:07, Adam Back a...@cypherspace.org wrote: On Tue, Jul 02, 2013 at 11:48:02AM +0100, Ben Laurie wrote: On 2 July 2013 11:25, Adam Back a...@cypherspace.org wrote: does it provide forward secrecy (via k' = H(k)?). Resumed [SSL] sessions do not give forward secrecy. Sessions should be expired regularly, therefore. That seems like an SSL protocol bug no? With the existence of forward secret ciphersuites, the session resumption cache mechanism itself MUST exhibit forward secrecy. Well. I've been thinking about this on and off all day, and it seems to me it has difficulties. Let's say we move to your world and I'm a scalable provider of TLS. To present a pessimistic view: when a session is resumed, I have to find that session in my session database, extract k, replace it with H(k) If you don't want compromise of a client or server session cache to compromise old traffic, you'd be better off doing H(k) *before* cacheing the secret. TLS assumes each session_id corresponds to a fixed master secret, and on a resumed connection, the server echos the session_id to signal acceptance of the resumption. So for a forward-secure resumption you'd need to get both parties to agree and get a new session_id, somehow. You could imagine a TLS extension sent by the client to signal support for resumption forward secrecy. If the server echos it, the client caches a forward-secure session. Something like: new_session_id = session_id + 1 new_master_secret = SHA256(master_secret) Not sure this is worth hacking into TLS. But it's worth considering in new protocols (e.g. I think QUIC is considering it). Trevor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Potential funding for crypto-related projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/07/13 13:26, danimoth wrote: Not directly related to remailer, but what about dc nets [1] ? [1] The Dining Cryptographers Problem: Unconditional Sender and Recipient Untraceability (David Chaum) DC nets have two major drawbacks: they don't scale, and any participant can anonymously jam the channel. Dissent is a recent system that aims to address both drawbacks: https://www.usenix.org/conference/osdi12/strong-scalable-anonymity-safetynet Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJR1BmZAAoJEBEET9GfxSfMwvgIAKimVf4ggHuvE0vYLeB4f2gH sUFiZSF+pMY1VCQ8+h32emd4zZoPYOA069y/QAuBbdW1ChJCBcOPsn0trbnZGivW gmJyOd5llb42gDWEMe++G4tYPRvJZ8K7txyrkEqw/W8s/QRxVUOI35258tDitOKB I+NEK53Z0qTOpxhWRyCUgszqXn2zGeGs5h9LY1wbaSCFHpxUqQvKjZDOF49ecjjv M76eoCJ0OAP1b90vTc+TuPvBpxo+hTN5WcMVnBddTpe35Zt5sUIrrLlpSuHjVH8E JuTZwFl278ijaflBhKHtTRweBj1D3/jLXaURWuRY8MW818Q3DebUn78AX4Mu8I8= =0jEp -END PGP SIGNATURE- ___ 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
[cryptography] gnupg-1.1.7, a Python GnuPG wrapper, is released on PyPI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Announcing the release of a more secure Python wrapper for GnuPG on PyPI. About this release - -- This is the first stable release of a module (named 'gnupg' on PyPI)[0], which originated as a fork of python-gnupg.[1] Several problems were found with the upstream version, including a security vulnerability triggered by unvalidated user input, and when used within networked code, can lead to remote arbitrary code execution. Full notes of the audit can be found in the docs/ directory of the git repo [2] and as orgmode→html [3] in the online documentation. The new version [4] is incompatible with the old version, though the changes required to upgrade for software depending on the old version should be slight. Not to mention, the module is now extensively documented,[5] and developed openly. It was downloaded nearly 1000 times on the first day it was uploaded to PyPI. To install: $ [sudo] pip install gnupg References: [0]: https://pypi.python.org/gnupg/ [1]: https://code.google.com/p/python-gnupg/ [2]: https://github.com/isislovecruft/python-gnupg/raw/master/docs/NOTES-python-gnupg-3.1-audit.org [3]: http://pythonhosted.org/gnupg/NOTES-python-gnupg-3.1-audit.html [4]: https://github.com/isislovecruft/python-gnupg/ [5]: https://pythonhosted.org/gnupg/ - -- ♥Ⓐ isis agora lovecruft _ GPG: 4096R/A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt -BEGIN PGP SIGNATURE- iQJuBAEBCgBYBQJR1DpIBYMB4TOASxSAABoAKGlzaXNAcGF0dGVybnNpbnRo ZXZvaWQubmV0MEE2QTU4QTE0QjU5NDZBQkRFMThFMjA3QTNBREI2N0EyQ0RCOEIz NQAKCRCjrbZ6LNuLNafeEACH23ZjAHyx0a42db8AKo9cpHMur5YH0CtICp3h8z80 CAWMyFSOOK87Dpzx7kWhyXcWIu55LBFGnW8iQyeLMnAmgtpEXuGV47lCpcuwMGmU lsyRY0UBcp1j38uiyc0RHbvdZxY18mG4UgX1dmCnO1ehYdGc7kbMgvcmPdNZWErJ pDLtxO1+8BZwoYEr0ngSJ+p26IaOmaAaKG4/iuGQ7ac9P8w5CPr4k4rNme4u/yvO pn29syvCfo6FDcb5j4SOpJWwLbH1mo5xry6KUJflVLHx779q3sDcz3M9wX4pSeOn RISeo5TcXAca6YZLlMbArAsy/dYjW5bINCkTo4S7zY1VsaeN1uAH6NC9T1BqI+e+ 7APD6DD6/qN0Tjv6rT3TZKugFyFtwn98HZxA78kFWZJQbG6SzzgEvfph7pTgm8Tm EavrXex6LQvY6C93yoSoicoBoIZuCXJ7SmkMvf9GJRfDcj9dLM8DVxb0VkclUaKr AaHAFcdjIZ+CZHOukSHmRhrNKNa+FUnAyIrxcfcDU5gsqpOoLgWwWuFrkHICQMyQ PYkMQ0Dh/xhEA5P1tChX1taxOAVJCIWLhQGFaXLWqPM85a+TC2p0GpRga4oKzdUJ ZFB8hBM5T83614iQ8E5FjA6BvryksfVWoe0TW/212C+zeDOXiQl3LdXjnrtfP1cU bQ== =SfHT -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Potential funding for crypto-related projects
On 03/07/2013 13:31, Michael Rogers wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/07/13 13:26, danimoth wrote: Not directly related to remailer, but what about dc nets [1] ? [1] The Dining Cryptographers Problem: Unconditional Sender and Recipient Untraceability (David Chaum) DC nets have two major drawbacks: they don't scale, and any participant can anonymously jam the channel. Dissent is a recent system that aims to address both drawbacks: https://www.usenix.org/conference/osdi12/strong-scalable-anonymity-safetynet is it really feasible to get good latency/bandwith with such system? it seems users need to transmit packets at the same time; so it seems the latency and bandwidth is a bottleneck because everyone must wait for the users with highest latency and lowest bandwidth? Or is there a scheduling mechanism involved (which would eat up usable bandwidth)? Also, how much trust is put on servers compared to Tor? At first sight, it seems that the compromise of one server will compromise all clients connected to this server since servers knows all their shared secret. m no expert so any explanation is very welcome! And forgive if my questions are too basic :) Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJR1BmZAAoJEBEET9GfxSfMwvgIAKimVf4ggHuvE0vYLeB4f2gH sUFiZSF+pMY1VCQ8+h32emd4zZoPYOA069y/QAuBbdW1ChJCBcOPsn0trbnZGivW gmJyOd5llb42gDWEMe++G4tYPRvJZ8K7txyrkEqw/W8s/QRxVUOI35258tDitOKB I+NEK53Z0qTOpxhWRyCUgszqXn2zGeGs5h9LY1wbaSCFHpxUqQvKjZDOF49ecjjv M76eoCJ0OAP1b90vTc+TuPvBpxo+hTN5WcMVnBddTpe35Zt5sUIrrLlpSuHjVH8E JuTZwFl278ijaflBhKHtTRweBj1D3/jLXaURWuRY8MW818Q3DebUn78AX4Mu8I8= =0jEp -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] SSL session resumption defective (Re: What project would you finance? [WAS: Potential funding for crypto-related projects])
On Tue, Jul 2, 2013 at 10:07 AM, Adam Back a...@cypherspace.org wrote: On Tue, Jul 02, 2013 at 11:48:02AM +0100, Ben Laurie wrote: On 2 July 2013 11:25, Adam Back a...@cypherspace.org wrote: does it provide forward secrecy (via k' = H(k)?). Resumed [SSL] sessions do not give forward secrecy. Sessions should be expired regularly, therefore. That seems like an SSL protocol bug no? With the existence of forward secret ciphersuites, the session resumption cache mechanism itself MUST exhibit forward secrecy. The whole point of session resumption is to make that fast. It can't be too fast if it implies public key cryptography. Now, with ECC DH it's probably fast enough anyways, so, yes, we should do this. Do you think anyone would be interested in fixing that? It's already possible to resume then renegotiate with an anon ECC DH cipher suite. Oh, wait, no, anon ECC DH with AES cipher suites were left out (by accident). So the fix might just be to register the missing cipher suites and always renego with one of those immediately after resuming a session. We could then work on a round-trip optimized session resumption with PFS feature. But first we'd have to get users to use cipher suites with PFS. We're not really there. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Potential funding for crypto-related projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Wasabee, I'm no expert either but I'll try to answer to the best of my understanding. I'm CCing Henry Corrigan-Gibbs, one of the Dissent designers, who will hopefully correct my mistakes. :-) On 03/07/13 17:11, Wasabee wrote: is it really feasible to get good latency/bandwith with such system? it seems users need to transmit packets at the same time; so it seems the latency and bandwidth is a bottleneck because everyone must wait for the users with highest latency and lowest bandwidth? Or is there a scheduling mechanism involved (which would eat up usable bandwidth)? Dissent has a scheduling mechanism that allows the members of each DC-net to transmit different amounts of data in each round. I assume each member must send and receive as many bits as all the members want to transmit in total, plus the scheduling overhead, but that could still be a big efficiency gain compared with each member having a fixed-length transmission slot. Also, how much trust is put on servers compared to Tor? At first sight, it seems that the compromise of one server will compromise all clients connected to this server since servers knows all their shared secret. Every client shares a secret with every server, and a client's anonymity is only broken if all the servers collude. So there only needs to be one honest server, and the client doesn't need to know which one it is. It would be interesting to imagine a network where the servers were run by mutually distrusting parties, and every client was satisfied that there was at least one trustworthy server, but different clients trusted different servers. Then clients would be able to communicate anonymously with each other even if they couldn't agree on any server they could all trust. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJR1HZ0AAoJEBEET9GfxSfMxvAIALjs5bIPKwL9uHA+v0ttnVl/ PRMF7+8JnvLZq7QzgdgflnboW4qydYyIO3e7sbJflMJgQuEhlmTt1HASPEIh9CM0 /iu9c5ePw9DKxyl2hnZ7avnzZLl/nVH1QQcrvo3sVL/JYpkYlLdAq8BGQlrVkpMW X1tLxuIXKvtFljF4iG+c6pBZ/jqjs3CdssZQf4AFfF7OKclyR0bS6rScDY+nKU+m LKLaMuwn1CKSoDgsNG1+mdRhE3pr6dpUBixfy+6J55xh/e1lN3KZMVD12aeYNodE JTbngl78mfacZYIqXs9d2692THf3QyycK+mmuIiiRq/mBe0WtCSStEOPBtlMPgk= =RUVT -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Potential funding for crypto-related projects
On 2013-07-04 2:11 AM, Wasabee wrote: On 03/07/2013 13:31, Michael Rogers wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/07/13 13:26, danimoth wrote: Not directly related to remailer, but what about dc nets [1] ? [1] The Dining Cryptographers Problem: Unconditional Sender and Recipient Untraceability (David Chaum) DC nets have two major drawbacks: they don't scale, and any participant can anonymously jam the channel. Dissent is a recent system that aims to address both drawbacks: https://www.usenix.org/conference/osdi12/strong-scalable-anonymity-safetynet is it really feasible to get good latency/bandwith with such system? it seems users need to transmit packets at the same time; so it seems the latency and bandwidth is a bottleneck because everyone must wait for the users with highest latency and lowest bandwidth? Or is there a scheduling mechanism involved (which would eat up usable bandwidth)? Also, how much trust is put on servers compared to Tor? At first sight, it seems that the compromise of one server will compromise all clients connected to this server since servers knows all their shared secret. It suffices that one server is not controlled by your adversary, even if all the others are NSA plants, even if the server you are using is an NSA plant. However, a single evil server can jam the channel, so have to identify and throw out actively disruptive servers. Effectively, the servers form a DC net, and client anonymity is layered on top of that. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] What project would you finance? [WAS: Potential funding for crypto-related projects]
On Tue, Jul 02, 2013 at 12:25:50PM +0200, Adam Back wrote: I think it time to deprecate non-https (and non-forward secret ciphersuites.) Compute power has moved on, session cacheing works, symmetric crypto is cheap. A reasonable use for the $3k the OP is talking about would be to add node-to-node SSL encryption w/o mandatory authentication to Bitcoin actually. I'm pretty sure $3k could hire a developer to implement that - I'd do it msyelf and I think the hourly rate would be reasonable - while Better-Than-Nothing-Security is probably a more expensive project. But if you can get significantly more funds BTNS probably could have more widespread impact. -- 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
