October 2013 - cypherpunks - lists.cpunks.org

[zfs] [Review] 4185 New hash algorithm support
by Eugen Leitl 07 Oct '13

07 Oct '13

----- Forwarded message from Saso Kiselkov <skiselkov.ml(a)gmail.com> ----- Date: Mon, 07 Oct 2013 00:47:52 +0100 From: Saso Kiselkov <skiselkov.ml(a)gmail.com> To: illumos-zfs <zfs(a)lists.illumos.org> Subject: [zfs] [Review] 4185 New hash algorithm support Message-ID: <5251F6A8.2040305(a)gmail.com> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 Reply-To: zfs(a)lists.illumos.org Please review what frankly has become a bit of a large-ish feature: http://cr.illumos.org/~webrev/skiselkov/new_hashes/ This webrev implements new hash algorithms for ZFS with much improved performance. There are three algorithms included: * SHA-512/256: truncated version of SHA-512 per FIPS 180-4. Uses all existing code from the sha2 module (with new H(0) consts), but the native 64-bit arithmetic used in SHA-512 provides a ~50% performance boost relative to SHA-256 on 64-bit hardware. * Skein-512: 80% faster than SHA-256 in optimized C implementation, and a very high security margin (Skein was a finalist in SHA-3). Also includes a KCF SW provider. * Edon-R-512: 350% faster than SHA-256 in optimized C implementation. Security margin lower than Skein. To address any security concerns associated with using new algorithms this patch also implements salted checksum support. We store a random 256-bit secret key (the salt) in the MOS and use it to pre-seed the hash algorithms (Skein and Edon-R use this, SHA-512/256 is just a straight hash). Any attacker thus cannot simply mount a collision attack on the algorithm, since they can't completely control the input. ATM I didn't implement support for booting off of pools with salted checksums, thus root pools are limited to sha256 and the new sha512 (new GRUB stage2 needed for sha512 support, obviously). It's possible, but I see fairly little reason in doing so (is anybody running dedup on their rpool and running into hash performance limitations?). For performance and correctness testing I've included a set of tiny test suites in usr/src/common/crypto/{edonr/skein/sha2}/test. Simply cd into the test subdirectory in a shell with your build environment set up and type 'make'. See attached file for an example of the output. To those who will inevitably ask about Keccak/SHA-3, here are my reasons why I didn't integrate it (in decreasing order of significance): * Keccak's software performance is worse than SHA-2. * There's no hardware support for Keccak and there likely never will be, as SHA-3 != Keccak. * SHA-3 has yet to be standardized, and there are even some questions around that, be they tinfoil hat material or otherwise: http://tiny.cc/schneier_sha-3 * To be sure, at some point in the future there will be HW support for SHA-3 (which may or may not be faster than Edon-R in SW), but seeing as how HW vendors are easily backdoored, I'm not convinced we should put a lot of trust in their work: http://tiny.cc/hw_trojans_becker13 Cheers, -- Saso root@illumos-build:...gate.git/usr/src/common/crypto# for TEST in edonr skein sha2; do ( cd $TEST/test ; make ); done Building 32-bit test... Running 32-bit test... Running algorithm correctness tests: Edon-R-224 Message: test_msg0 Result: OK Edon-R-224 Message: test_msg1 Result: OK Edon-R-256 Message: test_msg0 Result: OK Edon-R-256 Message: test_msg1 Result: OK Edon-R-384 Message: test_msg0 Result: OK Edon-R-384 Message: test_msg2 Result: OK Edon-R-512 Message: test_msg0 Result: OK Edon-R-512 Message: test_msg2 Result: OK Running performance tests (hashing 1024 MiB of data): Edon-R-256 2604591 us (6.05 CPB) Edon-R-512 4227055 us (9.81 CPB) Building 64-bit test... Running 64-bit test... Running algorithm correctness tests: Edon-R-224 Message: test_msg0 Result: OK Edon-R-224 Message: test_msg1 Result: OK Edon-R-256 Message: test_msg0 Result: OK Edon-R-256 Message: test_msg1 Result: OK Edon-R-384 Message: test_msg0 Result: OK Edon-R-384 Message: test_msg2 Result: OK Edon-R-512 Message: test_msg0 Result: OK Edon-R-512 Message: test_msg2 Result: OK Running performance tests (hashing 1024 MiB of data): Edon-R-256 2002762 us (4.65 CPB) Edon-R-512 1006284 us (2.34 CPB) Building 32-bit test... Running 32-bit test... Running algorithm correctness tests: Skein_256/256 Message: test_msg0 Result: OK Skein_256/256 Message: test_msg1 Result: OK Skein_256/256 Message: test_msg2 Result: OK Skein_512/512 Message: test_msg0 Result: OK Skein_512/512 Message: test_msg2 Result: OK Skein_512/512 Message: test_msg3 Result: OK Skein1024/1024 Message: test_msg0 Result: OK Skein1024/1024 Message: test_msg3 Result: OK Skein1024/1024 Message: test_msg4 Result: OK Running performance tests (hashing 1024 MiB of data): Skein_256/256 14110264 us (32.76 CPB) Skein_512/512 12465191 us (28.94 CPB) Skein1024/1024 16864123 us (39.15 CPB) Building 64-bit test... Running 64-bit test... Running algorithm correctness tests: Skein_256/256 Message: test_msg0 Result: OK Skein_256/256 Message: test_msg1 Result: OK Skein_256/256 Message: test_msg2 Result: OK Skein_512/512 Message: test_msg0 Result: OK Skein_512/512 Message: test_msg2 Result: OK Skein_512/512 Message: test_msg3 Result: OK Skein1024/1024 Message: test_msg0 Result: OK Skein1024/1024 Message: test_msg3 Result: OK Skein1024/1024 Message: test_msg4 Result: OK Running performance tests (hashing 1024 MiB of data): Skein_256/256 3328342 us (7.73 CPB) Skein_512/512 2549537 us (5.92 CPB) Skein1024/1024 3547695 us (8.24 CPB) Building 32-bit test... Running 32-bit test... Running algorithm correctness tests: SHA256 Message: test_msg0 Result: OK SHA256 Message: test_msg1 Result: OK SHA384 Message: test_msg0 Result: OK SHA384 Message: test_msg2 Result: OK SHA512 Message: test_msg0 Result: OK SHA512 Message: test_msg2 Result: OK SHA512_224 Message: test_msg0 Result: OK SHA512_224 Message: test_msg2 Result: OK SHA512_256 Message: test_msg0 Result: OK SHA512_256 Message: test_msg2 Result: OK Running performance tests (hashing 1024 MiB of data): SHA256 6745601 us (15.66 CPB) SHA512 19033518 us (44.19 CPB) Building 64-bit test... Running 64-bit test... Running algorithm correctness tests: SHA256 Message: test_msg0 Result: OK SHA256 Message: test_msg1 Result: OK SHA384 Message: test_msg0 Result: OK SHA384 Message: test_msg2 Result: OK SHA512 Message: test_msg0 Result: OK SHA512 Message: test_msg2 Result: OK SHA512_224 Message: test_msg0 Result: OK SHA512_224 Message: test_msg2 Result: OK SHA512_256 Message: test_msg0 Result: OK SHA512_256 Message: test_msg2 Result: OK Running performance tests (hashing 1024 MiB of data): SHA256 4551774 us (10.57 CPB) SHA512 3029591 us (7.03 CPB) ------------------------------------------- illumos-zfs Archives: https://www.listbox.com/member/archive/182191/=now RSS Feed: https://www.listbox.com/member/archive/rss/182191/22842876-6fe17e6f Modify Your Subscription: https://www.listbox.com/member/?member_id=22842876&id_secret=22842876-a25d3… Powered by Listbox: http://www.listbox.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

