Hacker Newsnew | comments | show | ask | jobs | submit | cryptbe's commentslogin

While I'm not 100% sure, it's likely that VNNIC has been 0wned.

Rationale: VNNIC doesn't provide any online DNS management tools. One has to submit a paper request in person to change any DNS records.

Edit: it looks like it's the registrar WebNic.cc that got hacked.

reply


Man! VNNIC now has EPP Gateway http://www.vnnic.vn/en/domain/eppgateway?lang=en

reply


Papers have nothing to do with their infrastructure IMHO..

reply


POODLE worked not only against SSLv3, but also against any TLS implementations that check padding in SSLv3's style (e.g., just checking the last byte, and ignoring the rest of the padding). SSL accelerators from F5 and A10 were vulnerable. Thus, many of the world's largest sites were vulnerable.

-----


Great question. The core crypto library in End-To-End has already supported ECDH on Curve25519 and Ed25519 since day one [1]. We're discussing with GnuPG team on extending RFC 6637 to include these algorithms in the OpenPGP standard.

[1] https://code.google.com/p/end-to-end/source/browse/javascrip....

-----


I spent the weekend digging into both End-to-End and OpenPGP.js, and it appears the End-to-End has the primitives for Ed25519, but it doesn't recognize signature packets that use Ed25519. Is there an e2e bug tracking compatibility with GPG 2.1 signatures that use Ed25519?

-----


Congratulations Werner and GnuPG team!

> GnuPG now support Elliptic Curve keys for public key encryption. This is defined in RFC-6637. Because there is no other mainstream OpenPGP implementation yet available which supports ECC, the use of such keys is still very limited. [1]

Google End-To-End [2] supports ECC by default. We are working on supporting Ed25519, but encrypting and signing with NIST curves should work and be compatible with GnuPG. That said, we've had a lot of compat issues, so it'll be great if Hacker News readers and GnuPG users can help test our implementation against GnuPG. You can generate keys in GnuPG and import them to End-To-End and vice versa, or you can encrypt/sign messages on one software and decrypt/verify them on the other. If you found a bug or anything that doesn't work as expected, you can report it at https://code.google.com/p/end-to-end/wiki/Issues?tm=3. If it's a security bug you're eligible for a monetary reward under our bug bounty program :-).

[1] https://gnupg.org/faq/whats-new-in-2.1.html#ecc [2] https://code.google.com/p/end-to-end/

-----


Hopefully this is not too obvious, but what is the advantage of ECC crypto compared to what GnuPG 2.0 is using?

-----


There are three big issues; in order of importance:

1. PGP's RSA constructions are archaic; they use a format defined in the 1990s that is vulnerable to multiple different attacks and likely to harbor more that we don't know about yet. (This, bafflingly, is also a problem with DNSSEC.) I should be clear: PGP is not itself known to be vulnerable to these attacks. But neither was Java's TLS implementation, before it was found to be vulnerable a few months back.

2. RSA is well-studied but it's hard to say how well we understand its strength. There are no credible attacks on RSA-2048, but academic progress is being made on a cousin of the factoring problem it relies on (the discrete log problem). ECC is based on a harder math problem, is also well studied, and is believed to be stronger.

3. ECC is faster and provides more security with fewer key bits.

A combination of all three of these factors gives a sort of second-order issue, which is that modern public key crypto constructions tend to be based on ECC and not multiplicative group IFP/DLP algorithms. EdDSA is good for reasons other than that it's based on good ECC crypto.

Hope that's helpful and not just noise. Looking forward to inevitable 'pbsd correction. :)

-----


Speed. Key generation (and most other operations) in ECC is order of magnitude faster than in RSA, DSA or ElGamal. Last time I checked it took End-To-End's Javascript library seconds to generate a key pair in RSA, but only milliseconds in ECC.

-----


Key gen time probably doesn't matter too much in the particular case of pgp, but key size is a big deal. Keys that you might conceivably type by hand. Keys, not fingerprints, that can fit in tweets. Or tattoos. :)

-----


Do you know of anyone with a signify (or reop) key tattoo yet?

-----


Heh. No, I'm not trying to encourage that, but I think it's useful as rough measure of practical size for exchanging data. Like "Olympic swimming pools" is a popular measure.

-----


> Sure you have control over the first N bytes. Look at the request-line: "GET /hello/world/this/is/my/url HTTP/1.1". Sure, you don't control the spaces, but you can assume any practical implementation uses a single space character. Combine that with control over the method (with XHR or statically through <form> or <img>) and the path, you're in business.

tptacek is right. To make BEAST work we had to control _all_ the bytes of the very first block. We tried very hard to make it work with Javascript, but we couldn't. Java applet (and maybe Flash) was the only tool that gave us that kind of control.

-----


When Pornin disclosed CRIME I was telling myself: "Wait a minute, I saw this name somewhere." Then I remembered that it was Pornin's article [1] that helped me understand how zlib flush modes work.

I thought that was pretty funny.

[1] http://www.bolet.org/~pornin/deflate-flush-en.html

-----


You guys are both my heroes.

-----


If you want to learn the math, check out http://www.amazon.com/Introduction-Mathematical-Cryptography....

-----


I like this book a lot, but you won't need any of this math until set 8. I spent a lot of term learning things like lattice basis reduction algorithms (I used Strang's linear algebra book and MIT lectures) only to discover that there really isn't a whole lot that requires you to break out linear algebra in day-to-day cryptography.

