And why just 128-bit AES? AES-256 is not much slower, is it? I think I read it's only 30 percent slower than 128-bit encryption. Either way PFS should become the default for all encrypted communications.
Companies need to start setting their own minimums years ahead of what NIST is recommending. NIST recommended the use of RSA 1024-bit until 2010, so that probably means companies should've moved away from RSA 1024-bit at least 3-5 years earlier. Yet here we are, with most companies today still using RSA 1024-bit 3 years after what even NIST recommended. Time to put security over profits first.
Also, as Ptacek is saying, it's time to implement TACK for certificate pinning:
If one good thing comes of this most recent debacle, though, it'll be an industry reconsideration of the concepts that didn't manage to become NIST standards, like modern stream ciphers and faster curves.
or list all openssl curves: $ openssl ecparam -list_curves
I semi-regularly see it on Cloudflare sites because their customers haven't bothered to send their own keys to Cloudflare.
I thought it was ironic than article about SSL security was doing something that is less secure than possible (from the end user's point-of-view).
Just to be clear, yes, I understand that the operator of brainsmith.org isn't gaining any more security by sending CF the private key to their own cert vs. using CF's G2 cert. With the first approach the end user of brainsmith.org has better security since he can view the site without having to trust an MITM-capable certificate.
I've never seen a CDN that will let you load an ssl cert for less than a few hundred dollars. SNI isn't supported widely enough yet, so they have to dedicate an IP to you.
And how can browsers start to use any other parameters before they standardise them? I think they can't?
1. Locate a public string. A tweet or a quote should suffice.
2. SHA-512 the string to obtain a seed.
3. Use that seed to generate b, and calculate N = #E(Fp) = n * h, and choose a base point P. Of course we need to ensure that these parameters are safe against known attacks.
4. Mandate that the new set of parameters MUST be supported wherever NIST prime curves are supported.
The last step is probably the most difficult. You don't need that if you don't need to interoperate with other implementations though.
- curve25519 and the other djb et al curves.
Changes should stand on their own merits. I don't see why we should trust anyone, random or not. It's not about trusting people, it's about trusting algorithms. So it doesn't really matter who in particular proposes changes.
From a theoretical perspective, the polynomial MACs (like GHASH) are very well understood.
But, much more importantly, the TLS GCM construction is the only modern stream encryption standardized and widely available to TLS. The block constructions in TLS suffer from being created before Encrypt-then-MAC was proven secure; they do the operations the other way around, and thus require extremely fiddly code to quash side channels that have (unlike GCM) already been shown to admit plausible attacks.
The author of this proposal probably isn't so much making a statement about GCM so much as he is suggesting that we need to deprecate the 90's-crypto parts of TLS, which is something that is hard to argue with.
The ARMv8 architecture is supposed to come with hardware optimized AES and SHA-1/SHA-2 encryption, and be "up to 10x" faster than on ARMv7. ARMv8 chips should start coming out next year. So if we're planning "for the future" here, then I'd start with ARMv8 in mind, rather than ARMv7 or even ARMv6 (which really should stop being supported already).
If better and more optimal security means that older phones and lower-end ones will experience a setback in performance on some sites for the next few years (until they get upgraded), so be it.
There's the ARMv7 Cortex A7 chip for low-end now, and ARMv6 chips are terrible for performance anyway. They should not be used as a starting point for very low-end phones anymore.
Going forward, how are site admins to know what ciphersuite to use? This needs to be made very clear. And how are web users to know what the green lock in their browser means, if it can mean anything at all? The current state of affairs is incomprehensible to all but a very few.
There needs to be a big public debate about what ciphersuite is the best. And there should be very careful scrutiny of the implementation. Choosing ciphersuite(s) is a political as well as a technical problem -- the goals should be as clear and simple as possible.
Would any security expert give a critique of this section of the article? That line seems counterintuitive: faster sometimes means easier to break. Shouldn't the goal to be as slow as possible (but no slower than a user will tolerate)?
Also, who is Brian Smith? His personal page doesn't give any info, just an email address. Searching for "brian smith cryptographer" yields a stackoverflow user page, some comments by Brian Smith on various security-related newsgroups, and a linkedin profile with very strange job history -- overlapping timelines, and no entries after 2004 ... I'm assuming that's the same Brian Smith because of his interest in "Cryptography and Information Security."
If that is him, I wonder who he's worked for since 2004? (Should we even be asking these kinds of intrusive questions about people who are proposing new security standards?)
While I'm at it, I may as well ask: who is the submitter, fejr? His account is 5 days old with just one comment but 11 submissions, all related to the NSA or security. I'm curious how they came across this Brian Smith proposal in the first place, because that would give us some information about his background at least. This proposal seems new, because Wayback Machine has no record of that Brian Smith proposal URL so fejr seems to be the first one to post this to any news website.
EDIT: This article deserves a better top comment than mine. When I wrote this, the submission had zero comments and raised a whole lot of questions: Who is this person? Can we trust them? Why haven't we heard about this proposal till now? The answers came swiftly: Brian Smith works for Mozilla. Yes, we can trust that this proposal has no hidden agenda. We hadn't heard about it because it was originally posted to the Mozilla Crypto list two days ago.
Now that those questions are settled, I find myself in the top comment spot and entirely undeserving of the honor. It may have been necessary to at least consider the questions I raised (trust and identity of the author), but my comment addressed none of the substance of the article. I wrote it in order to get some discussion started until tptacek comes in and writes a thorough critique of the proposal's strengths and any possible weaknesses.
So please, someone, write up a good topcomment analysis of the proposal so we can upvote you. :)
> The answers came swiftly: Brian Smith works for Mozilla. Yes, we can trust that this proposal has no hidden agenda. We hadn't heard about it because it was originally posted to the Mozilla Crypto list two days ago.
Would the NSA not have planted multiple long-term people at Mozilla? Would these people not cover for each other, and promulgate their insecurities by planting them in the minds of others who then make the on-record proposal?
The reputation of the popular cryptographers we know and love would only have suffered if their subversions were discovered, which is clearly the opposite of the NSA's goal. And if that is where their morals lie, why would they be personally worried about being uncovered? Moving to Virginia/Utah probably isn't that bad.
And BTW why hasn't Bruce Schneier released the raw documents that could shed clues on which systems are flawed? This is bona fide security-critical information with extreme relevance to the technical community, regardless of the NSA's whining. But I just have to assume he has his reasons even if I'd think they're misguided.
I apologize for any personal implications against Brian, Bruce, et al - they're meant to be completely illustrative. But any decent security person would actually tell you that you should not trust them either.
Are we moving from a state that can know everything on us, but at least might be too busy, to a mob that insists on knowing everything about us, because it's too idle?
I'm pseudoanonymous on here, deleted my LinkedIn account years ago because I despise the site with an utter passion. And, fuck me, I've probably said something stupid about cryptology online because even though I love practical math, crypto is really hard, and IANAC.
I could explain that I'm pseudoanonymous here because I actually am an attorney,[1, 2] and I don't want anything I accidentally say online to be associated with any of my clients. But while that sounds very serious, it's actually pretty unlikely, so no, there's another secret reason that's utterly selfish. I'm going to reveal it here for everyone.
I don't use my true name all the time because I don't want my online reputation in every community tied to stupid shit I said online when I was 15. And when I'm 35, I might not want to tie my online reputation to the stupid shit I'm saying right now. I like the freedom online communities provide to earn respect from nothing, without people relying on any preconceived notions based on how your name sounds, or even what you did last year. I take comfort in the realization that if it all doesn't work out, I can always walk away from a profile and start from scratch. It's social bankruptcy protection. Or maybe, the summer before your freshman year anytime you need it to be.
I feel like in 2002 we wasted a lot of time trying to figure out who in the sphere of public thought was a secret terrorist. I don't think we got anything out of those conversations, and I'd hate to see us repeat the same mistake digging for secret bureaucrats.
I know the recent news makes this hard, but maybe go back to "Is this guy Bruce Schneier, or someone I've never heard of? If I've never heard of him, I'll provide extra scrutiny to the proposal, not because I'm necessarily presuming malicious intent, just because his reputation is not established, and it's a better use of my time to scrutinize the proposal than to scrutinize some random guy's life."
You can waste a lot of cycles trying to confirm or deny if someone has a secret life, something that's probably unknowable, and none of that work actually improves the crypto.
 Head start on the doxxing for anyone playing along at home.
 I am not your attorney, so don't get any funny ideas.
 Well, arguably in crypto, you should always assume malicious intent, constantly ask how any little bit could aid an adversary. But that's not all we're talking about, is it?
