Hacker News Reader

Brian Smith works at Mozilla in the Security Engineering team. He's one of the brain behind NSS.

No, faster does not mean easier to break. Fast is a problem when brute force attacks are viable, as in with password hashes. There are no viable brute force attacks on 128 bit keys; that's why we use 128 bit keys.

As a noob in encryption, why is it not possible to guess the 128 bit private key by brute force?

I could explain this, but in all seriousness, I think the better answer to this question is to urge you to pop open your Perl, Ruby, or Python prompt and work the math out.

There are 340282366920938463463374607431768211456 possible 128-bit keys. So if you had a machine that could check a trillion possible keys per second it would take over 10 quintillion years to try all possible 128-bit keys.

The math: https://www.google.com/search?q=2%5E128+%2F+1E12Hz+in+years

The brute force algorithm is O(2^n)

Sorry, you're just fueling counterproductive witch-hunt hysteria. Probably due to seeking safety and wanting for trustable crypto gurus to show you the way. They don't exist. The only way to move forward is to continue to judge ideas and not people, and use what we've learned to design systems more resistant to hidden subterfuge of unknown design.

> 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.

Here's some discussion on mozilla's crypto list:

http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.or...

Thanks! I also found a presentation from the Stanford Real World Cryptography event in Jan 2013 which cites Brian's work. It's an interesting read: https://crypto.stanford.edu/RealWorldCrypto/slides/gueron.pd...

No, slower doesn't mean more secure. 3DES is a lot slower than, say, AES, but nobody's suggesting 3DES is more secure than AES.

> Also, who is Brian Smith?

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,[1] 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,[3] 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.

[1] Head start on the doxxing for anyone playing along at home.

[2] I am not your attorney, so don't get any funny ideas.

[3] 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)

Yes, my apologies. My comment was overly blunt.

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.[1] But in another case, evidence suggests they may have secretly put a backdoor into their Dual_EC_DRBG proposal.[2]

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.

[1] http://en.wikipedia.org/wiki/Data_Encryption_Standard#NSA.27...

[2] http://en.wikipedia.org/wiki/Dual_EC_DRBG

Eh, I was probably too hyperbolic.

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.

"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?"

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.

> I'm pseudoanonymous on here, deleted my LinkedIn account ...

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.

ECDSA verification on P-256 is slower than RSA verification with 1024-bit or 2048-bit modulus, but they are thought to achieve such vastly different security levels that comparing them at all for performance is wrong.

> While I'm at it, I may as well ask: who is the submitter, fejr?

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.

I think "as slow as possible" is good for the initial key exchange, or for storing keys at rest. The point is to make offline key recovery (by guessing) more difficult. But once you have a good key, the ciphertext is already completely scrambled. Slowing down won't make that part any harder.

Brian Smith seems to be ignoring everything Schneier has said in the past week regarding avoiding ECC, And preferring 128b AES over 256 or even 512 is so counter intuitive it is beyond reason. And this whole paper reeks to me of an exercise in finesse'.

Check the date -- the proposal is a month old. So Bruce Schneier's comments may be relevant, but one can't really accuse Brian Smith of ignoring them.

Good point, I missed that on the first pass, I look forward to an update from him or a comment on this from Schneier.

For the record: (a) I can't find anything Schneier has ever published on ECC; it is a notable omission in his most recent crypto book (Cryptography Engineering, (b) the ECC issue is confused by Dual-EC-DRBG, the ECC-derived CSPRNG that nobody uses but is now thought to be a deliberately weak NSA design, (c) his reasoning for avoiding ECC (the constants are suspect) is a little bit of a stretch given that the most popular curves have a relatively straightforward derivation, and (d) it's downright weird to point a finger at all of elliptic curve cryptography based on a single set of constants; surely he's not implicating the Edwards curves Bernstein and Lange have been promoting, for instance.

The recommendation is confused enough that I'm inclined to dismiss it.

The deterministically derived ECC constants are derived by seeding a hash function with an extremely high entropy input (> 100 bits), and taking the first usable result. This is effectively the same as choosing the parameter. The NSA had freedom to specify this very high entropy seed value, and could have done so by iteratively trying seed values until they got a curve that weak using techniques only known to the NSA; it's just a way to disguise the origin of the curve by making it sound random. The situation with Kobolitz curves is only slightly better.

For what it's worth, I submitted this link to HN a month ago: https://news.ycombinator.com/item?id=6187176

> Shouldn't the goal to be as slow as possible (but no slower than a user will tolerate)?

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.

I'm pretty sure Brian currently works for Mozilla.