trusted computing?
by Juan Garofalo 06 Oct '13

06 Oct '13

What about implementing aes or similar in something like a stm32 arm? The micro is interfaced to a keyboard and a lcd text display. Then you can type your emails or chat messages, have them encrypted in the arm micro, and sent through usb to a non-trusted host pc(or whatever) for delivery.

2 1

SilkRoad coins
by coderman 06 Oct '13

06 Oct '13

On Wed, Oct 2, 2013 at 11:56 AM, coderman <coderman(a)gmail.com> wrote: > ... > i would be interested to know what coin addresses were seized, and how > they are used going forward (if it all?). they moved the coins to new wallet(s) and who knows what happens to them next... http://blockchain.info/address/1F1tAaz5x1HUXrCNLbtMDqcw6o5GNn4xqX?sort=1 http://blockchain.info/unspent?active=1F1tAaz5x1HUXrCNLbtMDqcw6o5GNn4xqX&fo…

2 1

Re: [cryptography] the spell is broken
by Eugen Leitl 06 Oct '13

06 Oct '13

----- Forwarded message from Jeffrey Goldberg <jeffrey(a)goldmark.org> ----- Date: Thu, 3 Oct 2013 20:26:00 -0500 From: Jeffrey Goldberg <jeffrey(a)goldmark.org> To: Jon Callas <jon(a)callas.org> Cc: "cryptography(a)randombit.net" <cryptography(a)randombit.net> Subject: Re: [cryptography] the spell is broken Message-Id: <601145B1-5C4B-4E27-AD30-6445B8436DE0(a)goldmark.org> X-Mailer: Apple Mail (2.1811) Jon, first of all thank you for your extremely thoughtful note. I suspect that we will find that we don’t actually disagree about much, and also my previous rant was driven by the general anger and frustration that all of us are experiencing. That is, I amy have been misdirecting my anger at the whole situation at you, a fellow victim. On 2013-10-03, at 4:31 PM, Jon Callas <jon(a)callas.org> wrote: > You might call it "security theatre," but I call it (among other things) "protest.” I would put it more strongly than that. I think that NIST needs to be punished. Even if Dual_EC_DRBG were their only lapse, any entity that has allowed themselves to be used that way should be forced to exit the business of being involved in making recommendations on cryptography. I don’t have to think that they are bad people or even that they could have prevented what happened. But I think there needs to be an unambiguous signal to every other (potential) standards body about what happens if you even think of allowing for the sabotage of crypto. I imagine that everyone is looking at public protocols for picking curves now. Everyone is looking at how every step in the establishment of a recommendation can be made provably transparent. That is all a good thing, and it does require that NIST pay dearly. But it isn’t a trust issue. I don’t “trust” the NIST less than I trust any other standard’s body. The need to be put out of the crypto business as a signal and deterrent to others, but not because they are inherently less trustworthy. But not using AES is a protest that hurts only ourselves. It doesn’t punish where punishment is needed. > I have also called it "trust," "conscience," and other things including "emotional." I'm willing to call it "marketing" in the sense that marketing often means non-technical. Agreed. > I disagree with "security theatre" because in my opinion security theatre is *empty* or *mere* trust-building, I still think the term is appropriate, and indeed I think that your sentence about conscience and emotions actually reinforces my claim that it is theater. But I think that it is largely a definitional question which isn’t worth pursuing. I’m using the term in a slightly different way than you are. > but I don't fault you for being upset. I don't blame you for venting in my direction, either. I will, however, repeat that I believe this is something gentlepersons can disagree on. A decision that's right for me might not be right for you and vice-versa. Absolutely! Although I still stand by my “security theater” statement, I think I also mean it less pejoratively than it came across. Anyone (including me and the company that I work for) who has moved to 256 bit symmetric keys is engaging in “security theater” in my sense of the word. It’s nothing to be particularly proud of, but it doesn’t make us the TSA either. > > Since the AES competition, NIST has been taking a world-wide role in crypto standards leadership. Yep. And (sadly) that has go. As I said, they need to pay a heavy price so that it is absolutely clear that some behaviors are beyond the pale. > A good standard, however, is not necessarily the *best*, it's merely agreed upon. That’s true. > I think Twofish is a better algorithm than Rijndael. OK. I was flat out wrong. I was ignorant of your longstanding view of ciphers. I’m not competent to really have an opinion about whether your judgement is correct there, but that isn’t relevant. I thought Twofish was pulled out of a hat. I was wrong. And I also apologize for accusing you of pulling Twofish out of hat. > ZRTP also has in it an option for using Skein's one-pass MAC instead of HMAC-SHA1. Why? Because we think it's more secure in addition to being a lot faster, which is important in an isochronous protocol. I agree that if you are changing ciphersuites, it’s as good a time as any to move to a SHA-3 candidate. And as there some questions that need to be answered about official SHA-3, I’m happy with Skein. Again, I’m not competent to judge the relative merits of SHA-3 candidates. > Silent Phone already has Twofish in it, and is already using Skein-MAC. Ah. So yes, we are in very different starting places. Your choice seems very reasonable. > In Silent Text, we went far more to the "one true ciphersuite" philosophy. I think that Iang's writings on that are brilliant. > > As a cryptographer, I agree, but as an engineer, I want options. I think I am in a different position. I’m neither an engineer nor a cryptographer. I’m the guy who can kinda sorta read bits of the cryptography literature and advise the engineers on what to do with respect to using these tools. And what we decide affects the security of a very large number of users. So for me, the “one true ciphersuite” notion was ideal. I could pay attention and follow the consensus advice. You may be competent to, say, pick Skein over Blake for some particular purpose, but I’m not. And I don’t want to have to make those choices. Not only is it that I don’t want to make such choices, but you shouldn’t want me to either. You don’t want me and zillions of application developers to be making such choices. So the loss of “one true ciphersuite”. Think about it, it’s taken a decade to get typical application developers to understand that for many purposes you can’t just use SHA1, but you need to contain it in HMAC. Now they are going to have to unlearn that for the new class of hash algorithms. If we are forced from the Eden of one true ciphersuite, we may end up with people who really aren’t competent to judge picking algorithms out of a hat. So, I guess that some of my frustration that I’m taking out in various directions is rooted in that. Expelled from the paradise of one true ciphersuit, I have the responsibility to choose between the good and the bad didn’t get enough to eat from the tree of knowledge. > One True Suite works until that suite is no longer true, and then you're left hanging. Yep. I was certainly aware of the risks, but I guess I took a bit of a CYA approach. If people spent enormous amounts of money building certain things into chips, they surely would have investigated very carefully before making such a commitment. (I should say that it really isn't CYA; I want to make the best choices for our customers. I also am intensely curious about this stuff, even if I’m not a cryptographer by any means.) > Now let me go back to my comment about standards. Standards are not about what's *best*, they're about what's *agreed*, and part of what's agreed on is that they're good enough. When one is part of a standards regime, one sublimates one's personal opinions to the collective good of the standard. Yes. I fully agree. And I agree that there were things that went into the selection of Rijndael that may not be what I would chose. I fully get that. But having been selected more than a decade ago, AES has been subject to far far more scrutiny than anything else. As a consequence, I think that the gap between our understanding of AES and the NSA’s is smaller than the gap for lesser studied ciphers. So I’m not talking about following the standard as soon as the winner is declared, but the benefits of it having been the standard for so long decrease my uncertainty about it. > That collective good of the standard is also "security theatre" in the sense that one uses it because it's the thing uses to be part of the community. I can see how that might be the case under an even looser definition than I was using, but I’m not really buying it in this case. > I think Twofish is better than AES. I believe that Skein is better than SHA-2. I also believe in the value of standards. Acknowledged. I had misjudged your motivations, and in a fairly insulting way. I appreciate the grace in your response. > The problem one faces with the BULLRUN documents gives a decision tree. The first question is whether you think they're credible. If you don't think BULLRUN is credible, then there's an easy conclusion -- stay the course. If you think it is credible, then the next decision is whether you think that the NIST standards are flawed, either intentionally or unintentionally; in short, was BULLRUN *successful*. If you think they're flawed, it's easy; you move away from them. My take is that BULLRUN was successful in parts. I’m not sure whether the count Dual_EC_DRBG as a success or not, as problems with it were discovered early. It stank from the outset and BULLRUN just confirmed that the stink had a nasty source. Leaving RSA Inc aside, no one really needed to change ciphersuites. Yet it was that revelation that sent me reeling. So the question which other standards *could* they have gotten away with subverting. Quite simply not everything has the kind of math that Dual_EC_DRBG has and not everything has the same “gaps” in the history of where certain things come from. You seem to be suggesting that if BULLRUN was successful anywhere, then it was successful everywhere (and they tried it with everything). Furthermore, at least with AES, you seem to be assuming that if BULLRUN was successful in a case in 2006, then it was also done successfully before 2001. And so when looking at which things I need to move away from, I have to judge the risks that they’ve been compromised in light of all of the information that we have. The new information was confirmation that at least after 2001, the NSA was willing and able to subvert at least one NIST cryptographic standard. I have to integrate that piece of exceedingly distressing news in light of everything else we know about the things I rely on. And so this is what we rely on: AES, SHA-2, and the (alleged) CSPRNGs in commercial operating systems. Looking at those realistically, my energies haven’t been focused on looking for replacements for AES and SHA2, but how to deal with potentially malicious CSPRNGs from Apple and Microsoft. So my focus on improving key generation against undetectably malicious CSPRNGs. > The hard decision is the one that comes next -- I can state it dramatically as "Do you stand with the NSA or not?" which is an obnoxious way to put it, as there are few of us who would say, "Yes, I stand with the NSA." You can phrase less dramatically it as standing with NIST, or even less dramatically as standing with "the standard." You can even state it as whether you believe BULLRUN was successful, or lots of other ways. I’m sorry, but that I have to reject. That is an all or nothing absolutism that I not only think is wrong, but is pernicious. “If you don’t take my position on all things that have come out of NIST you are a stooge for the NSA”. I really don’t think that is something you want to be saying. > Moreover, it's not all-or-nothing. Bernstein and Lange have been arguing that the NIST curves are flawed since before Snowden. Lots of people have been advocating moving to curve 25519. I want a 384-or-better curve because my One True Curve has been P-384. Ah. Good. You are not taking an all-or-nothing position. I seem to have misread something then. I concur about P-384. Were we using elliptic curves, I would be advocating the same move. > If I'm going to move away from the NIST/NSA curve (which seems wise), what about everything else? This isn’t a philosophical or judgement difference between us. It’s just a technical starting place, but > Conveniently, I happen to have alternates for AES and SHA-2 in my back pocket, where they've been *alternates* in my crypto going back years. They're even in part of the software, sublimated to the goodness of the standard. The work is merely pulling them to the forefront and tying a bow around it. OK. You have persuaded me that you are making the right choice for your situation. > And absolutely, this is an emotional response. It's protest. Intellectually, I believe that AES and SHA2 are not compromised. Emotionally, I am angry and I want to distance myself from even the suggestion that I am standing with the NSA. As Coderman and Iang put it, I want to *signal* my fury. I am so pissed off about this stuff that I don't *care* about baby and bathwater, wheat and chaff, or whatever else. I also want to signal reassurance to the people who use my system that yes, I actually give a damn about this issue. So do I. So do I. I am furious. And I want to let the world know. And most importantly, I want to do what I can to make sure that nothing like this happens again. I wrote at top what kind of signal I think is needed for that. > I admire your cool head, Don’t mistake it for lack of anger. > but I have to stand over there. I apologize for angering you, but I'm not sorry. No apology needed. And I once again apologize for thinking and saying that you made your ciphersuite choices naively. And again, thank you for this discussion. Cheers, -j _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [cryptography] the spell is broken
by Eugen Leitl 06 Oct '13

06 Oct '13

----- Forwarded message from Peter Gutmann <pgut001(a)cs.auckland.ac.nz> ----- Date: Fri, 04 Oct 2013 13:15:48 +1300 From: Peter Gutmann <pgut001(a)cs.auckland.ac.nz> To: jamesd(a)echeque.com Cc: cryptography(a)randombit.net Subject: Re: [cryptography] the spell is broken Message-Id: <E1VRt3c-00044Z-W7(a)login01.fos.auckland.ac.nz> "James A. Donald" <jamesd(a)echeque.com> writes: >By moving away from anything NIST has touched he deprives the NSA of leverage >to insert backdoors, Just as a bit of a counterpoint here, how far do you want to go down this rathole? Someone recently pointed me to the latest CERT vuln. summary (because of a few interesting entries there): https://www.us-cert.gov/ncas/bulletins/SB13-273 Now this is just a single weeks' worth, and yet look at all the remote-code- execution and seize-control-of-device issues in just that seven-day stretch. The NSA doesn't really need to backdoor crypto when the barn door isn't just propped wide open, it's entirely missing in some cases. (I completely support Jon's position in terms of being seen to do the right thing, but there are more things to worry about than just backdoored crypto). Peter. _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [cryptography] A question about public keys
by Eugen Leitl 06 Oct '13

06 Oct '13

----- Forwarded message from "James A. Donald" <jamesd(a)echeque.com> ----- Date: Fri, 04 Oct 2013 08:39:08 +1000 From: "James A. Donald" <jamesd(a)echeque.com> To: cryptography(a)randombit.net Subject: Re: [cryptography] A question about public keys Message-ID: <524DF20C.7090809(a)echeque.com> User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.0 Reply-To: jamesd(a)echeque.com On 2013-10-04 03:45, Adam Back wrote: > Is it just me or could we better replace NIST by DJB ? ;) He can > do that EC > crypto, and do constant time coding (nacl), and non-hackable mail servers > (qmail), and worst-time databases (cdb). Most people in the world > look like > rank amateurs or no-real-programming understanding niche-bound math geeks > compared to DJB! Committees are at best inherently more stupid than their most stupid member, and are at worst also inclined to evil and madness. Linux was success because Linus is unelected president for life. Let us have Jon Callas as unelected president for life of symmetric cryptography, Bernstein as God King of public key cryptography. Recall the long succession of Wifi debacles. Has any committee ever done anything good in cryptography? IEEE 802.11 was stupid. If NIST was not stupid, it was because evil was calling the shots behind the scenes, overruling the stupid. _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [cryptography] the spell is broken
by Eugen Leitl 06 Oct '13