EDIT: Formatting (mostly footnote numbering)
This isn't about you or any other drama queens, noone cares who you are and what you do in this context as long as you don't propose changes to crypto standards or conventions in browsers.
The reason why people are asking these questions in the context of cryptography software is perfectly valid, it was discussed here in the past few days.
Yes. See also Sunil Tripathi. Everybody complains about the lack of constraints on the NSA. Nobody complains about the lack of constraints on a mob of redditards.
The reason paranoia is important in post-2013 crypto is because the NSA's knowledge of crypto is very likely ahead of academia / public sector knowledge. They've historically used that advanced knowledge to influence past standards. In one case, they seem to have secretly enhanced the security of DES. But in another case, evidence suggests they may have secretly put a backdoor into their Dual_EC_DRBG proposal.
This raises the question: Should we worry about NSA tampering with proposals? If that's our goal, then it seems to me that our most powerful tool is trust: the fact that we can almost always trust tptacek, cperciva, the Mozilla Security team, and other established names. It's not that they're infallible --- rather, it's that they've always been genuine with their intentions, and have spent years building up that level of trust, so it would be a huge risk for them to be willing parties in NSA tampering.
Therefore, if someone is proposing a new standard, scrutinizing their reputation would seem to be a necessary first step. If their knowledge is secretly ahead of the public sector's, and their proposal contains a secret flaw, then no one will be able to spot it. What else is there to examine if not our level of trust in their established reputation?
So if we choose to believe that the NSA is ahead of public sector knowledge, then it seems like it's valid to be concerned about identity and reputation, because it's inherently impossible to rely on the public sector to spot any hidden influences in the proposal, unless the public sector happens to make the same sort of cryptographic breakthroughs that we presume the NSA to have made.
I apologize for bringing it up in a disrespectful way. I didn't mean to dig into Brian's life. The LinkedIn profile just happened to stand out in a quick google search.
For what it's worth, all I'm trying to do here is ask the community: should we be concerned about NSA tampering? If so, should we assume their knowledge is ahead of the public sector's? If we assume that, then what else can we do except scrutinize identity/trust (since if we assume advanced knowledge, then we can't rely solely on scrutinizing the content of their proposal)? I honestly don't know whether those are valid concerns going forward, or whether they should be taken so seriously. I'm hoping the community will decide.
I agree it's a difficult situation, one with a lot of really hard challenges.
I don't envy the standards communities that will have to figure out the best next steps forward.
I was wondering the same thing with his previous post. I can say he has some interest in Arabic, as his name must be فجر (fejr), as in "the dawn". This has a lot of literary and political connotations and is used by a lot of people these days.
As an Arabic speaker, this caught my attention at the ironic choice of language for the name. Time will tell.
The recommendation is confused enough that I'm inclined to dismiss it.
Slowness is an idiotic goal: slow on slower hardware is fast on faster hardware and slow on faster hardware is unusable on slower hardware. The goal should be a minimum level of security that is still practically secure, and something without a backdoor/easily churnable with adequate hardware. Do you think anything that the majority use today is adequate? I don't. So I think this is all bullshit.
SHA-3 wasn't designed by the NSA.