sdevlin

Report coauthor here.

No significant issues were found in either phase of the TrueCrypt audit. If you're using it today (or have used it in the past), I don't think you have anything to worry about.

But it is an unmaintained piece of software, and for that reason I would migrate away from it. If I were setting up a new laptop today, I wouldn't consider installing it. If I had an existing laptop using it, I would think about transitioning when I had some spare time.

Not a hair-on-fire problem, though.

Report coauthor here.

The weaknesses of XTS mode are mostly limitations imposed by full-disk encryption. You should think of XTS as fine for FDE, but you also shouldn't put too many expectations on FDE. FDE is great if you leave your powered-off laptop in the back of a cab. It's not great if federal agents distract you and steal your powered-on-and-logged-in laptop at the library.

You should definitely use FDE, but you should also separately encrypt the things that are really important to you.

What makes it slow? Is it implemented in C#?

I would avoid slow implementations of password hashing algorithms. You want the overall operation to be slow due to the computations you're performing, but you want the implementations of those operations to be fast. Because the attacker's implementations of those operations will be fast.

There are some thoughts on the matter here: http://chargen.matasano.com/chargen/2015/3/26/enough-with-th....

But I would say yes, bcrypt is still best practice. Other commenters are right that bad passwords will still be recoverable, but using one of bcrypt/scrypt/PBKDF2 is due diligence. I would use whichever one is most easily available on your platform.

Great info - thanks!

Ah, interesting - so this applies in particular to elliptic curves over binary fields.

I may have missed this, but did they note how performance fared in the absence of hardware support?

Also, have binary curves (this or the NIST ones or any others) seen widespread deployment anywhere? I was under the impression that prime field curves were more widely used.

That's the whole point, though - the algorithm is very straightforward to implement without data-dependent look-ups. So while any of those could affect execution time, none should do so in a way that leaks data.

> They also added the PCLMULQDQ instruction to efficiently implement ECC.

Isn't this more typically used in GHASH implementations? Maybe it's applicable to both.

Are you talking about this paper? https://gmplib.org/~tege/x86-timing.pdf

I only saw evidence of data-dependent timing with respect to the div operation, but maybe I missed something.

Of course, I am not suggesting other operations are inherently immune to data-dependent timing leaks.

EDIT: I see there are also some notes on adc and sbb in some situations, i.e. chains of instructions that all light up the carry flag.

RSA is not "modern".

Modern elliptic curves are chosen with side channels in mind. You won't find data-dependent branches or look-ups in straightforward implementations of Curve25519 scalar multiplication, for example.

Yep. I remember seeing this version though: http://eprint.iacr.org/2013/346.pdf.

Not sure if there is any difference in content.

I haven't. I think they are pointless at best.

This particular phone screen was probably the most nervous I've been during any interview ever. Predictably, it was enough to disqualify me.

I once had a phone interview wherein I was required to write some code and then read it to the interviewer (character by character!) over the phone. I asked him whether it would make more sense for us to use etherpad (this was maybe five years ago), but he said no.

Maybe he meant Nadia needed to "handhold" the server(s)? I.e., that the factoring service is currently not very robust?

Well, he is correct that Matasano was acquired by NCC Group. But as a rank-and-file Matasanoan since before the acquisition, I can't say I've noticed a huge impact on the day-to-day.

I don't really buy that this is a simplification. This code isn't even guaranteed to work on correct input.

A really simple fix would be just to use a character array.

First: great article.

One nit, though. There's a subtle error in the main function:

    char* input;
    printf("Please input a word: ");
    scanf("%s", input);

Local variables are not automatically initialized in C, and we never assign input to point to any particular block of memory. This means it's probably pointing off to some random location - basically whatever address happened to be sitting on the stack when main was called. So when scanf writes the user password to input, it's going to go to some unpredictable location with unpredictable results. This could lead to code execution, or at least a straightforward denial of service.

Most of the comments so far focus on the fact that WhatsApp is a closed-source system. And just to be clear, it would absolutely be better to have source code. Source code gives you a 1000-foot view of the application and lets you spot obvious problems quickly.