In particular: virtually all of block cipher crypto and message authentication relies on straightforward math. (It would be different if our challenges covered poly MACs, but we don't have good examples of common flaws in poly MAC implementations).

-----


Nonce reuse? It usually gets you at least forgeries, and in GCM's case it even gets you key recovery.

I agree that the published sets of challenges don't really need much theory.

-----


Are you referring to Joux here? Is the math for that really complicated? (I haven't tried to implement it.)

Later: I just read Ferguson, with the linear algebra.

-----


Yeah. Joux's attack is conceptually simple. You have 2 tags T_0, T_1, obtained with distinct messages and the same IV. This means T_0 = S_0 ^ X and T_1 = S_1 ^ X, where X is the same value for both. So you have T_0 ^ T_1 = S_0 ^ S_1. S_0 and S_1 are the polynomial evaluation of the ciphertext at H, the authentication key (which is also the same).

Now, via a simple polynomial evaluation property, you have f(x) + g(x) = (f + g)(x). We know f and g --- those are the two ciphertexts being authenticated here, interpreted as polynomials --- and we know that the polynomial f + g - S_0 - S_1 must be 0 at H. From there it's a matter of finding the roots of this polynomial, one of which is H, and this is the mathematically complicated part of the attack. Though you can treat root-finding as a black-box, the keywords here are Berlekamp or Cantor-Zassenhaus.

(Hopefully I didn't get this too wrong, I'm handwaving here)

-----


Can you imagine how much more insufferable I'm going to be once I have worked examples of these attacks? ;)

-----


I took a quick look at your implementation of ECDSA and I think it has a bug at line 311 [1]. It looks like I could bypass the check if r or s is negative.

One thing that I don't understand is why big integer libraries developed exclusively for crypto need negative numbers. The library [2] that I contribute to doesn't need them, and it works just fine. Actually I could argue that having only non-negative numbers make it simpler and faster.

[1] https://github.com/cryptocoinjs/ecdsa/blob/master/lib/ecdsa.... [2] https://code.google.com/p/end-to-end/source/browse/javascrip...

-----


Its not really a bug, the operations after it would still be valid (it is almost immediately reduced to the field order), its just that those parameters would not be akin to the SEC paper specification. I agree that the honus isn't on the users to check that though, so I'm probably going to make a pull request to change this.[1]

[1] https://github.com/bitcoinjs/bitcoinjs-lib/pull/250

-----


What might happen if r = s = -n? I think it's pure luck that this doesn't lead to a signature forgery.

-----


You're not wrong.

Thanks for pointing this out, thankfully the implementation already failed on a negative s value, but you're correct in that it wasn't definitive.

I also whole-heartedly agree with your comment about the unnecessary inclusion of a bignum that allows for negative values. The lack of typing in this (and other cases) has lead to several problematic scenarios for users to the point we have littered the code with assertions to enforce whatever we can.

-----


> None of this bickering changes a simple truth: when a web mail provider claims to provide "NSA-proof" end-to-end encryption, hosted in Switzerland just to be safe, using software that you don't have to install on your computers at all, then you need to assume that web mail provider can read your email, and so can anyone who can coerce that provider into doing something. If you believe that --- and you should --- then I don't care what you think about the rest of the Matasano article.

This. The whole article could be replaced with this paragraph, and it couldn't be clearer.

-----


Thanks for posting this article. I wrote it was a response to the Matasano's article that I saw on Hacker News a few days ago.

I want to introduce many useful applications of Javascript crypto that I've seen, and I want to explain that developing crypto in Javascript is difficult because of the lack of types. What I found surprisingly is that most people that complain about Javascript crypto don't even mention this problem. I guess they think the language is too bad to even give it a try.

-----


The main criticisms of JS crypto that I've seen have nothing to do with the language, just that it's in-browser scripting hosted by a third party. Even if the language were perfectly designed for cryptography, the problem is the trust model - every single time you decrypt or sign something, you need to load your private key (or give a password for key generation, or whatever) into the script, which means that you need to make sure that the code has not been subverted every single time, which is nearly impossible to do anyway. So if you try and offer a service that says, "Even I can't access your e-mails, they are end-to-end encrypted using Javascript in your browser!", that may be true right now, but you can revoke that trust unilaterally by changing the Javascript and I won't notice. You could be compelled to do this. Your server might be compromised in some way, then all of a sudden you've got my private key. The whole problem that end-to-end encryption solves is that the server/cloud can only say, "We won't look at your data.", not "We can't look at your data." If you're controlling the encryption process with javascript, then you can't necessarily decrypt the data when it's at rest, but the next time I log in, you could snatch my keys, and maybe you've already done that at some point. So now we're back to a "We won't look at your data." model, because you're just making the choice not to subvert the crypto javascript.

Think about what you'd do if you were going to install TrueCrypt or some other security/cryptography program. Assuming you didn't want to build it from the source, you'd download a binary, and that binary would have an SHA or MD5 hash next to it, verifying that it's the correct file. Other people who compile the binary from source should be able to generate the same file and compare the hashes, so at the very least it can be audited and you can verify that you've got what they say you have. To do the equivalent thing with in-browser Javascript, you'd need to check the MD5 hash of the javascript that you're executing every single time you use the script, BEFORE you start the encryption/decryption process. You could use some sort of browser extension to check that the script you're about to download and execute is the same one you've used before, but if you're already installing browser extensions to do something like that, you might as well just install a browser extension that does the crypto for you without having a trust relationship with a server.

-----

More

Applications are open for YC Summer 2015

Guidelines | FAQ | Support | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: