Re: [cryptography] LeastAuthority.com announces PRISM-proof storage service
On Thu, 15 Aug 2013 13:11, wasabe...@gmail.com said: To: and From: headers leak the emails/identity of communicating parties, but it's not the only place that happens. I've never used PGP but I've used OpenPGP allows sending messages without information on the used keys (e.g. gpg --throw-keyids). Folks using many secret keys need to have a bit more patience due to the required trial decryptions. keywrap structure. If the email is present, it will leak even if To/From were protected somehow. Even if the email is not present, maybe the cert A mail can easily be wrapped into an message/rfc822 container along with more innocent outer headers. This would allow to keep on using the existing mail infrastructure. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] urandom vs random
I thought that decent crypto programs (openssh, openssl, tls suites) should read from random so they stay secure and don't start generating /insecure/ data when entropy runs low. The only way I could see this as being a smart thing to do is if these programs also looked at how much entropy the kernel had and stopped when it got ~50 or so. Is this the way things are done when these programs use urandom or what? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
I think the programs block when reading from random, if the kernel doesnt have enough entropy. When reading from urandom, that is not the case. Basically the internal pool is reused to generate pseudo random bits so that the call doesnt need to block. As far as I know, there is no measure like 50 or so for /dev/random. On 16-Aug-2013, at 6:32 AM, shawn wilson ag4ve...@gmail.com wrote: I thought that decent crypto programs (openssh, openssl, tls suites) should read from random so they stay secure and don't start generating /insecure/ data when entropy runs low. The only way I could see this as being a smart thing to do is if these programs also looked at how much entropy the kernel had and stopped when it got ~50 or so. Is this the way things are done when these programs use urandom or what? ___ 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] urandom vs random
On Fri, Aug 16, 2013 at 10:03 AM, Swair Mehta swairme...@gmail.com wrote: As far as I know, there is no measure like 50 or so for /dev/random. /proc/sys/kernel/random/entropy_avail ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Expired/Revoked certificates + private keys
On Fri, Aug 16, 2013 at 11:03 AM, Dominik Schürmann domi...@dominikschuermann.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 For a research project on OCSP, we are searching for expired and revoked X.509 certificates with their corresponding private keys. Any help or pointers to find leaked keys are much appreciated. littleblackbox (http://code.google.com/p/littleblackbox/) is a database of well known private keys from a number of devices and appliances. As far as I know, most have never been revoked (or the device/appliance updated) even though they are well known. Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 6:32 AM, shawn wilson ag4ve...@gmail.com wrote: I thought that decent crypto programs (openssh, openssl, tls suites) should read from random so they stay secure and don't start generating /insecure/ data when entropy runs low. This presumes that urandom is somehow more insecure, which is not the case despite the ancient scare-language in the manpage. The security of all stream ciphers rests in secure CSPRNGs. Meanwhile, /dev/random is not robust: https://cs.nyu.edu/~dodis/ps/rng.pdf -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 11:42 AM, Tony Arcieri basc...@gmail.com wrote: On Fri, Aug 16, 2013 at 6:32 AM, shawn wilson ag4ve...@gmail.com wrote: I thought that decent crypto programs (openssh, openssl, tls suites) should read from random so they stay secure and don't start generating /insecure/ data when entropy runs low. This presumes that urandom is somehow more insecure, which is not the case despite the ancient scare-language in the manpage. The security of all stream ciphers rests in secure CSPRNGs. Meanwhile, /dev/random is not robust: https://cs.nyu.edu/~One of the prdodis/ps/rng.pdfhttps://cs.nyu.edu/~dodis/ps/rng.pdf -- Tony Arcieri Not for nothing, but that refers to both random and urandom, showing one problem with the entropy estimation, and another with the pool mixing function. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 12:03 PM, Tony Arcieri basc...@gmail.com wrote: On Fri, Aug 16, 2013 at 8:47 AM, Patrick Mylund Nielsen cryptogra...@patrickmylund.com wrote: Not for nothing, but that refers to both random and urandom, showing one problem with the entropy estimation, and another with the pool mixing function. Finally, we propose a simple and very efficient PRNG construction that is provably robust in our new and stronger adversarial model. We therefore recommend to use this construction whenever a PRNG with input is used for cryptography. Yes, but they aren't talking about urandom. Your reply made it sound like random is weak, but the paper points to both (as urandom is seeded by random), and they propose a new AES-based PRNG that accumulates entropy properly. Here's the whole conclusion: We have proposed a new property for PRNG with input, that captures how it should accumulate the entropy of the input data into the internal state. This property actually expresses the real expected behavior of a PRNG after a state compromise, where it is expected that the PRNG quickly recovers enough entropy. We gave a precise assessment of Linux PRNG /dev/random and /dev/urandom security. In particular, we prove that these PRNGs are not robust. These properties are due to the behavior of the entropy estimator and the mixing function used to refresh its internal state. As pointed by Barak and Halevi [BH05], who advise against using run-time entropy estimation, we have shown vulnerabilities on the entropy estimator due to its use when data is transferred between pools in Linux PRNG. We therefore recommend that the functions of a PRNG do not rely on such an estimator. Finally, we proposed a PRNG with input construction that meets our new property in the standard model. We therefore recommend to use this construction whenever a PRNG with input is used for cryptography And from the introduction: On a practical side, we give a precise assessment of the security of the two Linux PRNGs, /dev/random and /dev/urandom. In particular, we prove that these PRNGs are not robust and do not accumulate entropy properly. These properties are due to the behavior of the entropy estimator and the internal mixing function of the Linux PRNGs. We also analyze the PRNG with input proposed by Barak and Halevi. This scheme was proven robust in [BH05] but we prove that it does not generically satisfy our expected property of entropy accumulation. On the positive side, we propose a PRNG construction that is robust in the standard model and in our new stronger adversarial model. There is a much more in-depth comparison starting in section 5.1. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] LeastAuthority.com announces PRISM-proof storage service
On Tue, Aug 13, 2013 at 03:16:33PM -0500, Nico Williams wrote: Nothing really gets anyone past the enormous supply of zero-day vulns in their complete stacks. In the end I assume there's no technological PRISM workarounds. I agree that compromise of the client is relevant. My current belief is that nobody is doing this on a mass scale, pwning entire populations at once, and that if they do, we will find out about it. My goal with the S4 product is not primarily to help people who are being targeted by their enemies, but to increase the cost of indiscriminately surveilling entire populations. Now maybe it was a mistake to label it as PRISM-Proof in our press release and media interviews! I said that because to me PRISM means mass surveillance of innocents. Perhaps to other people it doesn't mean that. Oops! Regards, Zooko ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] LeastAuthority.com announces PRISM-proof storage service
On Tue, Aug 13, 2013 at 01:52:38PM -0500, Nicolai wrote: Zooko: Congrats on the service. I'm wondering if you could mention on the site which primitives are used client-side. All I see is that combinations of sftp and ssl are used for data-in-flight. Thanks! I'm not sure what your question is. The available interfaces to the gateway -- i.e. the cleartext side that is marked in red on [1] -- are: * the tahoe command-line tool [2] * your unadorned web browser, even with JavaScript turned off, pointed at the gateway over localhost (or over SSL to a remote host, or whatever you want) * your FTP or SFTP client * FUSE (although in a Rube Goldberg-esque setup where FUSE is chained to the aforementioned SFTP server through the sshfs tool; Like a Rube Goldberg device, it actually does work once you get all the pieces set up next to each other.) The semantics of what you can do with this are described in summary here: https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/about.rst#access-control And in much more detail in the documentation pages linked from there. Does that answer your question? Regards, Zooko [1] https://tahoe-lafs.org/trac/chrome/LAFS.svg [2] https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/frontends/CLI.rst P.S. This is a test of charset handling through GNU screen, mutt, and GNU mailman: ?? (That should be a superscript 1.) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 9:18 AM, Patrick Mylund Nielsen cryptogra...@patrickmylund.com wrote: Yes, but they aren't talking about urandom. Your reply made it sound like random is weak, but the paper points to both (as urandom is seeded by random), and they propose a new AES-based PRNG that accumulates entropy properly. I'm not sure if you feel the same way, but the opinion of many uneducated observers[1] seems to be that using a PRNG at all in these contexts is insecure when that is absolutely not the case, and for the most part there isn't a meaningful difference between the security of random vs urandom except that random will run out of entropy. The urandom is insecure claims are specifically what I was trying to challenge, and I hope this paper helps drive it home. If urandom is insecure it isn't more so than /dev/random [1]: http://arstechnica.com/security/2013/08/google-confirms-critical-android-crypto-flaw-used-in-5700-bitcoin-heist/?comments=1post=25102733#comment-25102733 -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] LeastAuthority.com announces PRISM-proof storage service
On Fri, Aug 16, 2013 at 2:11 PM, zooko zo...@zooko.com wrote: On Tue, Aug 13, 2013 at 03:16:33PM -0500, Nico Williams wrote: Nothing really gets anyone past the enormous supply of zero-day vulns in their complete stacks. In the end I assume there's no technological PRISM workarounds. I agree that compromise of the client is relevant. My current belief is that nobody is doing this on a mass scale, pwning entire populations at once, and that if they do, we will find out about it. That's fair, and true-enough, although you never know. pwning everyone is a very costly operation: you can only do it once for each pwn, and the political risks and costs are high enough to put the entire concept at risk. But we've seen actors take some breathtaking risks in recent years (e.g., Flame)... My goal with the S4 product is not primarily to help people who are being targeted by their enemies, but to increase the cost of indiscriminately surveilling entire populations. That's fair, and a point that I should learn to make in general. We saw China back down from banning github -- that's a big clue that sufficiently popular services have leverage against foreign governments, and possibly local ones too. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 3:30 PM, Tony Arcieri basc...@gmail.com wrote: On Fri, Aug 16, 2013 at 9:18 AM, Patrick Mylund Nielsen cryptogra...@patrickmylund.com wrote: Yes, but they aren't talking about urandom. Your reply made it sound like random is weak, but the paper points to both (as urandom is seeded by random), and they propose a new AES-based PRNG that accumulates entropy properly. I'm not sure if you feel the same way, but the opinion of many uneducated observers[1] seems to be that using a PRNG at all in these contexts is insecure when that is absolutely not the case, and for the most part there isn't a meaningful difference between the security of random vs urandom except that random will run out of entropy. Ignoring the veiled insult: I don't, but I still recognize that they're not identical (at least on Linux.) There's no meaningful difference in most cases, i.e. when nobody's observing the output, or if the CSPRNG has no biases. Using /dev/urandom in general is fine. Either way, that's beside the point. The urandom is insecure claims are specifically what I was trying to challenge, and I hope this paper helps drive it home. If urandom is insecure it isn't more so than /dev/random You replied with a link to a paper that states that both /dev/random and /dev/urandom have the same weaknesses, and said that /dev/random isn't robust. Neither of them are, so what the paper drove home is that both have vulnerabilities, not that /dev/random is worse than /dev/urandom (which must clearly be false since /dev/urandom is a PRNG seeded by /dev/random.) That is all I'm pointing out. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 12:49 PM, Patrick Mylund Nielsen cryptogra...@patrickmylund.com wrote: You replied with a link to a paper that states that both /dev/random and /dev/urandom have the same weaknesses, and said that /dev/random isn't robust. I was quoting the title of the paper in the context of a thread in which someone claimed that /dev/random should be used in lieu of /dev/random. That's all I was pointing out. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 12:55 PM, Tony Arcieri basc...@gmail.com wrote: I was quoting the title of the paper in the context of a thread in which someone claimed that /dev/random should be used in lieu of /dev/random. That's all I was pointing out. Blah, /dev/urandom... -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] open letter to Phil Zimmermann and Jon Callas of Silent Circle, re: Silent Mail shutdown
also posted here: https://leastauthority.com/blog/open_letter_silent_circle.html This open letter is in response to the `recent shutdown of Lavabit`_ , the ensuing `shutdown of Silent Circle's “Silent Mail” product`_, `Jon Callas's posts about the topic on G+`_, and `Phil Zimmermann's interview in Forbes`_. Also, of course, all of this is unfolding in the context of the `2013 Mass Surveillance Scandal`_. Dear Phil and Jon: Hello there! It is good to have a chance to chat with you in public. Please accept the following in the spirit of constructive criticism in which it is intended. For those readers who don't know, I've known you both, personally and professionally for decades. You've each written texts that I've learned from, inspired me to follow your example, we've worked together successfully, and you've mentored me. I have great respect for your technical abilities, your integrity, and your general reasonableness. Thank you for the all of that and for holding fast to your principles today, when we need it more than ever. Now: Your job is not yet done. Your customers are currently vulnerable to having all of their communications secretly monitored. I just subscribed to the service at https://SilentCircle.com, and after I paid $120 for one year of service, it directed me to install the Silent Text app from Silent Circle on my android phone, which I did. Now, when I use that Silent Circle app to send text messages to other Silent Circle customers, I have no way of verifying whether it is really encrypting my message on my own phone, and if it is really keeping the encryption key only for me, or if it is leaking the contents of my messages or my encryption keys to you or to others. If some attacker, for example the U.S. Federal Government — or to pick a different example the Zetas Mexican drug cartel — were to coerce Silent Circle into cooperating with them, then that attacker would simply require Silent Circle to distribute an update to the app, containing a backdoor. There is no way for me to verify that any given version of Silent Text, including the one that I just installed, is correctly generating strong encryption keys and is protecting those keys instead of leaking them. Therefore, how are your current products any safer for your users that the canceled Silent Mail product was? The only attacker against whom your canceled Silent Mail product was vulnerable but against whom your current products are safe is an attacker who would require you to backdoor your server software but who wouldn't require you to backdoor your client software. Does that constraint apply to the U.S. Federal Government entities who are responsible for PRISM, for the shut-down of Lavabit, and so much else? No, that constraint does not apply to them. This was demonstrated in the Hushmail case in which the U.S. DEA asked Hushmail (a Canadian company) to turn over the plaintext of the email of one of its customers. Hushmail complied, shipping a set of CDs to the DEA containing the customer's messages. The President of Hushmail `emphasized`_ in interviews with journalists at the time that Hushmail would be able to comply with such orders regardless of whether the customer used Hushmail's “client-to-server” (SSL) encryption or its “end-to-end” (Java applet) encryption. .. _emphasized: http://www.wired.com/threatlevel/2007/11/hushmail-to-war/ Phil had been Chief Cryptographer of Hushmail years earlier, and was still a member of the Advisory Board of Hushmail at the time of that case. He commented about the case at that time, and he also `stated`_, correctly, that the Hushmail model of *unverified* end-to-end encryption was vulnerable to government coercion. That's the same model that Silent Circle uses today. .. _stated: http://www.wired.com/threatlevel/2007/11/pgp-creator-def/ You have just taken the courageous act of publicly shutting down the Silent Mail product, and publicly stating your reasons for doing so. This, then, is your opportunity to make your stance consistent by informing your customers of the similar dangers posed by the software distribution practices currently used by Silent Circle (along with most of the rest of the industry). I don't know the perfect solution to the problem of the *unverifiability* of today's software. But being frank about the current approach and the vulnerability that it imposes on users is the first step. People will listen to you about this, now. Let's start talking about it and we can start finding solutions. Also, warn your users. Don't tell them the untruth that it is impossible for you to eavesdrop on their communications even if you try (as your company seems to be on the borderline of doing in public statements like these: [ `¹`_, `²`_]). .. _¹: http://www.forbes.com/sites/parmyolson/2013/07/15/corporate-customers-flock-to-anti-snooping-app-silent-circle/ .. _²:
Re: [cryptography] urandom vs random
Aaron Toponce writes: Cryptographers don't like the idea that it's possible, even if it's excessively remote, and highly unprobable. This is why you see suggestions to use /dev/random for long term SSH, SSL and OpenPGP keys. Cryptographers are certainly not responsible for this superstitious nonsense. Think about this for a moment: whoever wrote the /dev/random manual page seems to simultaneously believe that (1) we can't figure out how to deterministically expand one 256-bit /dev/random output into an endless stream of unpredictable keys (this is what we need from urandom), but (2) we _can_ figure out how to use a single key to safely encrypt many messages (this is what we need from SSL, PGP, etc.). For a cryptographer this doesn't even pass the laugh test. I'm not saying that /dev/urandom has a perfect API. It's disappointingly common for vendors to deploy devices where the randomness pool has never been initialized; BSD /dev/urandom catches this configuration bug by blocking, but Linux /dev/urandom (unlike Linux /dev/random) spews predictable data, causing (e.g.) the widespread RSA security failures documented on http://factorable.net. But fixing this configuration bug has nothing to do with the /dev/random superstitions. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 7:24 PM, D. J. Bernstein d...@cr.yp.to wrote: I'm not saying that /dev/urandom has a perfect API. [...] It might be useful to think of what a good API would be. I've thought before that the Unix everything-as-a-file philosophy makes for lame entropy APIs, and yet it's what we have to work with... I'd like something like /dev/urandom128 - min. 128 bits of real entropy in the pool. I'd also wish open(2) of AF_LOCAL socket names were the same as a connect(2) on the same thing, and to block like named pipe opens do (why on Earth is this not so? what could possibly break if it were so? considering that named pipe opens block... one would think nothing could break). Then we could have each open of /dev/prngN result in a PRNG octet stream seeded by N bits of real entropy. (I saw a blog post recently about using AF_LOCAL sockets as PID files. Making open(2) of them == connect(2) to them would make that an awesome idea.) Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
At startup, likely to be short of entropy. Actual behavior, and even existence, of /dev/random and /dev/urandom varies substantially from one implementation to another. If /dev/random blocks when short of entropy, then likely to block at startup, which is good. Services that need entropy do not need to start immediately. If they take a while to come up, no big deal. If /dev/urandom seeded at startup, and then seeded no further, bad, but not very bad. If /dev/urandom seeded at startup from /dev/random, then should block at startup. If /dev/urandom never blocks, bad. Should block at startup waiting to receive 160 bits from /dev/random, and never block again. Ron Peterson reports /dev/random not very random http://bytes.com/topic/c/answers/219952-dev-urandom-vs-dev-random ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 10:01 PM, James A. Donald jam...@echeque.com wrote: If /dev/urandom seeded at startup, and then seeded no further, bad, but not very bad. If /dev/urandom seeded at startup from /dev/random, then should block at startup. If /dev/urandom never blocks, bad. Should block at startup waiting to receive 160 bits from /dev/random, and never block again. On 2013-08-17 12:33 PM, shawn wilson wrote: I don't follow this - I understand why lack of entropy should block urandom but, why shouldn't it block on a running system that low_bound? Once /dev/urandom has 160bits of true randomness, can generate cryptographically strong pseudo randomness for an unenumerably long time. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 10:33:11PM -0400, shawn wilson wrote: On Fri, Aug 16, 2013 at 10:01 PM, James A. Donald jam...@echeque.com wrote: At startup, likely to be short of entropy. If /dev/urandom seeded at startup, and then seeded no further, bad, but not very bad. If /dev/urandom seeded at startup from /dev/random, then should block at startup. If /dev/urandom never blocks, bad. Should block at startup waiting to receive 160 bits from /dev/random, and never block again. I don't follow this - I understand why lack of entropy should block urandom but, why shouldn't it block on a running system that low_bound? Please explain what it means, exactly, to reduce the amount of entropy in the system in question. Emphasis on exactly. Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