06 Oct '13

----- Forwarded message from Jon Callas <jon(a)callas.org> ----- Date: Thu, 3 Oct 2013 14:31:12 -0700 From: Jon Callas <jon(a)callas.org> To: Jeffrey Goldberg <jeffrey(a)goldmark.org> Cc: "cryptography(a)randombit.net" <cryptography(a)randombit.net> Subject: Re: [cryptography] the spell is broken Message-Id: <18F6696D-4D3B-4DC8-8CD4-82CE5D8DAAD3(a)callas.org> X-Mailer: Apple Mail (2.1510) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 3, 2013, at 7:13 AM, Jeffrey Goldberg <jeffrey(a)goldmark.org> wrote: Jeff, You might call it "security theatre," but I call it (among other things) "protest." I have also called it "trust," "conscience," and other things including "emotional." I'm willing to call it "marketing" in the sense that marketing often means non-technical. I disagree with "security theatre" because in my opinion security theatre is *empty* or *mere* trust-building, but I don't fault you for being upset. I don't blame you for venting in my direction, either. I will, however, repeat that I believe this is something gentlepersons can disagree on. A decision that's right for me might not be right for you and vice-versa. Since the AES competition, NIST has been taking a world-wide role in crypto standards leadership. Overall, it's been a good thing, but one could have one's disagreements with a number of things (and I do), but it's been a good *standards* process. A good standard, however, is not necessarily the *best*, it's merely agreed upon. A standard that is everyone's second choice is better than a standard that is anyone's first choice. I don't think there are any problems with AES, but I think Twofish is a better choice. During the AES competition, the OpenPGP community as a whole, and I and my PGP colleagues put Twofish into OpenPGP *independently* of the then-unselected AES. It was thus our vote for it. When Phil, Alan, and I were putting ZRTP together, we put in Twofish as an option (RFC 6189, section 5.1.3). Thus in my opinion, if you know my long-standing opinions on ciphers, this shouldn't be a surprise. I think Twofish is a better algorithm than Rijndael. ZRTP also has in it an option for using Skein's one-pass MAC instead of HMAC-SHA1. Why? Because we think it's more secure in addition to being a lot faster, which is important in an isochronous protocol. Silent Phone already has Twofish in it, and is already using Skein-MAC. In Silent Text, we went far more to the "one true ciphersuite" philosophy. I think that Iang's writings on that are brilliant. As a cryptographer, I agree, but as an engineer, I want options. I view those options as a form of preparedness. One True Suite works until that suite is no longer true, and then you're left hanging. To be fair, there are few options in ZRTP -- it's only AES or Twofish and SHA1-HMAC or Skein-MAC, so the selection matrix is small when compared to OpenPGP. We have One True Elliptic Curve -- P-384, and options for AES-CCM in either 128 or 256 bits and paired with SHA-256 or SHA-512 as hash and HMAC as appropriate. There's a third option, AES-256 paired with Skein/Skein-MAC, which I don't think is in the code, merely defined as a cipher suite. I can't remember. So we have to add Twofish there, but it's in Silent Phone now. Now let me go back to my comment about standards. Standards are not about what's *best*, they're about what's *agreed*, and part of what's agreed on is that they're good enough. When one is part of a standards regime, one sublimates one's personal opinions to the collective good of the standard. That collective good of the standard is also "security theatre" in the sense that one uses it because it's the thing uses to be part of the community. I think Twofish is better than AES. I believe that Skein is better than SHA-2. I also believe in the value of standards. The problem one faces with the BULLRUN documents gives a decision tree. The first question is whether you think they're credible. If you don't think BULLRUN is credible, then there's an easy conclusion -- stay the course. If you think it is credible, then the next decision is whether you think that the NIST standards are flawed, either intentionally or unintentionally; in short, was BULLRUN *successful*. If you think they're flawed, it's easy; you move away from them. The hard decision is the one that comes next -- I can state it dramatically as "Do you stand with the NSA or not?" which is an obnoxious way to put it, as there are few of us who would say, "Yes, I stand with the NSA." You can phrase less dramatically it as standing with NIST, or even less dramatically as standing with "the standard." You can even state it as whether you believe BULLRUN was successful, or lots of other ways. Moreover, it's not all-or-nothing. Bernstein and Lange have been arguing that the NIST curves are flawed since before Snowden. Lots of people have been advocating moving to curve 25519. I want a 384-or-better curve because my One True Curve has been P-384. If I'm going to move away from the NIST/NSA curve (which seems wise), what about everything else? Conveniently, I happen to have alternates for AES and SHA-2 in my back pocket, where they've been *alternates* in my crypto going back years. They're even in part of the software, sublimated to the goodness of the standard. The work is merely pulling them to the forefront and tying a bow around it. And absolutely, this is an emotional response. It's protest. Intellectually, I believe that AES and SHA2 are not compromised. Emotionally, I am angry and I want to distance myself from even the suggestion that I am standing with the NSA. As Coderman and Iang put it, I want to *signal* my fury. I am so pissed off about this stuff that I don't *care* about baby and bathwater, wheat and chaff, or whatever else. I also want to signal reassurance to the people who use my system that yes, I actually give a damn about this issue. I am fortunate enough to have a completely good cipher and completely good hash function in my back pocket. So I'm going to use them. If it turns out that there's a good explanation, that BULLRUN is wrong, it's just software. Your situation is different, as is everyone else's. I admire your cool head, but I have to stand over there. I apologize for angering you, but I'm not sorry. If I'm wrong, I'll have to eat my words. I would rather eat my words in this direction -- moving away -- than the other direction -- standing pat. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 3.2.0 (Build 1672) Charset: windows-1252 wj8DBQFSTeImsTedWZOD3gYRAkIRAJ9cDK8o+NF+L6j7B8tQyP/8oIV7rgCgzGpf ns15Wi+7A3OtBclHULxxBtM= =/bzs -----END PGP SIGNATURE----- _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

[liberationtech] As F.B.I. Pursued Snowden, an E-Mail Service Stood Firm
by Eugen Leitl 06 Oct '13

06 Oct '13

----- Forwarded message from Michael Allan <mike(a)zelea.com> ----- Date: Thu, 3 Oct 2013 17:25:51 -0400 From: Michael Allan <mike(a)zelea.com> To: Liberationtech <liberationtech(a)lists.stanford.edu> Subject: [liberationtech] As F.B.I. Pursued Snowden, an E-Mail Service Stood Firm Message-ID: <1380835388.ACD53ff0.17857(a)out.zelea.com> Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> DALLAS — One day last May, Ladar Levison returned home to find an F.B.I. agent’s business card on his Dallas doorstep. So began a four-month tangle with law enforcement officials that would end with Mr. Levison’s shutting the business he had spent a decade building and becoming an unlikely hero of privacy advocates in their escalating battle with the government over Internet security. http://www.nytimes.com/2013/10/03/us/snowdens-e-mail-provider-discusses-pre… -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [tor-talk] Tips for configuring and using Tor for anonymous Bitcoin usage?
by Eugen Leitl 06 Oct '13

06 Oct '13

----- Forwarded message from mirimir <mirimir(a)riseup.net> ----- Date: Thu, 03 Oct 2013 21:12:42 +0000 From: mirimir <mirimir(a)riseup.net> To: tor-talk(a)lists.torproject.org Subject: Re: [tor-talk] Tips for configuring and using Tor for anonymous Bitcoin usage? Message-ID: <524DDDCA.3050900(a)riseup.net> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 Reply-To: tor-talk(a)lists.torproject.org On 10/03/2013 05:45 PM, author(a)anonymousbitcoinbook.com wrote: > Hey all, > > I'm writing a book about the use of Bitcoin and anonymity. A fair > portion of the book will be dedicated to teaching people how to most > safely use Tor to facilitate anonymity with Bitcoin. Are there any > special tips that people have for configuring Tor or using Tor when > it comes to Bitcoin? I'll have tutorials online "soon" (not in my hands) that cover this in great detail. I recommend mixing through at least three different mixing services, using independent anonymous wallets. > Right now, I'm recommending the use of a LiveCD Linux distro > (Ubuntu) with TorBundle for Linux and the vanilla Bitcoin client for > Linux. A couple tips I'm already aware of are to disable JavaScript > before using (since NoScript currently defaults to being on :() and > to avoid downloading files through the web browser such as PDF > documents. I recommend using Whonix with the Multibit client. The vanilla Bitcoin client downloads the full blockchain, which is far too much for Tor. It's comparable to torrenting an 8 GB video. Multibit is a local client, under user control, but doesn't download the blockchain. It's the recommended default now. > In particular, I'm curious 1) if there needs to be special > configuration to ensure that all DNS request go through Tor, and 2) > whether I can configure the system not to send any internet message > except through the Tor proxy. As I understand Whonix, it's designed not to leak. But I defer to adrelanos for specifics. > Regards, Kristov -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [cryptography] the spell is broken
by Eugen Leitl 06 Oct '13

06 Oct '13

----- Forwarded message from Jeffrey Goldberg <jeffrey(a)goldmark.org> ----- Date: Thu, 3 Oct 2013 09:13:59 -0500 From: Jeffrey Goldberg <jeffrey(a)goldmark.org> To: Jon Callas <jon(a)callas.org> Cc: "cryptography(a)randombit.net" <cryptography(a)randombit.net> Subject: Re: [cryptography] the spell is broken Message-Id: <EC4DE0DF-6CAC-48C3-BCA0-FCFFA41B01DF(a)goldmark.org> X-Mailer: Apple Mail (2.1811) On 2013-10-02, at 5:23 PM, Jon Callas <jon(a)callas.org> wrote: > A friend of mine offered this analogy -- what if it was leaked that the government replaced all of a vaccine with salt water because some nasty jihadis get vaccinated. This is serious and pretty horrifying. If you're a responsible doctor, and source your vaccines from the same place, even if you test them yourself you're stuck proving a negative and in a place where stating the negative can look like you're part of the conspiracy. I have been like that doctor, trying to explain to people why I remain confident in AES and SHA-2. Most who have asked have been understanding, but there have been a few “if you still use NIST/NSA algorithms, it’s because you are being told to.” Now some of us do have a (non-evil) financial incentive not to switch. We are encrypting data in files that a user synchronizes among multiple platforms. Even if we built in alternative ciphersuites today, it would probably be a year before we could create data using the new ones. So unless you and Silent Circle have information that the rest of us don’t about AES and SHA-2, I’m actually pissed off at this action. It puts more pressure on us to follow suit, even though such a move would be pure security theater. > Let me also add that I wouldn't fault anyone for deciding differently. We, the crypto community, need to work together with security and respecting each other's decisions even if we make different decisions and do different things. I respect the alternate decision, to stay the course. Would you fault people for engaging in security theater? And how is moving away from AES anything other than security theater? Traditionally we’ve used the term “security theater” to refer to things instigated by politicians and large entities. But the term applies just as well when it is motivated by demand from semi-sophistical users. Some instances of security theater of that sort are relatively harmless (256 bit symmetric keys, etc), but switching to an AES alternative carries real risks. I have nothing against Skein and Twofish (simply because I’m not familiar with the research on these and other SHA-3 and AES alternatives), but that choice only helps confirm the charge of security theater. I also think that the choice of Twofish and Skein reeks of security theater as well. It’s based on the public image of a high-profile contributor instead of on security considerations. Other things being equal, going with ciphers that are popular is wise. But are “other things” equal here? (genuine question. I don’t know how well Twofish and Skein hold up in comparison to other AES or SHA-3 finalists.) I’m not unsympathetic to you and Silent Circle. I can foresee engaging in the same sorts of security theater due to user demand. We’ve done it ourselves in a move from 128 bit AES to 256 bits despite the problems with the 256 bit key schedule. I’m also sympathetic to showing the world that we consider NIST tainted in general. NIST may never regain credibility even if Dual_EC_DRGG was the only case. But that loss of credibility should come (as it has) in renewed scrutiny of NIST behavior; it shouldn’t be throwing out the baby with the bath water just to make people feel more secure. Although I’m angry, I do recognize that Silent Circle’s actions are legitimate. But I do wish you would acknowledge that wrt AES and SHA-2 it is security theater instead of security. Cheers, -j _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0