Re: [cryptography] The Wandering Music Band
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/01/15 07:03, realcr wrote:
I think the naive solution I proposed in my first message is more
efficient than using Bitcoin, because it does not involve proof of
work or flooding stuff.
Shortly: Whenever a person is added to the band, all the members
sign on the new list. Whenever a member leaves the band, all the
members sign on the new list. The band members keep the signatures
forever, so they can always prove they where formed originally from
the original band S.
I think there might be a problem if a majority of members leave the
band one by one and then construct an alternative history:
band_0 = {a,b,c,d} // original lineup
band_1 = {a,b,c}// d leaves
band_2 = {a,b,c,e} // e joins
band_3 = {a,b,e}// c leaves
band_4 = {a,b,e,f} // f joins
band_5 = {a,e,f}// b leaves
band_6 = {a,e,f,g} // g joins
Now the original members b,c,d create an alternative history:
band_0 = {a,b,c,d} // original lineup
band_1' = {b,c,d} // a leaves
band_2' = {b,c,d,h} // h joins
Which is the true lineup, band_6 or band_2'?
A verifier who's seen both histories can tell that b and c have signed
inconsistent statements. But how can a verifier know whether they've
seen all histories that might exist?
Cheers,
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBCAAGBQJUrnpiAAoJEBEET9GfxSfMEqIIAK8ZHAE4XzAmVYg3A7z2kWJA
mUHNoNMHf7198NLH9ddMrLOmKbGYWRko/6VY6dStx8Na3E0O1nAZVO2vdK9oTlBJ
v6O6mmgAuAnG4oKAn3+KQHhGIxIUmsOn7vHTgF6X6l7JlgEnEhwNQ2GZ5azbyEnb
iSxAjy1cnH4uWV8On8nFrBRfv1BkcizoclX1hBxF9b2v0+psNLbS0/EIFuGkonfx
CYGRC117saH9t//kwEZEAk2b8PeNENb/memS4beBJdQNe0oMaiKV/rxXgf2IwnpX
1AdDopBU84EnICiwuB8lwSqhdlKBO07fJ6Slki/l6Fjie9lUlFU/4+rpSNQnzOE=
=98M3
-END PGP SIGNATURE-
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The Wandering Music Band
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/01/15 13:21, realcr wrote:
Now the original members b,c,d create an alternative history:
I assume that the original band has a majority of correct members.
Therefore at least two out of {b,c,d} are correct, and they will
not create alternate history.
Sorry, I should've read your formulation more carefully. But as
Natanael pointed out, the same problem exists if any version of the
band contains a dishonest majority.
(I don't necessarily agree that Bitcoin in the only answer, but I
can't see another answer.)
Cheers,
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBCAAGBQJUrp15AAoJEBEET9GfxSfME6wH/2AGTz/xH0aRtAMxeWIgu6Ie
xXxt+uL/4JhpZWEnCK+SYXmoKLh9OLJVSVUw2U1mcA1pZdj/KGk1RnLerU+w8D5c
e8FwvrNsVqPMLjwYRtrNXJje9UJlRLti1jlZxchg4Xj6gYWpuS8lJev2bT6He7aj
ylhiBvhzvvdTYzC1iA9yNOpxM4dGHWWXuj/sUUWvPVHEIpG7iQPs9XH/pYOTbLJU
NNzNjYwkObJvGCgo20dHlQ2+Vr7UNLk6O+ZXZvZORfSlEgnKLF7/HUTrTRTxsjnO
7Iy7gFbmHswnWWeaa3DGl9xoJxHpZJoCMNshYdAuEYOykulPyqqw9KOEtgcxxmk=
=Gvzr
-END PGP SIGNATURE-
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Define Privacy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Dan, I always enjoy your writing and the broad scope of thought it reveals, but I think there's more to privacy than a dichotomy between keeping things to ourselves and revealing them to the world. I like David Feldman's conception of privacy, which is based on the observation that individuals live their lives in a number of social spheres, which interlock, and in each of which they have different responsibilities, and have to work with people in relationships of varying degrees of intimacy. Privacy in this sense means managing the various social spheres in which we live, and the sharing of information between them. The core of privacy as a civil liberty, then, is the entitlement to dignity and autonomy within a social circle. The ability to have not just an inner, private self and an outer, public self but many selves, or aspects of self, appropriate to different contexts is indispensable to our understanding of what it means to be a whole person. When Mark Zuckerberg says that people who have one self for their friends and another for their colleagues lack integrity, he's criticising them for possessing exactly the quality we call integrity in public officials - the ability to maintain boundaries between their personal and professional lives, for example by refraining from nepotism. Helen Nissenbaum's view of privacy as contextual integrity likewise recognises that not only is privacy dependent on context, but the definitions of privacy and context are intertwined. Developed by social theorists, [contextual integrity] involves a far more complex domain of social spheres (fields, domains, contexts) than the one that typically grounds privacy theories, namely, the dichotomous spheres of public and private. I wonder if you've chosen the dichotomous view because you believe that there's no longer a meaningful distinction between revealing something to a circle of intimate friends and revealing it to all of humanity. But even if that is, or soon will be, the case, that reality can be challenged, both normatively and operationally. In order to do so we must first acknowledge that there's territory between the poles of private and public that's worth fighting for. Cheers, Michael http://clp.oxfordjournals.org/content/47/Part_2/41.full.pdf http://venturebeat.com/2010/05/13/zuckerberg-privacy/ https://crypto.stanford.edu/portia/papers/RevnissenbaumDTP31.pdf On 23/10/14 17:52, d...@geer.org wrote: Sir, This is a question for which hard answers seem difficult. Nevertheless, below are a few paragraphs from my current book draft. The draft does not now include Ayn Rand's pronouncement that Civilization is the progress toward a society of privacy. The savage's whole existence is public, ruled by the laws of his tribe. Civilization is the process of setting man free from men. In any case, I concur with you that it would indeed be prudent to nail down an answer to your question well before science allows us to read the mind externally and without reserve. --dan -8cut-here8- There are two ways to define privacy, and neither involves the squishiness that begins a reasonable expectation of... The first is what privacy means as a civil construct -- what Brandeis described[1] as [T]he right to be left alone -- the most comprehensive of rights, and the right most valued by civilized men. The second is what privacy means at its operational core: the effective capacity to misrepresent yourself with de minimus side effects. As to the first, privacy is something that society, meaning you, give the individual, meaning me. When privacy will not be given and is thus not available, secrecy is something I can take for myself -- secrecy is a functional backstop for the absence of the civil construct. If privacy is a gift and secrecy is a taking, then the possibility of privacy is inversely proportional to the numbers of those who must do that giving for the state of privacy to prevail, hence privacy is inversely proportional to interconnectedness. This is consistent with a view of risk as proportional to dependency where dependency, in turn, is proportional to non-optional interconnectedness. This is where the all-wired world's information wants to be free is most robustly anti-privacy. As to the second, Privacy is the power to selectively reveal oneself to the world.[2] which means that in choosing what to reveal, however idiosyncratically we choose, we demonstrate our liberty. As if that were not enough, Philosophical and legal analysis has identified privacy as a precondition for the development of a coherent self.[3] which asks the question of whether a person whose life experience has been one without privacy can even comprehend the desire of those who prefer privacy. As a matter of prediction, raising the young to not expect privacy foreordains
Re: [cryptography] Silent Circle Takes on Phones, Skype, Telecoms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/07/14 11:27, James A. Donald wrote: On 2014-07-11 07:45, Kevin wrote: On 7/10/2014 4:39 PM, John Young wrote: https://blog.silentcircle.com/why-are-we-competing-with-phone-makers-skype-and-telecom-carriers-all-in-the-same-week/ With silent circle, when Ann talks to Bob, does Ann get Bob's public key from silent circle, and Bob get Ann's public key from silent circle. For phone calls they use ZRTP, so Ann and Bob can verbally compare short authentication strings after the key exchange to detect a MITM, *if* they know each other's voices and their voices can't be faked. ZRTP carries keying material forward from one session to another so it isn't necessary to do this every time. For messaging it's the same, except the verbal confirmation happens out-of-band. The protocol spec seems to have been taken offline recently, but it's archived here: https://web.archive.org/web/20140125121552/https://silentcircle.com/static/download/SCIMP%20paper.pdf Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJTv8ORAAoJEBEET9GfxSfMZmoH/1ip9AmkhY+bVLtgpgYTOjrp SRSgFIzaeGocGnMyBz1cgcxOaDOSNOATc8IpbhSVvmJue1VD43VlCv6Fvdwe0pid nOBX/ZMY35hlil9Kte/STcDQDt6E3AYiaFlIXXVyU7y/35K2J6629fixPJc5yPVB rHy1ew0HqvQFWfiztYK/fxptuWu81UAh9HIL3A9j1/N0eX1EpaKBgUFWRTzD/4Id XSckanVjQ34JTJNuC0UbLXY7sz8ljSeFI3dGQQEFliODYNhy5eWn7JkL9oOj26AM KcSdAp85KF6f7rRE36QC5NroS9iiDWzgcXLOy/cHgmH3uODWOA70vy1GxjYbhxQ= =uakY -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Stealthy Dopant-Level Hardware Trojans
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22/06/14 09:46, coderman wrote: On Fri, Sep 13, 2013 at 2:49 AM, Eugen Leitl eu...@leitl.org wrote: ... http://people.umass.edu/gbecker/BeckerChes13.pdf Stealthy Dopant-Level Hardware Trojans ? Georg T. Becker1 this paper has disappeared from the net. any one have copies? (looking at you, JYA ;) http://www.emsec.rub.de/research/publications/Hardware-Trojans/ [bonus points for backstory on the distribution woes] PhD students suck at maintaining their web pages. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJTpqUmAAoJEBEET9GfxSfMUz8H/3lqO7I1/4nfe006ebV2IIvO hsyntYGUri3/42WfeeBfLf3yCwC7bYtgQLOwL5FWM2Y61crBaPYp9BM2HO5o1z/1 E7UH0c+deFtp87jHUaPL4dRxNoLJITm1eAqt4GTJlcgQyy86TWBjbbL0HiwvwdB0 0QWHNJ383sW3b/iZVMIR8Wbpyc/jol0jdcokXiREronT/7L9rw+HW5/eJiVQW0KK p0b+TPC8MLB/RFLuLNuBYd7ETqrEljGPLMDXYUhCvd5y+0TSTHeWHXS7bAURBlH0 WJzmRWjBtRATT2ARo52ykyLzSiaMaaZxxBXzawkVSVVtmGSxhg8ylM+H1L2xC3Y= =9aAl -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [p2p-hackers] The next gen P2P secure email solution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/06/14 19:30, grarpamp wrote: It would be nice to check some numbers on this for the list. Is there a wiki or paper repository that discusses plausibly reachable DHT sizes, time needed for DHT ops to resolve, and management schemes for such clusters/hiers/roles? A couple of old papers: http://sahara.cs.berkeley.edu/jan2004-retreat/slides/bamboo-tr.pdf http://www.iptps.org/papers-2004/li-churn.pdf The first paper finds that a 1000-node DHT under heavy churn has a 900 byte/second bandwidth overhead, which grows logarithmically with the number of nodes. The second paper compares the performance of various DHT designs under churn. A more recent paper finds that there are 15-27 million nodes in the mainline DHT: http://www.cs.helsinki.fi/u/lxwang/publications/P2P2013_13.pdf Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJTi3kaAAoJEBEET9GfxSfMMzcIALOtwQ4ahKVqz1wQLyefZioL dlUhobjhtUUIls02K4b2u+hZxgIEQDIHVKr4LYRwRqgGDOcFmNuIiyAXFhd9OjON C8SCvLa7eiL24jxoYJKjriPskmlvnZEHL35nmsGSyHLV0SBRpSn39+HN2VzIrVDt 3GRkt/2kVwmcUMhxYFGRxqWAHJORryQiHfyVR5iNxN4e+kvT1RL+LZ0xZyhFzT26 vjyYNAXGteZyI95EyE3BRFVaRVRzlJcSnrE8eI7HF165C8Yl2wBHCv6KD6yuVIId SXOHmQE06hgiGPzyKgzhTSq17YSlD82NBxTYhlBzvpjOKL+HHwN8Zo86FjDPB6s= =N8xp -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [p2p-hackers] The next gen P2P secure email solution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/06/14 20:54, pira...@gmail.com wrote: There is no way to hide metadata because you need a destination for your messages to arrive ... has to find its destinations to deliver its contents. Yes of course... the minimum necessary for delivery is the destination address. Is this absolutelly necesary to be on clear? Can't it be possible to be broadcasted and forwarded to all the peers in the network, or it would be a no sense? It's possible, but it wouldn't scale well. There are some routing protocols for ad hoc wireless networks that take that approach: A. Boukerche, K. El-Khatib, L. Xu, and L. Korba. SDAR: A secure distributed anonymous routing protocol for wireless and mobile ad hoc networks. In Proceedings of the 29th Annual IEEE International Conference on Local Computer Networks (LCN 2004), Tampa, FL, USA, pages 618–624, November 2004. R. Song, L. Korba, and G. Yee. AnonDSR: Efficient anonymous dynamic source routing for mobile ad-hoc networks. In Proceedings of the ACM Workshop on Security of Ad Hoc and Sensor Networks (SASN 2005), Alexandria, VA, USA, pages 32–42, November 2005. B. Zhu, Z. Wan, M.S. Kankanhalli, F. Bao, and R.H. Deng. Anonymous secure routing in mobile ad-hoc networks. In Proceedings of the 29th Annual IEEE International Conference on Local Computer Networks (LCN 2004), Tampa, FL, USA, pages 102–108, November 2004. S. Seys and B. Preneel. ARM: Anonymous routing protocol for mobile ad hoc networks. In Proceedings of the 20th International Conference on Advanced Information Networking and Applications (AINA 2006), Vienna, Austria, pages 133–137, April 2006. http://www.cosic.esat.kuleuven.be/publications/article-636.pdf Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJTi5RLAAoJEBEET9GfxSfMIZEH/0wZ31OjI092QJsoqgz7tKe8 4SX0nXsewpK050CELG5pIHNfibX+TkxOSkkZh3ZxnKxqdadhhP/wFrNej2gwmF8v ULF6QMfPuFHT8KCI205hdw3hsqHU1HIpC7grde7yF2dQHXBQwFog08kY4RlPEPz4 MoLOF0SSC1nZuJZ/Q5XfQo0iOXZ1SF6AMgM+m25bPhYGjzPUWMXaonZh2G7VSMj3 VGdfxPnj4i/6Ximbofmf2+ppm7yFEiOh0aDbrnz9bCryGvcSda3GSp+NKMpOEuRN eZ1TzMBhcVOWxxKLMp7IO7LkLOj7JOTgashipGTauDJGtGpoz4ExF6udfSnk3PY= =QtiP -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Is it time for a revolution to replace TLS?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28/05/14 10:54, Mansour Moufid wrote: On Fri, 2014-04-25 at 09:28 -0700, Tony Arcieri wrote: There's an entire class of memory safety bugs which are possible in C but not possible in Rust. These also happen to be the class of bugs that lead to Heartbleed-like secret leakage or remote code execution vulnerabilities. It seems we've come to the programming version of the possibilism versus revolution or nothing debate. In politics anyway, the latter attitude leads to nothing rather than revolution. I don't think anyone's suggesting that we should rewrite all existing software in Rust (the equivalent of revolution). But it's quite possible to stop writing new software in C. Then we just have to wait 50 or 100 years for most of the existing C code to fall out of use, and we'll have a somewhat improved security landscape. Hooray! I need a drink. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJThblAAAoJEBEET9GfxSfMFzQH/06mPEaJFB+uVftwD4XWHVRy 5pU71JlEJMLIM5d8qF6oczyT4wMOpzankOanDSGGbQnznT+jji/nn5OM4O1Asgbm 7JQovsbNmTENHBXw2Jgk7sxU0+lNaR3ejJH2MyrsLIhrPjayFp8PBXpplWzaHQTL pE2Y1TV5erJwGPL9zHEiH3eF5xB4egW03ZX9t5THCkzOBBoDYYLiYgcTutaV4nNU sQQCPwNOcVhEWDMH65ooVQg1XtsblAySMWy08/kfWerdcf4xQW3rWRKUR1EGHrL/ Qvj1X7GLM6NcIU6xXQ5pEfsaf1itN4yx3IedXupmfx7md3YRzVzgu00kKwgKCOM= =J8dv -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] NSA Said to Exploit Heartbleed Bug for Intelligence for Years
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/04/14 23:51, ianG wrote: 2. Score another 1 up for interpreted languages that handle array allocation cleanly. This is more or less a buffer overflow, in a wider sense. Not just interpreted languages - a modern compiled language such as D or Go would also have caught this. I'm curious - does anyone on this list still use C or C++ for new projects? If so, what's the advantage that outweighs the enormous, repeatedly demonstrated disadvantage of memory handling bugs? 4. This should put to rest any silly claims that the NSA put the bug into play themselves. The programmer and the reviewer missed it. I don't see how a claim that the NSA exploited the bug is evidence that the NSA didn't plant the bug. (Not that I believe they did - but this isn't evidence that they didn't.) Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJTSUvjAAoJEBEET9GfxSfMG9cH/Ak2acQG13WyP5HwOzWsTr7u T2sX8rtKpy51jPb6OWZudrq6CpqBm3ofsMTIkxYXu5vX/Roz/5Q+G+btikWO34NT Gz5Fl6iz1yF68TT23VtG79PNhl5zwDmZvpeESyOkb0tXOFSuK/Wu139nIOFCMJkg S4fvbDEuLteYSNOiAWjxDP9Xa4vT8kAvVxME8UaQIcMYFF0dbiTaIujto99WOBv0 JfoprZbfhd/Xw05iJWwsbF0NInfN4nRWnIvqEKxjQOhziLrDRZlepKhA0z9sE3Bi d+sRytwoF3pqDgouLARwKjBfsBWgjaS+uMLHQ4Gg7/i/HbRVntcwXGBtY78PCd8= =sftN -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Extended Random is extended to whom, exactly?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 31/03/14 18:36, ianG wrote: END of snippets, mostly to try and figure out what this protocol is before casting judgement. Anyone got an idea? http://tools.ietf.org/html/draft-rescorla-tls-extended-random-02 The United States Department of Defense has requested a TLS mode which allows the use of longer public randomness values for use with high security level cipher suites like those specified in Suite B [I-D.rescorla-tls-suiteb]. The rationale for this as stated by DoD is that the public randomness for each side should be at least twice as long as the security level for cryptographic parity, which makes the 224 bits of randomness provided by the current TLS random values insufficient. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJTOaq0AAoJEBEET9GfxSfMv0UIAKyO/ofWH5Z70wunv679ijM4 N/mZT8oeVGrAgsCBtGvzuzQg8iWpo5PmNju3HbIv8MF4jsB8AfEE7q9rk0yNjo0c zewfKD2mDJMPFUkUDIZ92WYvvfQH1CgO8defiTpSKMMNbHAsndTqOCIV17ohpmnJ iX4inZSqart4GxFi0JyU7R8F87HmuX1fhgEVBCheYnX44R4+vrv/Fv27sEF6eghw dCRY6z/q6jbOhPdM3QH2bC9KXvGrs2DqSrmNuw8WMKUBiJNXxBWpo13FpGX0+DLk 962o7JGxtWbrsZt95BPrTPNp7rEhpaQyOm8l/n2p8QYhp9YKB/VdScVUISuBBA8= =/HP6 -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] SafeCurves evaluation of secp256k1 - side channels
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/01/14 14:26, Krisztián Pintér wrote: Ondrej Mikle (at Saturday, January 11, 2014, 11:19:30 PM): a) Ladders Does this mean that an implementation of secp256k1 is likely to have timing side-channel attacks? likely might be a strong word. for some curves, an implementor must choose between a safe and a fast and simple implementation. [...] b) Completeness Like in ladders case, this implies that a timing branch/cache side channel is likely in an actual implementation due to the need to check for special cases? yep, but i would question the use of likely again. unlucky curves lead to an implementation nightmare, which will, no doubt, be trimmed down every now and again, especially because it doesn't affect normal operations, and speeds things up. Hi Krisztián, Thanks for this explanation. If I'm stuck with an 'unlucky' curve for reasons of compatibility, can you give me any advice about checking the implementation for the problems you mention, either by inspecting the code or through test cases? It seems to me that some of the problems listed on safecurves.cr.yp.to could be caught by tests - for example special cases in the addition formulas. Other problems could be caught by looking at the source code - - for example we could check that the implementation uses the Brier-Joye ladder and checks that points are on the curve. But maybe there are other problems that are harder to catch? It would be useful to know which curves, if any, can be made safe through the right implementation choices, and which are unsavable. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJS08poAAoJEBEET9GfxSfM0YMH/R1jOf7UcPTS89TWxTKMHtN6 DJQ0e24sfxt0IAn66HhYjmcAISaolsCRBnIVApmpWyPKv6HEmRHaKUF7VMrolylr pu/FKfpjdUGrekk+pDBLiZz7Ufg0ssBt/tPn/XXBwWSQZ5RKN5rl7JO9PXhqVqKy qwvZykerdKqNghlGKwHNlqiPn9Lh2M3876meYqlbtS1dCYO1H4r22cDMZQ3KOtuP Fkyf28KGKJ2ipl30iENaco/qS3pBqqfmFnT7CyfbAyr3oVVmodky9QSfynNlFPK6 ytlUuE4bRnRw42v9SMu+Q3QsEBjo1CeCSlhcafQn0Srz/eHBP4HHOYpMtdA9UvM= =Jjx7 -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Allergy for client certificates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/10/13 09:29, Guido Witmond wrote: It looks like you've worked around the UX issues by inserting an EC-aware proxy between the client and server. Who would be responsible for deploying such proxies? That proxy lives in the end user's computers. Right now, the user needs to install the proxy. I hope to get time and funding to make it a Firefox plug in. I hope that when it proofs useful browsers will adopt it. I hope you manage to persuade browsers to support it, because it seems like it will be difficult to get sites to adopt EA until their users can reliably expect it to be supported on every machine they use. (Sorry for referring to EA as EC in my last email!) My family and friends outside the tech community are quite casual about logging into their accounts from friends' machines, work machines, internet cafes, etc. It's all very well for us to say that's a bad idea, but we can't deny it's convenient to be able to log in from anywhere with nothing but a password. I can definitely see the benefits of EA for users who have a few personal devices that are synced and not shared with other users, and who value the security of using their own devices more than the convenience of being able to log in from anywhere. That describes me, but it doesn't describe most of the people I know. Perhaps you could think of a killer app for EA that appeals to people whose habits match the way EA works? Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSVu4GAAoJEBEET9GfxSfM/cgH/0fGNb+hIWcv/lgk9fZNbcTv 7f3M3GYhowM8IDO3CkOYCU7E0M0hAuhG9jYTAVPGFrEBYc3i9PgNAV+bfv+20qlT 50VlaGFgePWAzZ1lI4334KSNloNiLwxqC3aR1gUhzJGpxnwl4yOOj0/4MGqF64xo j3OocXPHB10j8qTL4l+J2GEK5OCvFv71wHWXoKeG19aq+GNlSaEBmemhIS5yC9X+ TjEviZZu/b5c4sPf3eHmtivJKUOOJ9Tcj1xZgpj1f6ZTk0Dt74T2KiyBkmmlPdr5 xiX6DtJm5z77WX2vMGulQa57pnDyEhWq4l3fmHPSLMUmT4nFIeDNK3EJi3j/pS0= =hm9t -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Allergy for client certificates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/10/13 10:56, Guido Witmond wrote: You might want to take a look at my experiments. It's a user agent that does all the key management for you. It even does it with never asking anything more difficult than what username you want to have at a site. Hi Guido, It looks like you've worked around the UX issues by inserting an EC-aware proxy between the client and server. Who would be responsible for deploying such proxies? What happens if a user creates an EC account from a client machine with an EC-aware proxy and then wants to use the account from a client machine without a proxy? This touches on another question I've been meaning to ask you: what happens if a user creates an account from a client machine, thus installing a client cert on that machine, and then wants to use the account from another machine? Also, what happens if a user installs a client cert on a machine and then walks away, leaving their client cert exposed to the next user? With passwords there's an expectation that once you've logged out, the next user can't log into your account. But client certs break that expectation. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSVV9DAAoJEBEET9GfxSfMSYUIALt6UPDE+mp2hIKWPJeOX//z rQ3Z4Jut/kU5NIIf3B0jdq/wjBz4kaY/M5t6DfiHIfRdQ0kXePg7izgoqnx5JRSm kcSS4WXHrxga0g2eGbZSrkmlh0sZOhIA09BgZiRF6Ux3f2QMUrEv0NVmQZLK5Rp3 TKAulMRfw7+38Bis7IvSL9qKtzUXLmPK36NYvHG3Pzeg1da1yxeeElXdy9ZGWrmq AU4Y/hg/DWLgV58dMkXg5rY6jetUAUzGNUJMwKrqVcMz7+ZDc6JaQ8uR2MXtehAf cLChx2wCsV0b7mw1Fub4qQD+jYVqh+tWleVjLd1EcG46hGXLM03+JnC4fXvj20k= =xBwX -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30/09/13 23:40, Trevor Perrin wrote: It'd be nice if Alice and Carol could use some additional, out-of-band channel to authenticate the ephemeral DH exchange. To fill in some background: the use case for this feature is introducing two people who aren't face-to-face right now and don't share an authenticated channel, but who each share a confidential and authenticated channel with a third party. Users aren't assumed to know which channels are confidential or authenticated, so we shouldn't create any opportunities for mistakes in that regard. I think that rules out PAKE. Best I can think of are short auth strings (SAS), public-key fingerprints (if you added long-term identity keys), and PAKE. The tradeoffs are something like: * Key fingerprints and SAS are non-secret (unlike PAKE passwords) * SAS and PAKE can use short strings of several chars (unlike fingerprints) * Fingerprints can be exchanged before *or* after the ephemeral DH handshake (unlike PAKE passwords or SAS) * Fingerprints can be confirmed with 3rd parties or public records (unlike PAKE passwords or SAS) * Fingerprints and PAKE can be compatible with a single, unordered handshake exchange of ephemeral DH values, unlike SAS Thanks, this is a really useful comparison. Perhaps we can combine some of the advantages of fingerprints and SAS: * The introducees exchange single-use public keys, signed with their long-term private keys, via the introducer * The introducees derive a shared secret, destroy their single-use private keys, and start key rotation * The introducees exchange acks via the introducer * The introducees can optionally obtain each other's long-term public keys from other third parties, before or after the introduction * If the introducees meet face-to-face, they can confirm each other's long-term public keys using SAS: - The users verbally exchange short codes to enable their devices to find each other over a short-range transport such as wifi - The devices exchange hash commitments and ephemeral public keys - The users verbally exchange short authentication strings - If the strings match, the devices derive symmetric encryption and authentication keys from the ephemeral shared secret - Within the ephemeral secure channel, the devices exchange long-term public keys and a value derived from the current temporary secret, signed with their long-term private keys, as verification that they own those keys and have the same shared secret * Nobody signs anything that proves who their contacts are Any thoughts on cryptographic or usability aspects? Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSTYr1AAoJEBEET9GfxSfMYx8H/0RxYl3gEqu7KUz/D5053o2T 2cZIUopdSiZs6SYH2gnTzrGPXAyd3xvGMmTFKV40EAWdix1+ZHpg6fs1i7wWZ6Q9 NbUNX5C1L8hbmMI4aK0ebq69J54N/iZqiQte/utQ3fwjq28U0xARuwq5VqPuJRlS 2TGt5tZG9tN5vAtb3R8I94OGwpF1PwFYEpUlyhG7LRRSoQBV5Xw5QwDaf7VKkeBM UoZ6JlAjI0wl17U01E6dYHmZpcq10EZ+BTomD+Kw1lioPGj15S97a4odOo0y2gd+ 0uW+yXoVRhRO4Hq2f9HPfMhoNE34eXt9ube1a6PrOmXMT2Dan/g10cVSOowZRMw= =O6PJ -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] A question about public keys
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/13 15:14, Adam Back wrote: Well I think there are two issues: 1. if the public key is derived from a password (like a bitcoin brainwallet), or as in EC based PAKE systems) then if the point derived from your password isnt on the curve, then you know that is not a candidate password, hence you can for free narrow the password search. (Which particularly for PAKE systems weakens their security). Presumably if you ensure that the private key is valid, the public key derived from it must be a point on the curve. So it's a matter of validating private rather than public keys. I understand what you're saying about a timing side-channel in the draft-harkins-tls-pwd approach, but here I'm not concerned with validating a public key after generating it, but rather with the puzzling statement that there's no need to validate a public key after receiving it: How do I validate Curve25519 public keys? Don't. The Curve25519 function was carefully designed to allow all 32-byte strings as Diffie-Hellman public keys. http://cr.yp.to/ecdh.html#validate 2. if the software doesnt properly validate that the point is on the curve, and tries to do an operation involving a private key or secret, anyway, it may leak some of the secret. DJB has some slides saying he found some software does not check. Hmm, so perhaps the statement quoted above simply means Curve25519 contains its own key validation code, and will complain if the string you give it isn't a valid public key? Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSTZLlAAoJEBEET9GfxSfM4dMH/jo83Jse5V6DqnZwaIkNesLY AufH8+amkMALbO8Db7r/sG+cGXMy8sSRWqPTJ0jXd3z4ZAgKbx3aW2eBEmIU9i3Y K0jkABVJty3XyvPAspoCUwZ+Fh7brUSCRHQJt0MWMQADPdoXJUY+iobmCGgO4Qbk +npDlo3pTNeEofsvkEM3uSPofR88JXvMC1sYhGr4+GMsBt330vG2Zd278AlVTlOb fVpwEtlad5Fb58RfGidMb4n7BUKKmkPI3KJewpJEXfc8CMP1ITsmX8hTzIz0wakz ubjwDu7ENUMkZhfkt4qNpTLeWQBOFrrfUDe9qrlTY5GpbNfy295K/aWMvi65c6g= =sxPV -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] A question about public keys
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/13 16:45, Trevor Perrin wrote: Suppose you are a good guy with a static curve25519 key, and a bad guy is sending you 32-byte strings, claiming them to be ephemeral curve25519 public keys for use in an ephemeral-static Diffie-Hellman. You repeatedly perform your side of the ephemeral-static DH. I.e., you perform a curve25519 operation betweeen the bad guy's alleged ephemeral public key and your private key. After each DH, you give the bad guy, say, some MAC based on the Diffie-Hellman result. At issue is whether this is safe without checking that the bad guy's strings correspond to possible public keys. And it is, with curve25519! Thanks! I think I finally understand what it means to say that all 32-byte values are allowed as public keys but not all are valid public keys. Sorry for taking so many round-trips. :-) Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSTZXwAAoJEBEET9GfxSfMUQ4H/R+89hfxD8Wy8wjPt8Bj7gsx rLLquJlvVqlvWqAGXzZcW/zkiqqb8nR5fCU+J5d8dAdB9M1J6AAJC10sDMoj+5/z vIQMBIO+9W28bhaQbb3cWLsaG+tI4Uo/rkZrEPVkBvELXq33fBNjFd4VZFcNUX63 0ZZQwYZ08JzoDtOAIKLHjHq3xEkwi2a5TDGwQMy2p5KUmSf1kIRdyQIMMGoGmKua KWtnfbeledr65+iqFIYyZlntMeMxSrgIJ0CRnjk09sqbkkjz8Pzau4/JEcuLBYhd uJb7y73L2OdKjzWVdYWjLhThKDPnVOf3FVX6CHP121YxBa7zmEYxhhOmpBNOPqc= =PH7z -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24/09/13 07:52, Trevor Perrin wrote: On Mon, Sep 23, 2013 at 4:51 AM, Michael Rogers The key agreement starts with a hash commitment, followed by an exchange of ephemeral ECDH public keys. Two short authentication strings (again, six decimal digits) are derived from the shared secret; the users exchange the authentication codes verbally to complete the process. Sounds reasonable but you'll need a 3-way handshake for the short auth strings, which could be awkward in an asynchronous messaging scenario. Good point, I should've mentioned that the key exchange protocol is designed to be carried out face to face; it requires a low-latency duplex channel, such as wifi or Bluetooth. We're also planning to support introductions through mutually trusted third parties. The protocol for Alice to introduce Bob and Carol to each other will look something like this: Bob - Alice: I'd like to introduce you to Carol Bob - Carol: I'd like to introduce you to Alice Alice - Bob: OK, here's a single-use public key I just generated Carol - Bob: OK, here's a single-use public key I just generated Bob - Alice: Here's Carol's single-use public key and contact details Bob - Carol: Here's Alice's single-use public key and contact details Alice - Bob: I've deleted my private key and started key rotation Carol - Bob: I've deleted my private key and started key rotation Bob - Alice: Carol has started key rotation, you can contact her now Bob - Carol: Alice has started key rotation, you can contact her now This process requires two-way communication between Alice and Bob, and between Bob and Carol, but that communication can be asynchronous and long distance. Alice and Carol must trust Bob not to MITM the key exchange. If they ever meet face to face, they can carry out a fresh key exchange with short authentication strings to check that Bob didn't MITM them. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSSE3/AAoJEBEET9GfxSfMo7MIAKeQDFLChMyKBBuzmSq29/Wc rI5HXiCD6CoPj6AU+TrFlpl+WknM/PlqTtYR1RXxmE2uDKyTUij5+ntZhvLg70uG 9D64bAW8gZ41T+MIMp1+7e55XYQt2+WcZen7Cmk78PFuMvexqtOI8OZShfqKYm/y rwpn5YfC7qV5mqJRM90PfwmEKgoom4mzl0VBw39SMjtXA1vHd4bEBseiAcp3d0h4 momQLGcd5ELbI3n2AfX8grFOcF4QuYBxHRK+bESdzSkKy40cBzdI3T5jaBvRQz5O SAdrvcw/XR/B40hXc8kzrLuFDPezpAa6ReGwB2ioa0IPJsxXVWpRS/QjmKwo+Xs= =3Q27 -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28/09/13 12:36, ianG wrote: On Thu, Sep 19, 2013 at 09:20:04PM +0100, Michael Rogers wrote: The key reuse issue isn't related to the choice between time-based and message-based updates. It's caused by keys and IVs in the current design being derived deterministically from the shared secret and the sequence number. If an endpoint crashes and restarts, it may reuse a key and IV with new plaintext. Not good. Either the whole session has to be renegotiated then, or you need a way to inject fresh randomness post-crash. It's not good to rely on counters or RNGs in those circumstances. Time ? I'm assuming that if a crash occurs, we can get fresh randomness (e.g. from the OS) after restarting. Is that not a safe assumption? I'd prefer not to rely on time, as the rotation periods for high-latency transports are necessarily long (we don't want to rotate keys while a message is in transit), so after crashing and restarting we may have to wait a long time until the next rotation period starts. I'm assuming the IV is shared in the enciphered message, as otherwise it is unknowable to the recipient if it has 1. in it. Yes - the format is (random IV || ciphertext || MAC), where the MAC is calculated over the IV and ciphertext. (If using an authenticated encryption mode instead of a separate MAC, the IV is included in the additional authenticated data.) It seems we're getting closer to MAC-then-Encrypt. That is, take a HMAC of the plaintext (uses 1, 2). Use that as (part of?) the IV. Encrypt. Deliver the IV + ciphertext. To be honest I don't see a reason to use any function of the plaintext as an IV - I'd prefer the IV to simply be a fresh random value, unrelated to the plaintext, unless there's a reason to doubt that we can generate such a value. I guess I would go back to first principles and ask why we're doing this. Yes, great idea. Here are the requirements as I see them: 1. Protocol obfuscation: Nobody except the intended recipient should be able to distinguish any part of an encrypted message from random bits 2. Unlinkability: Nobody except the intended recipient should be able to tell whether two encrypted messages have the same sender or recipient (except by observing who sends and receives them, of course) 3. Asynchrony: Messages should be deliverable via high-latency transports such as migrating geese 4. Forward secrecy: Encrypted messages should eventually become undecipherable by their senders and recipients 5. Error tolerance: None of the above properties should be lost if messages are lost or reordered in transit And of course the standard requirements of confidentiality, integrity and authenticity. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSSFO4AAoJEBEET9GfxSfMWOwIAMUXpoCPePO8pwrt4OhEsruS WNXw3DZGzTfEf+Rfe7tYulpxwEgz4BHUUjhTHiNe7jEwyYzq47vA5cglgJQAnvMf fOyeIk4FWhnpgC9MJcBeasBwr9lCxHBm/w2jBfYI5/z9F9fZa8CW7MDhVSrJMdrK rdVwb5hbyfr9UNPrzGfZ0zw6I9uk7e+1x+L7q+ia4ADGIZ3AuJK9JoYz/FGCQbbB 5HWAGoMvGMKqVMvSItN1Aj25oEyOkaPTb6B5ldrFqa97xsQClh1gQZyHJVcC+FTD EvyN06Fl1f9KKjLoDr21hSalqsrV9H3F3iim6y/eXYLbr6PCLNupnmWGdnUWvJw= =3kLK -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] A question about public keys
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry for making so much noise on the list today. I have a quick question about public keys. The Curve25519 paper says that every 32-byte string is accepted as a Curve25519 public key. Yet Elligator doesn't use Curve25519. So I guess there must be a way to distinguish a bunch of Curve25519 public keys from a bunch of random 32-byte strings. What is it? Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSSFT6AAoJEBEET9GfxSfMHLIH/1W98ezG12sqVPAmjcRBauoP EbChv+BzACaOz62I0Jxhc8quGHK3eqYOB0pDtFp2nGWuJpAw7OEKSAVNCABcTO/n OKTk0v24pNCf82RKF2UfAVr43s+cC2N8ApwYobC12Dp1C8DqxiBX+ERS/XleM12b LrPcVW0W6WYcnsK2CgOlENg70XaLDn1bn1M/O+DAsb8ue8nBoXN5UXGMaLRGEkuc jAOBljsiLdPc+gS6waseBuYTWnLk2plnHfrSXOR/1P+rM9rcQgZJsYsPJALzXXeH +ZbSW0+T0NbUMN8kmEhuNOSqGH5CBBpPYzm3dJEXVT1zdBGIyLPQUf475IFZHso= =H7Qj -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] One Time Pad Cryptanalysis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/09/13 17:36, Sandy Harris wrote: John Young j...@pipeline.com wrote: Tiltman vaunts the One Time Pad but cautions there have been effective decrypts exploiting enthusiastic sloppy thinking that OTP is unbreakable. Most appears to involve non-decipher means and methods. The paper redacts others presumably still effective. Here's one, not always applicable but devastating when it is: http://en.citizendium.org/wiki/Stream_cipher#Rewrite_attacks Reuse of pads is also disastrous - VENONA made a breakthrough due to pad reuse, which wasn't public knowledge at the time the paper was written (though was by the time it was declassified). Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSRIG3AAoJEBEET9GfxSfMPAsH/RiJ3eshLdf9wHCVzeZ+ WNSLuJ4Pb3J+B3kjYmei6M3RpfhsA0TWhHZxjUlBnBLqf3/+CoRsXSXMlfTS9EZV BXbNIjiDH5JiYJHGFGp3RZ3Cu1tDO59+1J+albBgMsY9V7Nk67HgBp66n9BuvgxK CqpY1gZQ5dXU/iQVgpUdAgPt9urZeShy9IF8l9pj38tAZtNF6XKjZ/HvezbGwh4s yhoYsYjIT56Nc04/yGKJKTwGztPJ4V3oIcKeXgCYCQx5AbGNqkimk+fnkiYVFzoW Wq3ycmgMJqFYSr3GSGniGjPeh/4kOsvSQSENHUzGW6qk//bNkgrsRm3TekCSsQQ= =lPIx -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] secure deletion on SSDs (Re: Asynchronous forward secrecy encryption)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24/09/13 00:18, Adam Back wrote: On Mon, Sep 23, 2013 at 01:39:35PM +0100, Michael Rogers wrote: Apple came within a whisker of solving the problem in iOS by creating an 'effaceable storage' area within the flash storage, which bypasses block remapping and can be deleted securely. However, iOS only uses the effaceable storage for resetting the entire device (by deleting the key that encrypts the user's filesystem), not for securely deleting individual files. Hmm well thats interesting no? With the ability to securely delete a single key you can probably use that to selectively delete files with an appropriate key management structure. eg without optimizing that, you could have a table of per file keys, encrypted with the master key. To delete a given file you'd re-encrypt everything in the file table to a new key, except the deleted file, and delete, then over-rewrite this effaceable storage area. Yes, absolutely, that's what makes it so frustrating - they already have per-file encryption keys with user-selectable key management policies and a hierarchy of keybags - adding a policy for efficient secure deletion would be a small amount of work. But it's work that would have to be done by Apple, not in userland. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSQU8rAAoJEBEET9GfxSfM9FsIALdSvuPTB4b8zUa9NnVSz+bM JdgQ9/pMB60V2/3Ebjm6zZHEZ/AmWDOQslOGCOANMa1JkbL51Hfzhd5qFllEXyeK 8T2pX6K0vKwyPWBmeASMATtiUxXgvf1NCE+TzQexmb/OEBF+Kq384tgu9Jps+H6K ktIXFImUBnkrjpp7g4mUbJv4SOZBdBrT7kLqouSPS/UdfscZhnlPS1yT713J1GIL nJBNjAabkaMsk77RfvasCk5NQZxUz0T/3g51Xf/eaoFij7AXK9nGJVrOAPti0WsW hfdKlxMzsWDOpHAtHFChpkdTAH1bQEbZXW6XXOvZYuSFkK2yM1nAb/ba4+CVclk= =ttTm -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks Trevor and Adam for your comments on this - I take your point about the importance of forward secrecy for metadata, so I'll abandon the idea of using ephemeral-static ECDH to protect the metadata. On 20/09/13 01:55, Trevor Perrin wrote: Interesting, are the codes passwords? Short Auth Strings? Each endpoint generates a random code (19 bits, represented as 6 decimal digits). The users exchange codes verbally, and the endpoints use the two codes to find each other and obfuscate the key agreement. The meaning of find each other depends on the communication channel; in the case of Bluetooth, the endpoints use the codes to generate a Bluetooth service UUID; each endpoint advertises a service with that UUID, looks for nearby devices advertising that UUID, and makes an unpaired RFCOMM connection to any it finds. The key agreement starts with a hash commitment, followed by an exchange of ephemeral ECDH public keys. Two short authentication strings (again, six decimal digits) are derived from the shared secret; the users exchange the authentication codes verbally to complete the process. (Elligator + DH-EKE makes a nice PAKE, fwiw.) Thanks, I'll look into it. The protocol I described above is (loosely ZRTP-inspired) homebrew, and it would be nice to move to something more standard. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSQCs5AAoJEBEET9GfxSfMLyIH/i1x/yxCsge/QSoYVUhF4tSs xBeEcZkRzsvaOdA97c02cFBQJqThnS5m3af0T6dxZWr5PfNJBnxO8j0T5gSkjgVL lSwHUZG17IGWq9xGY49XTkpO/yw91qjvZhoIuzJf4BSnSV3c37sNIC/4GrXT88TA 2yP80YaWJtiLHFBgFoLkK6qKWyB3asIQ+zxd2AOcPtxT4QoQ8ySksSu3SWT9M8do 08hooVd6uVifHvWHSzBGnPIYGdoxeyUYEBwDWXC/ogMRIBqoAZA+nWtScm+cYqZI um2UIByTRLcE5JOxQHw2IV1FdurBIH/zZJ2Dsc1CbFhEbhEupPxP6Dl/XZM6VsU= =Otj3 -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23/09/13 05:12, Dev Random wrote: I've been thinking about this for a while now and I don't see a way to do this with today's mobile devices without some external help. The issue is that it's pretty much impossible to delete data securely from a flash device. That means that in order to guarantee PFS, you have to store the keys in memory only. But again, in a mobile environment, you don't have access to stable memory either, because of the OS restarting your app, or the device itself rebooting. Let's call this the persistence/deletion issue. Yes, this is a major issue with current mobile devices. As far as I'm aware, SSD commands like Trim and Secure Erase aren't available on SD cards or the built-in flash storage of mobile devices. Apple came within a whisker of solving the problem in iOS by creating an 'effaceable storage' area within the flash storage, which bypasses block remapping and can be deleted securely. However, iOS only uses the effaceable storage for resetting the entire device (by deleting the key that encrypts the user's filesystem), not for securely deleting individual files. http://web.archive.org/web/20130302170747/http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf http://esec-lab.sogeti.com/dotclear/public/publications/11-hitbamsterdam-iphonedataprotection.pdf A similar approach would be possible on Android, but I don't know of any Android devices with effaceable storage. The closest I've seen is hardware-backed key storage, where keys are generated, wrapped and deleted by a TPM-like chip. Software can use the TPM to perform operations using the wrapped keys but can't directly access them, and thus they can't be exported from the device without cracking open the TPM (physically or via a vulnerability). http://nelenkov.blogspot.co.uk/2013/08/credential-storage-enhancements-android-43.html In combination with a hardware-based flash controller, this raises the bar for undeleting data pretty high: the adversary must compromise the flash controller to get access to data that's been logically but not physically deleted, then compromise the TPM to unwrap or undelete the deleted key with which the deleted data was encrypted. I'm not saying the bar is too high for a national security agency, but it's too high for some adversaries, so I believe it's worthwhile to think about forward secrecy on current mobile devices. So, I submit that PFS in async messaging is impossible without help from some kind of ephemeral, yet persistent storage. A possible solution might be to store a portion of the key material (through Shamir's secret sharing) on servers that you partially trust. Sounds like a great idea, especially in combination with a panic button or dead man's switch feature that alerts the servers to delete their shares. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSQDaHAAoJEBEET9GfxSfMw/EH/RQ9nmgB0TfTboQJQThHOD3k qDD0UrsjHqVwLD4oZu/rFMxIjQv0ECnLh2zJsbR9E0DqEbJAaOQ/GuDcY9RzzZ7S w1H0Ly1ecJu/iaBQ0Ah0VC+SH0qBWupsk+mSLxeXICMR/6JuMslVYhiErM6mM94O OLaia9slAoYDSTs+l/fOXXOtzrTTT3Nkn2M9mOhPVe6HAKNi7Ks1qXl/XMe4WZhJ eTttbqHhkoZDHLnCjKvskwPDUGlcAhNXkZ8sfphWyr77xEOK2md8Okx6oIBzRI53 UgKiVi3g+VwgY9jxeuUUc8xR6/yYXKncEuSCoF+oVKNsRqBTM7trKh1tU+J3Jqk= =G1oY -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Image hash function
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 20/09/13 13:11, shawn wilson wrote: Does anyone have a list of processes people have come up with to create images for hashes? The only one that I'm aware of is the randomart that is generated when creating a keypair for ssh (http://www.ece.cmu.edu/~adrian/projects/validation/validation.pdf) I wanted a fuzzy solution - so an image would be similar but not the same for a given key. Say some type of fractal or optical ilusion with static that didn't defeat the ilusion or something like that? Hi Shawn, Here are some ways of representing hashes visually: https://en.wikipedia.org/wiki/Identicon http://www.tastyrabbit.net/visprint/ http://scribblethink.org/Work/VisualIDs/visualids.html I don't think any of these are fuzzy, though. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSPEB4AAoJEBEET9GfxSfMElQIALjvKHCSMjkLYxKGuvdYzeAa WhAYWPokTFdhT/gBLq4rQShG5MBDMJ4DMaGPV92Z4D3S8BIdXRSuOnjVWyImmX2K EPB0Bex0y7Sf98ug1jMDVhb1/qVmJ84kXq1TVWay9lOolxu+srQ6r1AjN84ZN+sR 5x+8J2werhtrnYZoS9+bXj1CaFtOflI/kLc5ZFMM0JuERLMvKBl88tDVmNPukBXR 2S99HltioSa8s63yznWTCZ7h+4aCE2At4dxoYgEaJgutIb+V85kj4Yw2ShY745gU s7lAz2YRE3VeBKg7UDd/chkOgfnAJJJ5vO3GKsaf3xSua125utU3wNdawdJ6zHg= =TCUH -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19/09/13 08:04, Trevor Perrin wrote: I'd have to see a writeup to have real comments. But to address the issue of fragility: It seems you're worried about per-message key updates because in the (infrequent?) case that a sender's write to storage fails, an old key would be reused for the next message. What happens in that case? You mentioned random IVs, so I assume the only problem is that the recipient can't decrypt it (as she's already deleted the old key on receipt of the previous message). The key reuse issue isn't related to the choice between time-based and message-based updates. It's caused by keys and IVs in the current design being derived deterministically from the shared secret and the sequence number. If an endpoint crashes and restarts, it may reuse a key and IV with new plaintext. Not good. In the new design, the temporary keys are still derived deterministically from the shared secret, but the IVs and ephemeral keys are random. The sequence number's only used for generating tags. So if an endpoint crashes and restarts, it may reuse a tag, but it will use a fresh IV and ephemeral key, so confidentiality and integrity won't be lost. That's not great, but again this should be rare. I think you're trying to make decryption failures even rarer by performing less frequent time-based updates (instead of message-based). But that introduces time-sync and latency failure cases that didn't exist before. So I'm skeptical it's a reliability win. We're not using time-based updates because of the storage reliability issue. We're using them because of two issues with message-based updates. First, if messages are lost, the sender and recipient can lose synchronisation: if the sender's sequence number moves beyond the recipient's window, the sender will start using tags that the recipient doesn't recognise. To re-synchronise they need to reset the sequence number periodically. Second, if a message is intercepted by the adversary and not received, the recipient will keep the corresponding key until it moves out of the sliding window. If the sender stops sending messages or the adversary keeps intercepting them, that may never happen, so there won't be forward secrecy for the intercepted message. With time-based updates, the recipient will delete the key regardless of whether the message is received. We've tried to avoid plaintext fields in BTP to make it harder to design filter rules to detect or block the protocol. Makes me curious to see your key agreement. Elligator? I hadn't heard of Elligator - thanks for the tip! Briar's initial key agreement takes place face-to-face over a short-range transport such as Bluetooth. The key agreement protocol is weakly obfuscated using the invitation codes the parties verbally exchange to enable their devices to find each other. If you don't want recipients to have to check so many tags, you could encrypt the metadata with longer-lived keys (trading off forward-secrecy of metadata for easier processing). For example, each pair of users could have 2 symmetric keys they use to encrypt metadata (one for each direction). Perhaps they could even update their sending key whenever the other party ACKs it? This is a possibility we've discussed. But if the recipient corresponds with several senders, she has to try decrypting the metadata with all their keys. Apart from being inefficient, the timing reveals how many senders she corresponds with. The recipient could have a long-term public key that senders would use for encrypting metadata. Until now I didn't know of any public key cryptosystems with ciphertexts that were indistinguishable from random strings - but maybe Elligator can serve that purpose: * Each recipient has a long-term ECDH key pair * Each message starts with an ephemeral ECDH public key * The ephemeral public key is indistinguishable from random (Elligator) * The sender and recipient derive an ephemeral shared secret from the ephemeral key pair and the recipient's long-term key pair * A key derived from the ephemeral shared secret is used to obfuscate the metadata (sender's identity and sequence number) * The recipient uses the metadata to know which keys to use for authenticating and decrypting the message This would work with time-based or message-based updates, and would allow us to get rid of tags and sliding windows, which would be fantastic. Any thoughts? Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSO1x0AAoJEBEET9GfxSfMmFYIALHFKgC73PHLtxXOktSEnaKh ZfAala6xYjFLgJWfPNnpH9Zzk3qrVf3CSUdvw/opFh2mEcx1cVyFbx+7i3YeEA89 CH9ISddmOP0j1QMVrA1KFAYhLsQxeGUjgTp88GbCo5hrRNvFd6F8/EwUzp8AyNqG 7fJ8z4YzD6Lis00/bkLWlfqABcymL0ZIwFxpmL95JQSmcgspO9cYAUwjRlz6WVNH cE+bwL8pmnrwVIXKY/3ONDudlnC31lSaHMnDm7knNE6FkvsYK5Rg62k+KFwe6MTO +I7XPzGjR4Mje6C3Uq8HLvwYpqJbNgtgYJvzS4kTYmBQ5turAF3MsbacN1nqf08= =GGzM -END PGP SIGNATURE-
Re: [cryptography] Asynchronous forward secrecy encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18/09/13 00:14, Trevor Perrin wrote: Why not have separate symmetric keys for each direction of communication (Alice - Bob, Bob-Alice). We derive separate keys for each direction from the shared secret. Then whenever a party encrypts or decrypts a message, they can update the corresponding key right away, instead of having to wait. (Or look at OTR's use of updating Diffie-Hellmans). We did look at OTR, but unfortunately it's not suitable for our use case. We want to be able to operate over a wide range of communication channels, including one-way channels and unreliable, high-latency channels like the postal service. OTR's forward secrecy requires an ongoing back-and-forth between the two parties. Our approach doesn't provide forward secrecy as quickly as OTR's if there's a constant back-and-forth, but it tolerates lost and reordered messages, one-way communication, and long pauses in communication. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSObasAAoJEBEET9GfxSfMrRQH/1DKnD3NhMeKgX3CY/Wk0LrR MLM3SBd6rCHYh3kcVFmR/e08jaTRIF00/6FWJMCRgB5MAxU3iP/9+fXuLhQGHM4u O3nF2PXBnDYGv+bDwyDhErea9RjfFqIh7MIe2m6VgtOv399aiIvbUH0WrK6RADL3 Gz/VmCKZPZD6ZhPj67YQKOfG7BBmAY3znCCGv+yxDaoxGygqdydOGqRQaAumnAie 5Gvmmc63JYQTlFGd6MUgxa2HJben9PkE1mz5Qy5nlUnUY+fcoLRr9OznTxGTS7cT W5fU00g95SCUwT3q2cBxNV6J8RMCedWuDyP1htrZcAVEs5ZLk9t/U71IqQOfccE= =JYLo -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 18/09/13 08:12, Adam Back wrote:
Or better the actual key used could be derived to fix that. eg
k_{i+1}=H(k_i) delete k_i; but also sk_i=H(1||k_i) then use sk_i
values. In that way you can keep keys for a gap with no security
implication other than the missing/delayed message security.
Other messages that come afterwards would be unaffected.
This is very close to the way we currently derive keys. We also derive
a pseudo-random tag corresponding to each key, which is prepended to
the encrypted data so the recipient can detect reordering (using a
sliding window as in IPSec) and use the correct key.
However, this approach is fragile because it requires persistent
storage of a counter - if the app crashes after using a key but before
persistently storing the updated counter, you can end up reusing a
key. Unfortunately, since hard disks and operating systems lie about
having persistently stored data, this can happen even if you store the
counter and call fsync before using the key. So we're moving to a less
fragile approach:
* Rotate the shared secret periodically
* Derive temporary encryption and authentication keys for each
direction from the current shared secret
* Each time you want to send some data, generate a random IV and
ephemeral encryption and authentication keys
* Use the temporary keys and the random IV to encrypt and authenticate
the ephemeral keys
Cheers,
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJSObpCAAoJEBEET9GfxSfMrKIH/jfQwJzBaPLx7uKzJdoGHQkJ
8NWSYh3/YePrY8Ukbx9qZUMyBwghRecgf0u/pJeId5+fktgc2u1BVXQCekBIyYCO
YSxmHBDsfQ3cC+5JRMH8U7JwsRMvWDBYJdDCX3IR4ofGJ7+aaJuwqo13vhoToO4C
kkPGvXIvTSpP6YLSvy1wlbHwFy9hb3e3ywvt91jsGvk/nIfBX+eQLEixu/HqjVkN
g6IGvyMgm7B5m5puiodwH7k3fL0vIkdnWAtQZu7S3UztovyFqaJY34NCV+JgusYD
X0cmojyKf1/quePi8exMkeQaibrOPUG3a+O8f+Jhld3Gfv4fyO8EIK3PVoKIMbY=
=2Vz/
-END PGP SIGNATURE-
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18/09/13 08:23, ianG wrote: If I compromise your first shared secret, does that mean every shared secret thereafter is compromised? Yes. (Improvements are possible here, by sending and acking fresh key material inside the encrypted envelopes, but that requires two-way communication, so in the one-way case we'd always be vulnerable to the initial secret being compromised.) How do you coordinate between endpoints for the rotation? Is it strictly time-based? Or is there some sense of searching the space by hashing forward multiple rotations until the message decrypts? It's strictly time-based. The rotation period is based on the maximum latency of the communication channel and the maximum difference between the endpoints' clocks, such that if the sender thinks it's rotation period p at the time of sending, the recipient will think it's no earlier than period p-1 and no later than period p+1 at the time of receipt. If the endpoints have very inaccurate clocks, you get longer rotation periods but the protocol still works - as long as the endpoints know roughly how inaccurate their clocks might be. Ah, but does it consider the pâté attack? ;) Is that a type of meat-in-the-middle attack? Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSOb2KAAoJEBEET9GfxSfMae8IAMR0HxXQYUwIgJrQ5byQnIdO /z8frXW4qhBKtyt+zimpS1N0qBxg5hbQKoSYqSsIq/Et80/Lmjivnv/bHrVvfCeI RX0aFVvZi3BXthuYqr8x/AAbYun9y/jGAz6UoIDyXXA9oljom//e5AqZK3p9o9sg eWDltbuc4R5QBMEeMvbL7MM5PxrpSEVGfh0KzQZFn/MOCg6pjDuXWnfWWajf1Eg0 FZvaGNKu9DmNU9hxI8MOZePmiTy9S/Bjayp6Syt1cJTKKT9lT8IQJwRb1tERf/Go DqrdZBUZmsR1CIlzy9eS2XSUD4hyBqfp+Y2hjWanzsA1JWx7XrcDxxy5jTRJ3+c= =R1L+ -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18/09/13 17:27, Trevor Perrin wrote: Hmm, I would've thought clocks are *less* reliable than storage on most devices. That may be true, but this isn't a choice between relying on the clock or relying on storage. It's a choice between relying on both, or relying only on the clock. Certainly this has worse forward-secrecy than updating keys per-message, as keys for old ciphertext are kept around for some period. Yes, updating keys per-message would be preferable if we could assume an ongoing two-way exchange of messages. For OTR's instant messaging use case that's a reasonable assumption. For Briar's use case it's not. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSOeFqAAoJEBEET9GfxSfMJFEH/jnyd3SAYKhNAhQVFOYlvyy1 zckK4VQClQPEOwRcidSud9zSxblRQXQGJSO+pB23niHgpbomzDx7fc5jKlShF/yt sZ8qJ2gj13xZey0rp+DWK3DCcKq0erEbDd58bngJsHtFoVyjYpsZKfMi8Mqhl3iN 2QvEXkwkUzVTSX8bks30WRgGAObimvEHAOU7eOY32xZgy/l2VwUDOws5fd0lc5+p +HcEQLyckkSZnaF6C/vXa6jbNYigRLzR+UslIVnshg1BWrgShxe+f+2TtWhLDNqD 1y0vRdhW+JzQYcwmmTQyHpKGl5qCQ6vmkYxdmsm6JvGLFR06q+FG8thaWE/VCU4= =hmqv -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18/09/13 18:56, Trevor Perrin wrote: Sorry, mis-send... I meant: A quick glance at Briar makes it looks like it already uses local storage: Neither endpoint can send more than 2^32 connections to the other during a given rotation period. Each endpoint persistently stores the highest connection number it has sent to the other during the current rotation period, together with a sliding window of the highest connection numbers it has received from the other during each of the current retention periods. The persistent storage of these values is vital, so BTP cannot be used by endpoint devices that lack writable persistent storage (unless the devices never reboot). Yup, that's the fragile current design I mentioned. :-) The new design still depends on persistent storage, but it avoids the risk of key reuse if the persistent storage is unreliable. But I don't know enough about the protocol to be giving advice, so I'll stop... No, it's always good to get people's views on the design - thanks! The per-message symmetric-key update that Adam and I sketched doesn't require a 2-way exchange of messages. Even a one-way stream of message would receive good forward secrecy. Ah, sorry, I was thinking of OTR's per-message update rather than yours! The method you and Adam suggested would be suitable for our use case, and much more elegant than what we're using now, except that it requires a plaintext sequence number. We've tried to avoid plaintext fields in BTP to make it harder to design filter rules to detect or block the protocol. So we rely on the pseudo-random tag to tell the recipient (a) which sender the message comes from, (b) which rotation period the sender was in when the message was sent, and (c) the sequence number. The recipient precalculates a limited number of tags in a sliding window, which allows a limited amount of message loss or reordering - but if too many messages are lost, the sender's sequence number will move beyond the recipient's window, and they'll have to wait until the next rotation period to resynchronise (the sequence number is reset at the start of each rotation period). This is all rather clunky, and I'd love to find a better way to do it, but so far I haven't been able to work out how. Suggestions welcome! :-) Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSOg7cAAoJEBEET9GfxSfMZuAH/jQhZXDNMs0LszDoAE72SNaO et+uwRk1m8wnChhU1WCuQ8Cmc//tJxcdly9BfzqUafs7q4dj1pl7YEoRI152bs9J mFcF/Z7oF5/ueZ6m/deuR8e9Lf2oGgIvP8K87/E/DRQFGKR/As7rGs7Or9lchpey m7OFztfP0BB+uRkHrC7vfdgWqPOQeDnuHa1pItA+zXLqRloze4pPSpuHhvc2EGz2 JqckFQ4b0GRKFdHReYv/S46TO/g96qLjz+wNu9QUw9oAUiSHcuhQcJ7FX0dEXm77 mk78jRRBpaEjLCF03Zt+wcFSHJ30/GSqtdKyYnuJ2OfjMpkF6Ym3odWfzKtoYw4= =I+Be -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Preventing Time Correlation Attacks on Leaks: Help! :-)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Fabio, It seems to me that there are two fundamental problems to solve if you want to disguise the correlation between a node's inputs (submissions, comments and edits) and its outputs (notifications). The first problem is disguising the correlation between a single input and its outputs. To do that, every output must correspond to several possible inputs. So if you plan to disguise the correlation by randomly delaying the outputs, you need to delay them by several times the maximum interval between inputs. At this point two practical questions arise: 1. Is there any maximum interval between inputs, and is it possible to know what it is? 2. Does the resulting delay make the notification system less responsive than, say, logging into the node once a week to check for changes? The second problem is disguising the correlation between a series of inputs and their outputs, where the adversary knows that the outputs are related. This is much harder than the first problem. For example, if the adversary knows that a series of outputs went to a journalist who published a certain leak, the adversary may guess that many of those outputs were caused by inputs made by the leaker. For each output, the adversary finds the set of suspects who could have made an input that caused the output. If we've done a good job of solving the first problem then there are many possible inputs per output, so the set of suspects for each output is large. But the leaker probably appears in more of those sets than anyone else, so the adversary counts how times each suspect appears. The longer the series of outputs, the more likely it is that the leaker will stand out. In the anonymity literature, attacks like this are called intersection attacks or disclosure attacks, and they're very effective. You're not going to prevent them with a simple approach like random delays. Cheers, Michael On 20/08/13 20:31, Fabio Pietrosanti (naif) wrote: Hi all, at GlobaLeaks we are going to implement a feature that want to mitigate time correlation attacks between a Whistleblower submitting something and a Receiver, receiving a notification that there's a new leak outstanding to be accessed. We already had a internal discussion and received some valuable suggestions and comments available here https://github.com/globaleaks/GlobaLeaks/issues/264 . However being the argument possibly tricky, we would like to subject to suggestion, criticism and review the proposal. That's a summary of the context: Overview When a whistleblower submits to a globaleaks node all receivers that they have selected as recipients for their submission will receive a notification informing them that a new submission has occurred. Other whistleblower interactions also trigger a notification (that should therefore be protected from timing attacks) and such interactions are: * A new comment is added to an existing submission by a WB * A new comment is added to an existing submission by a Receiver * A new file is uploaded to an existing submission by a WB Goals We are interested in mitigating correlation attacks based on the dispatching of notifications for interactions performed by a whistleblower. It should not be possible (or harder) for an attacker to determine which person is a whistleblower for a certain submission based on their capabilities (more on that below). Adversary model A Their goal is to find which user has performed a certain submission on a globaleaks node. This adversary has the following capabilities: * They can read the content of notification messages. * They can perform a new submission to a globaleaks node and therefore trigger notifications (i.e. they are capable of doing a /flooding/ /blending/ attack) * A log of traffic from N users they suspect to have blown the whistle. This log includes the timestamp of when the request was made, the response was received and the size of the payload. * The log of the notification traffic. This includes the timestamp of when the notification was dispatched and the size of it. The content of the notification will be either encrypted (model A) or plaintext (model B). Adversary model B This adversary has all the capabilities of the above adversary, but they do not have the ability of reading the content of the notification messages. Adversary model C All of the above except the receiver is not trusted: their goal is to de-anonymise the WB. Is this any different from Adversary A, that is an adversary that has the ability to read the notification emails because they are not encrypted? Example real world scenario The GL node is a GL node for a private company. The adversary is a Manager of The Company that wants to find out who blew the whistle on the fact that he is recycling money through a shell company in the island of mann.
Re: [cryptography] urandom vs random
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 20/08/13 07:08, ianG wrote: On a related point, what name do we give to the design/pattern for entropy sources == mix/pool == deterministic expansion function ? I was asked this seconds after tasking my intern to build one :-/ Seems like HKDF's extract-then-expand terminology might be appropriate here, albeit in a slightly different context. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSE0tnAAoJEBEET9GfxSfMm+kIAIqGmzYYBigujiLsjJqkhfAF JpdMmUHIlH/SP2U/Vz+qMf3Hp/4dLiw8iIcUherJVylRvBUT/ngA+Roc65pQXlkC PdPKzu1HECIFMyYXx1wQtNFAdNfNHFgKSV/rDyR/F/kf4MRDkALKHyWSImu3xyee FKeZnb6PEGa+KLGwJ9CaQqsCYjy/95jBPAFhMdH0qpwGozQrvtoy9TuubZKARu85 O/QvLI/TrzE1J9orOQNCsDxGDSLa4Dx/ElyqqieIhdwbK4A/fN1EgnyTyJ+e+1Yf HefIN1y7DXTY91d2BZncIygKZgzMdsFNLAMnw1UsiWvwmFTWB8/w6+tHteolj6s= =g2GX -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] HKDF salt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I wonder if anyone on the list can help me to understand the purpose and correct use of HKDF's salt parameter. RFC 5869 has this to say: HKDF is defined to operate with and without random salt. This is done to accommodate applications where a salt value is not available. We stress, however, that the use of salt adds significantly to the strength of HKDF, ensuring independence between different uses of the hash function, supporting source-independent extraction, and strengthening the analytical results that back the HKDF design. Random salt differs fundamentally from the initial keying material in two ways: it is non-secret and can be re-used. As such, salt values are available to many applications. For example, a pseudorandom number generator (PRNG) that continuously produces outputs by applying HKDF to renewable pools of entropy (e.g., sampled system events) can fix a salt value and use it for multiple applications of HKDF without having to protect the secrecy of the salt. In a different application domain, a key agreement protocol deriving cryptographic keys from a Diffie-Hellman exchange can derive a salt value from public nonces exchanged and authenticated between communicating parties as part of the key agreement (this is the approach taken in [IKEv2]). My understanding of the above is that the salt doesn't increase the entropy of HKDF's output from the adversary's point of view, since the adversary knows the salt value. However, the salt prevents accidental collisions if identical initial keying material is used in multiple application domains. Is that right? Can anyone shed light on the meaning of source-independent extraction? The RFC continues: Ideally, the salt value is a random (or pseudorandom) string of the length HashLen. Yet, even a salt value of less quality (shorter in size or with limited entropy) may still make a significant contribution to the security of the output keying material; designers of applications are therefore encouraged to provide salt values to HKDF if such values can be obtained by the application. This doesn't sit well with my interpretation above, because it suggests that the salt contains entropy (from someone's point of view) that contributes to the security of HKDF's output. But how can the salt be said to contain entropy when its value is non-secret? It is worth noting that, while not the typical case, some applications may even have a secret salt value available for use; in such a case, HKDF provides an even stronger security guarantee. An example of such application is IKEv1 in its public-key encryption mode, where the salt to the extractor is computed from nonces that are secret; similarly, the pre-shared mode of IKEv1 uses a secret salt derived from the pre-shared key. This seems unsurprising - if the salt value is unknown to the adversary then clearly it can contribute entropy to HKDF's output. Going back to the issue of non-secret salt, here's a thought experiment: we generate a random salt value, publish it in the New York Times, and use it for all calls to HKDF in a certain application domain. Is this somehow more secure than using no salt? If so, can you help me to understand how? Less extremely: each time we use HKDF, we generate a fresh random salt value and publish it in the New York Times. Is this more secure than using no salt? How? Thanks, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJR+ieDAAoJEBEET9GfxSfMVsIH/3dsAhF4FukIcdVLa/Kw782A akbTjnYHAvwdvRi3fVBrXejM3csya9psSu2qVIgAUXWaMxRVcvPkUoTc7NF+MC65 xVS4j1YcmkEQL7L7LnUQVukISzBO3NgwmAKPrxdzeXLJlaiL9N51ecYmjC0jo9Ou dHs9108z2AQHYZ/n4PhRCVdSPjIA5/Z6kusu6cOQsZHTzeNbmoTuOafZTHFkESbX TmSVS4m54vgQWukTsjGsHDDoemvGzY4ahfZj8l+oOSr3OUP3MdYaxaQEXxq6ZQ3L fdNkdxnpOznz+e14RQzIOFjr8QbWBjwlGFp5CxaMPgKL9a5cKuU9JIxjLsUWyXs= =ZaC7 -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] HKDF salt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks Ian! I hadn't considered dictionary attacks because I was assuming the initial keying material had enough entropy to make them impractical. But now I can see that was my assumption, not the HKDF designers'. Cheers, Michael On 01/08/13 10:41, ianG wrote: In general: the purpose of the salt technique is to stop dictionary attacks. Say you have a password 'fred' and the hash function is a variant of DES [0]. It is possible to calculate the DES hash of 'fred' and store that. Then, in every system, I can simply read the hashed passwords by cat /etc/passwd [0] and compare to known results in my dictionary. However, if the hash function combines 'fred' with salt 948375384 and then stores the two together in the file, the dictionary attack fails. In effect, the space is expanded so dramatically that I can no longer calculate 'fred' with every possible salt and store it, economically. [0] these things were true a long time ago... in more particular: On 1/08/13 12:16 PM, Michael Rogers wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I wonder if anyone on the list can help me to understand the purpose and correct use of HKDF's salt parameter. RFC 5869 has this to say: HKDF is defined to operate with and without random salt. This is done to accommodate applications where a salt value is not available. As a quibble, this is a bad idea. It should be designed this way: HKDF is defined to operate with a salt, always. Where applications cannot provide a salt, a zero-filled salt should be supplied. This is a question of software engineering, and robustness. We stress, however, that the use of salt adds significantly to the strength of HKDF, ensuring independence between different uses of the hash function, supporting source-independent extraction, and strengthening the analytical results that back the HKDF design. Random salt differs fundamentally from the initial keying material in two ways: it is non-secret and can be re-used. As such, salt values are available to many applications. For example, a pseudorandom number generator (PRNG) that continuously produces outputs by applying HKDF to renewable pools of entropy (e.g., sampled system events) can fix a salt value and use it for multiple applications of HKDF without having to protect the secrecy of the salt. In a different application domain, a key agreement protocol deriving cryptographic keys from a Diffie-Hellman exchange can derive a salt value from public nonces exchanged and authenticated between communicating parties as part of the key agreement (this is the approach taken in [IKEv2]). My understanding of the above is that the salt doesn't increase the entropy of HKDF's output from the adversary's point of view, since the adversary knows the salt value. Yes. However, the salt prevents accidental collisions if identical initial keying material is used in multiple application domains. Not accidental, but calculated in advance. Is that right? Can anyone shed light on the meaning of source-independent extraction? hmmm... The RFC continues: Ideally, the salt value is a random (or pseudorandom) string of the length HashLen. Yet, even a salt value of less quality (shorter in size or with limited entropy) may still make a significant contribution to the security of the output keying material; designers of applications are therefore encouraged to provide salt values to HKDF if such values can be obtained by the application. This doesn't sit well with my interpretation above, because it suggests that the salt contains entropy (from someone's point of view) that contributes to the security of HKDF's output. But how can the salt be said to contain entropy when its value is non-secret? The entropy is provided to ensure lack of collisions in selection. If everyone selects from a good random source, then there is a good spread across the space, enlarging the task of dictionary attacks. It is worth noting that, while not the typical case, some applications may even have a secret salt value available for use; in such a case, HKDF provides an even stronger security guarantee. An example of such application is IKEv1 in its public-key encryption mode, where the salt to the extractor is computed from nonces that are secret; similarly, the pre-shared mode of IKEv1 uses a secret salt derived from the pre-shared key. This seems unsurprising - if the salt value is unknown to the adversary then clearly it can contribute entropy to HKDF's output. Going back to the issue of non-secret salt, here's a thought experiment: we generate a random salt value, publish it in the New York Times, and use it for all calls to HKDF in a certain application domain. Is this somehow more secure than using no salt? If so, can you help me to understand how? No, because
Re: [cryptography] A secret sharing consensus protocol (or leader election protocol)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony, The following article talks about using secret sharing and threshold signatures to make quorom decisions in a distributed system: L. Zhou and Z.J. Haas, Securing ad hoc networks. IEEE Network 13(6):24?30, November 1999. http://people.ece.cornell.edu/haas/Publications/NM-zhou-haas-1999-11+12.pdf Cheers, Michael On 19/07/13 04:57, Tony Arcieri wrote: Has there been any work with combining Shamir-style secret sharing with consensus protocols like Paxos and Raft (or leader election protocols like Omega Meets Paxos)? The idea would be to have a network of n peers, who share a secret where t=2 shares are required to reassemble the original secret. This secret is used to sign new values when a group consensus is reached via a Paxos-like protocol. In this scheme, a proposer would give its secret share, along with a proposed new value, to acceptor nodes, who can reassemble the entire secret. If they accept the new value, they can sign it with the secret, then immediately erase it. If we use a deterministic signature algorithm like Ed25519, every acceptor taking part in the consensus protocol can produce the same signed version of the proposed new value. They can then continue with the consensus protocol's accept phase. The result will be a quorum on a signed value (or a consensus failure if quorum can't be reached, of course) Let's assume a malicious entity gains control of one and only one of the nodes. They are now able to propose new values, so they can manipulate the peer network by proposing malicious values which will get accepted by the rest of the group. However, they do not *immediately* learn the private key. They would only learn the private key if any other node were to propose a value which contained their secret share. -- alternatively -- Secret sharing could be combined with a leader election protocol. In this scheme, the leader and only the leader would learn the shared secret. All proposed values would have to be approved and signed by the leader. I'm not sure I like this as much though. The leader is a single point of failure, and an attacker could maliciously force a leader election through e.g. DoS, having compromised only one other host directly. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJR6RG2AAoJEBEET9GfxSfMOBkH/ii34FKcPrXnOp7nJJlgROlZ MbCv/lf2dzevVgWwCpCnm1bAPkRxl/pDuvTFS+BcvaBnNcDIiuEF7HiT92MQrUAH XPBxnJwuwQa/TFCSXlfu3uX99XZMWiUBKVZKjJAksBKeeCneGlkmQQRvwFwASSBG a8NREeca97041xAXxQfZ9KOwidWz5GfDlY81BZEZGw44ld9DxQaiJDCujOhc2ul5 RvRGQ7oJUMyNnQNM/7uAxt5fkSiBtPpOH+CKH0wMRHjPemmHIT8+E8914pkeXYN4 7KqWYSV1Xpv50HEOTqenHapGD7kb87D6zzdpqdW7OSndCG1ENu5NkqdxV5B5iEA= =DlFK -END PGP SIGNATURE- ___ 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 04/07/13 13:34, danimoth wrote: 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. I think the point is that i2p's decision to use a decentralised directory service led to the vulnerabilities described in the paper. 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. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJR1ZS7AAoJEBEET9GfxSfM8uMH/2YtCTowxckwougMGb+9Sx4+ b0hgxBUGSwoowIACGCr5uFbKEWUTCK53q0h24qdbUejdjaiehiZh0MzaoL/HWIq3 T3993RRvDV8bDXdEJ6oOh9zwZLS2Y7IeOvJLipJjBrR0P9kkoXP0d9KHUxAARZE9 6zIhp+Dr6NHoqUL7u1mM8s9JmJ/4z2Mbb6q7Rtx1e3uZG23prxkOd1V/9OwOBgly Df3f1En6kuAs1nHD0fmP+OrNEMVR+edoQdOdSNVtkhjrtZEe1kT1ycZBT4dTof0Y WdInJPXu0vGDRcwxQxnm+I77iQA+CeQi2NmreBo7BGeZLRecLt3d0BKDrE3UaFo= =tPPD -END PGP SIGNATURE- ___ 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 04/07/13 17:15, danimoth wrote: 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. As far as I can see, the attacks work by seizing control of the netDB, which is i2p's decentralised directory service. We first show how an attacker can tamper with the group of nodes providing the netDB, until he controls most of these nodes. To mount a similar attack against Tor, the attacker would have to compromise the directory authorities that sign the network consensus. As far as we know that hasn't been done, so i2p's decision to use a decentralised netDB instead of centralised directory authorities has the practical effect of making these attacks possible. I don't see any reference to Tor in section 5 of the paper - perhaps we're looking at different versions? 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. I agree that we should always keep in mind that there are vulnerabilities we don't know about. However, we still have to make day-to-day decisions about which systems to use based on the vulnerabilities we do know about. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJR1aZqAAoJEBEET9GfxSfM9ZkH/j6WnVh5gWyLI7ILi78dMFmj tU08GelNbIUblsi4YauJ8vdrRf2Z2go7fAnYxcObWl9zwN0/OdyVj+HOzi9nzn+g nZnL6C+2ZXw7QjqyiarrgYeiYH2AF9Ff5Ndk0AQ5w9EQb/ApXQWIczY62CkLdgEn viSSJoUjXTONPE3fRkE8S7fA21BFLo3tkyJKCjJ4A0Xxvj4VQexK4NYLeyhgr1NY 7RqJgtkYqnPDkjC/Rs//PQwooAmjnRRgXxyB8/rn0xlwizNc+Fgur0/j5clXIYqL SXlCwSrNxUwWFtIa/g+Nf1B6BOJL8fQDsE+h/l6UTfbSJOXpewbVdos4Qco7ZNE= =QELT -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DeCryptocat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/07/13 22:07, James A. Donald wrote: 106 bits is still far too small. Seems to me that they only increased it as needed to defeat DecryptoCat, not as needed to defeat an NSA farm running dedicated special purpose hardware. Why not use an elliptic curve whose points are, in compressed form, about 256 bits, which is the size I chose for Crypto Kong, many, many years ago, when computers were far less powerful. I chose that after looking at various cracking efforts as the minimum size that I was pretty sure that the NSA could not beat, then or in the reasonably near future. The choice of curve wasn't the problem - they were using Curve25519 but messing up the random number generation. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJR1eafAAoJEBEET9GfxSfMfWwH/R/Rq/I02dMcmheZuIStT8lG dwTnBM7ZLqXywpvVjS4SDKDTcSC8EfrFx/QW2906VTqMDn5wNePe9BZegsZGIP5Q C+R/Kz8ahaUdJMbwHI0FrwdvrkCot1K8L8qWacUf/osZ/uP0Xrx7CEqk0Xi7OFLu jFTyj5hjSUWg7MctNfmCn6ElMaMO81Fc91aZGKxLRw4z7XBOSBGhcEuXoTpuQAAI 2Y7CkhXhuvdW1DpneD0EXRiyM0DK0/OKOQwoTvfHQXzHubss50Ke0OlqEiAhzRzw BPCTlVMCKF0dmgL7/EZ7Z60/JxSCRJ847uN1P76POEw+Ez9akzvaC9S/lveLyEs= =BggH -END PGP SIGNATURE- ___ 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
-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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30/06/13 20:32, Jacob Appelbaum wrote: Michael Rogers: 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. I'm not sure if I understand you right, but it sounds like you think I was saying that Tor is only designed for sender anonymity, and that sender anonymity isn't useful in general. I wasn't saying either of those things. My point was much smaller in scope: remailers have tried to provide sender anonymity for email, but in the current climate that's useful to fewer people than unlinkability for email, which a remailer-like system could provide more easily than sender anonymity. By all means let's build that remailer-like system on top of Tor, if it can be done in such a way that the low-latency and high-latency traffic share anonymity sets. If on the other hand it's effectively two different networks sharing an implementation then it might make sense to build a separate system. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJR0sYGAAoJEBEET9GfxSfMVDEIALPCMHLloyB76MSSonEPyLOU 4Nc/mMDD5w4uYxfMh5ynfQb7b1KqRcYZjK+AMJudj/1CRrHdVbKSKm2sxiJleFSu w6/CQ05T10jrsEFkALPgMF8mMERGIRc0S1HXPGpZgNW1PrjGdsTpVYa+z83/VBg2 50deiWPfSY1EctAavun2Zzble/VMwQOjJcu+ElOE6d9zyQIDe5SmsMhryf2775eV ySU0fQALd3NP+o5Vsw9WlHc5JjHtopYFXvwEGvnrssggyepVTTN8ovKBsEIgtQ7Z FmPzs2v2XZD+L75M8L15d3MtnGahxnlnscScOXHCsZtLwO/5rLc7nhwzaUQam5k= =XGbu -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Potential funding for crypto-related projects
So who's out there developing any useful protocols for anonymization today? *Anybody*? Could we try to start a new project (if needed) to create one? 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). Cheers, Michael ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Client TLS Certificates - why not?
I don't think most non-programmers would differentiate between a string of hex digits and an arbitrary alphanumeric string, so you might as well use base 32. But do you really need to encode more bits? With a ZRTPish hash commitment / key exchange / confirmation code structure you can detect a MITM attack with probability 1 - 1/2^b, where b is the number of bits in the confirmation code. A 19-bit code fits into six decimal digits and fails to detect a MITM attack with a probability less than one in half a million, which strikes me as a good tradeoff between convenience and security. Cheers, Michael ianG i...@iang.org wrote: On 6/03/13 14:33 PM, StealthMonger wrote: Your only argument is that the key ID is longer or more random. This of course is the ZT challenge. The issue isn't that Zooko's Triangle can or can't be squared, but that we the developer have to square it [0]. A solution is redesign of the hash code so it doesn't have to be so long plus maybe merchant generating and discarding lots of keys until stumbling on one with a pronounceable hash. I'm currently working on an invite process from phone to phone. For now I'm just using 6 char hex codes (24 bits). There's an easy MITM possibility here, which is fineessed by human processes, time and code space. But once the invite process is over, assuming no MITM, the phones are locked together (in that the internal addressbooks know each other at 1st class crypto level). I am musing on whether to go to Base 32, like the airline reservation codes. That seems to be workable, in that I personally manage to not miss my plane most of the time. Has anyone got any view as to how complicated a handshake code could be before users start making more mistakes than it is worth? iang PS: in stricter metaphorical terms, we are pyramiding the triangle into a 4 sided die, but squaring sounds easier on the ear. ___ 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] Bitmessage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 20/02/13 02:49, Jonathan Warren wrote: Suppose when Alice firsts sends a message to Bob she also includes a short term public key. Bob takes the short term public key and encrypts symmetric_key_1 (SK1) and also encrypts a message with SK1 and sends the encrypted SK1 and the encrypted message to Alice. Alice decrypts the encrypted SK1 with her short term private key and then uses SK1 to decrypt the message. The short term public key pair can now be deleted. When Alice replies, she sends the message and a new SK2, encrypted with SK1, to Bob. Bob will decrypt with SK1 and store SK2. When he sends a message, he encrypts his message along with a new key, SK3, with SK2. This continues with a new symmetric key each time. Both parties must remember the last SK that they suggested to the other party, and also the last SK that they received from the other party. All others can be deleted. This is quite close to what OTR does, except that instead of sending a public encryption key, OTR sends a public DH key and derives the encryption and MAC keys from the most recently received DH keys. You could do the same here, and make the first and last messages forward secret by adding setup and teardown phases. In fact you could reuse OTR in a store-and-forward context, as far as I can see. Like OTR, the forward secrecy properties of what you desrcibe depend on the frequency of communication in both directions: if Alice sends messages to Bob but Bob never replies, Alice doesn't receive any new keys for Bob, so she can't delete Bob's public key and he can't delete his private key. I didn't like that constraint when I was designing the transport protocol for Briar, so I opted for a design based on periodic replacement of symmetric keys using a one-way key derivation function instead: https://fulpool.org/btp.pdf Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJRJKpwAAoJEBEET9GfxSfMg4oH/AjIu3pblvnC1nbY7RNy+rzH 88jm74jBi9Bp2OEBFnrA4cMqsJTmxwhCrB31GoT0EohU98BDsLDdgmWjJNxki1+2 1+cy29cxX6ySZiLgw39n1oO88RAqfK2N3zmd6kH933T0GYkjWH74Rcnp5/PUi/iy nlw0qXsdwW5iMoeiVhN44pzBjqlIyeNlBslu+gfNBC66ab2rbjHPkW8iNsjBz6yE fAB5xtnlznVY5DmNsqGsleDOD5tRE0pCjKE5ZO36WFo3jcelwtyPXuIheuggVq1Y kZZp+cRigLUCqPGkv6HodUDk9QRDt0Edc2qvOk2K2nLNAomA6OQGWeMRC4dKEi0= =YiEQ -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Bitmessage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 20/02/13 02:49, Jonathan Warren wrote: Suppose when Alice firsts sends a message to Bob she also includes a short term public key. Bob takes the short term public key and encrypts symmetric_key_1 (SK1) and also encrypts a message with SK1 and sends the encrypted SK1 and the encrypted message to Alice. Alice decrypts the encrypted SK1 with her short term private key and then uses SK1 to decrypt the message. The short term public key pair can now be deleted. When Alice replies, she sends the message and a new SK2, encrypted with SK1, to Bob. Bob will decrypt with SK1 and store SK2. When he sends a message, he encrypts his message along with a new key, SK3, with SK2. This continues with a new symmetric key each time. Both parties must remember the last SK that they suggested to the other party, and also the last SK that they received from the other party. All others can be deleted. Sorry, after re-reading what you wrote I've realised it's not as close to OTR as I thought. Apologies for the noise. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJRJKsrAAoJEBEET9GfxSfMtLwH/0xliQcJXttefH/mt6BCDGCK aXH2JhLldlQ8yWqfhjMDBhyBGJsQK/Karhrct7GLFzTZJm45rxZHnRaWLy5tdMVF 6zTZAOyAQgzFnvoNClQU0CwexY2/rfZyW4+VAEu9DDStlIWqRDQSki8XONUozLMV xcK9qHMzFihtjmdpeVKdjba3jWgn37FPHW0pviCwoNfxVuTRpRf2tPpH+se6PB2/ tFMqezgOS+xL30er9mQvl5SXAz8vQCydAHnhryYMFGFimlSXSAGG3iO6dpN4JwXB q0t2GXG90zk54F0yLuYQDfnnGZ9appLgmfko6XJlb1KEm30V79vtKI/P9hT4P4c= =zyVD -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Bitmessage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jonathan, This looks like it could be a useful system, but I'm not sure I fully understand it. Each node is assumed to have a slowly changing set of addresses, is that right? A node migrates between streams by choosing whether to create new addresses in its current stream or a child of its current stream; when it has no more addresses in the current stream, the child stream becomes its current stream. So if addresses identify users, does that mean each node is assumed to have a slowly changing set of users (like a mail server, say, rather than a personal computer)? Or does each user change addresses over time? When a node first enters the network, how does it decide which stream to join? When a node leaves the network, a stream may be left empty. What happens if stream 1 (or any other non-leaf stream) becomes empty? Can a node in a leaf stream that wants to send a message to a node in another leaf stream still find a suitable node to connect to? Section 5 of the paper says that all users receive all messages. But that's no longer true once the network has divided into streams, right? So how does a broadcaster ensure that all subscribers receive her messages? It might be worth looking at P5, which uses some similar ideas: http://www.cs.umd.edu/projects/p5/p5-extended.pdf Also, some analysis of proof of work as a means of limiting spam: http://www.cl.cam.ac.uk/~rnc1/proofwork2.pdf I seem to remember a DHT-based system where messages could be addressed to all nodes with a given identifier prefix (of any length), but I can't find the reference. Cheers, Michael On 16/02/13 18:49, Jonathan Warren wrote: Hello everyone, I would like to introduce you to a communications protocol I have been working on called Bitmessage. I have also written an open source client released under the MIT/X11 license. It borrows ideas from Bitcoin and Hashcash and aims to form a secure and decentralized communications protocol which also doesn't rely on trust. Criticism of the X.509 certificate system is understandably common in this listserv (and also increasingly common in more public forums); Bitmessage instead uses Bitcoin-like addresses for authentication. It has a 'broadcast' and 'subscription' feature which other people have described as a decentralized Twitter and also aims to hide non-content data, like the sender and receiver of messages, from passive eavesdroppers like those running warrantless wiretapping programs. It may also be possible to be strong against active attackers although I'm not yet making that claim. A primary goal has been to make a clean and simple interface so that the key management, authentication, and encryption is simple even for people who do not understand public-key cryptography. I'm sure that there is quite a bit of demand for such a program and protocol although I am currently not actively promoting it because it has not been independently audited. I would be interested to hear your comments. The website https://bitmessage.org links to various resources like a short whitepaper describing how the protocol works and what its goals are ( https://bitmessage.org/bitmessage.pdf ) and the source code on Github ( https://github.com/Bitmessage/PyBitmessage ). The main source code file is bitmessagemain.py. Bitmessage is written in Python and uses an OpenSSL wrapper called pyelliptic (written by a different individual) to implement ECIES and ECDSA. Again I look forward to hearing comments; it is always easier to change or add to a protocol earlier than it is later. All the best, Jonathan Warren ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJRI3OzAAoJEBEET9GfxSfMzOkH/29tjxyzO2g949Pk8yM2V+lZ Sqd2BeamgzYoz3QCS5iwDjhgJedguNS0/CzTwzDW56mEzYKkqZPdfZlKR2s541hA Y10++AOy9yyumAZypAGD/0HDDRftMs4iUoZZbOlm6jB4Ul8Al5iHeNL2r1VIPaU/ pmP1cbUi8yLC86POmjMARfvbiAX4+G3EYxb+lKaZleFMg8cCoo07Ur6Po7mdTtkz nMkuNsmBgzUoaGHejB2tAe6B5QQNsqazFEK1UK/wg9829CedF6l1UKMFy5iDNIJa 60zQ9U0+SDnd0RedeR45pYIPKmPI4pGEp4COyv/n2derzRY52P1TrHx/T7jkx9k= =4oMp -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