But source code can also lie to you. To really understand what the application is doing, you need to do what security auditors do irrespective of source code availability. Namely:

1. Disassemble the application binary.

2. Debug the running application.

3. Observe the network traffic.

Here's another thing to think about. Suppose the source code were available. How could you trust that the source code provided matches the compiled binary running on your phone? You would need to perform the above steps to verify.

> RSA Encrytion uses padding (usually OAEP)

Heh.

I had to read the article a couple times.

The scenario he's describing is:

  1. A user submits a password (with no username) to authenticate.
  2. The server looks up the password in a hash table. This involves:
     a. Hashing the password to find the correct bucket.
     b. Doing a string comparison against passwords stored in the bucket.

There are vulnerabilities in two places:

1. Buckets containing more passwords will take longer to return a negative result because they will have to perform more string comparisons. (This irrelevant except in pathological cases.)

2. String comparisons with longer common prefixes will take longer to return a negative result.

This is a bad example for a couple reasons:

1. Password inputs are not compared directly to stored values in any real authentication system. They are hashed first. A timing attack here implies a preimage attack against the hash function.

2. Passwords are not global. Passwords are paired with a username. You don't get to time the comparison against every password in the system to determine common prefixes, for example.

A better example might have been API tokens, which are often stored in cleartext and fetched directly from the database.

All of these points are orthogonal as to whether source code is required for a security audit.

Source code doesn't really matter as much as you'd think. In fact, it can be deceptive in some cases. I would call source code a nice-to-have.

In contrast, observing the network traffic, debugging the application, and examining the decompiled binary will tell you exactly what's going on.

You'd also have to rebuild the tools for every new syntax, whereas paredit basically "just works" for every lisp.

Yeah, it's arguably a plus.

It depends on your use case.

If you need something that speaks TLS, then no. NaCl is a different (simpler) protocol that does not have TLS compatibility as a goal.

If you're building a new application then NaCl is probably a good choice. There are some problems you may need to solve yourself, if your application calls for them. For example, NaCl has no notion of a CA hierarchy.

"Theory and practice" was a poor choice of words on my part.

The point is simply that there are assumed-hard problems and cryptographic constructions based on them. If there is wiggle room between these things (as in RSA), it can severely undermine the strength of the system.

This is why proofs are valuable: if you can prove the cryptographic construct is reducible to the underlying problem†, you can focus your attention on the problem. I feel much better worrying about the practicality of quantum computers than whether there's a plaintext recovery attack that runs in a million queries.

† This isn't a panacea, unfortunately, as side channels are still a concern. Also: conformance of implementation to what has been proven.

This is a pretty neat survey on the gulf between theory and practice, which is basically where practical cryptographic attacks live.

For example, RSA is based on the integer factoring problem, but they are not equivalent. Vanilla RSA does not offer what they call "chosen-ciphertext security"; in fact, a careful plaintext padding scheme† is needed to approximate this property.

PKCS#1v1.5 padding is not that scheme††: it formats the plaintext with a fixed leading byte (or two). This puts implementers in a tricky spot - what do you do if you decrypt a message and the prefix is wrong? If your answer was "throw an error", then congratulations! You've completely compromised the security of RSA.

They reference this attack briefly on page two of the linked article; grep for "Bleichenbacher". For more information, you can find Bleichenbacher's description of his padding oracle attack on PKCS#1 here: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.19..... I'll go further and say that implementing this attack is fun and enlightening - it's well worth your time.

† The scheme I'm alluding to is OAEP, but even it has implementation pitfalls that can sometimes be exploited.

†† But it is (bafflingly) the default padding scheme in every RSA library I can think of.

I guess I'm still unclear how that would work in the context of AES. Or really any symmetric construction, come to think of it.

I think he's talking about something like:

  c = encrypt(k, m)
  sleep(rand())
  return c

Which is not what blinding is. Blinding is not really about adding a random delay as much as it is about preventing an attacker from controlling inputs to variable-time functions.

Also, it's not clear how blinding could be applied to AES.

A better strategy (and an area of research for Dan Bernstein, author of the referenced paper) is to design crypto that doesn't leak this kind of side-channel information. See, for example, his Salsa20 family of stream ciphers.