A public TrueCrypt Audit

Re:A public TrueCrypt Audit by tedunangst on Thursday October 10, 2013 @02:17AM (#6525971)

  void
  encrypt(void *data, size_t len, char *password)
  {
    char key[32];

    turn_password_into_key(password, key, sizeof key);
    aes_make_encrypted(data, len, key);

    memset(key, 0, sizeof key); /* optimized away */
  }

The compiler knows what memset does. It also knows that stack variables have no use after the function returns. Therefore, the compiler knows there is no reason to write zeroes to this memory, because the program will never read those zeroes. Hence, the compiler will delete the call to memset.

[ Parent | on HN ]

Re:A public TrueCrypt Audit by foobarbazqux on Thursday October 10, 2013 @02:31AM (#6526015)

Oh I get it. You're saying the key is stored on the stack and then you can find it by inspecting memory if it hasn't been zeroed out. That's really interesting, what a great example of leaning on language implementation. I guess the correct way to write this is to malloc and free the key. Except, couldn't an attacker see the key anyway while it was live in memory, either on the stack or on the heap (or if it's not "heap", whatever you call the thing that malloc takes memory from)?

[ Parent | on HN ]

Re:A public TrueCrypt Audit by tribaal on Thursday October 10, 2013 @02:50AM (#6526074)

I'm not a specialist, but wouldn't a call to free simply deference the memory, but not zero it out? you can then probably still find the key by inspecting memory? again, I'm not a good C programmer, I would like to know too :)

[ Parent | on HN ]

Re:A public TrueCrypt Audit by foobarbazqux on Thursday October 10, 2013 @04:49AM (#6526402)

Yeah, you'd still need to call memset before free. Compilers have a much harder time convincing themselves of things about pointers, so it should survive dead code elimination.

[ Parent | on HN ]

Re:A public TrueCrypt Audit by kingkilr on Thursday October 10, 2013 @06:02AM (#6526621)

This is what memset_s is for.

[ Parent | on HN ]

Re:A public TrueCrypt Audit by MacsHeadroom on Thursday October 10, 2013 @09:33AM (#6527520)

So what we have here is the potential for a backdoor caused by a 2 character difference in code.

Backdoors in source can be as simple as changing a single == to = or removing a minus sign in some seemingly innocuous place.

[ Parent | on HN ]

Re:A public TrueCrypt Audit by tedunangst on Thursday October 10, 2013 @11:05AM (#6528106)

Not everybody programs against the C11 standard.

[ Parent | on HN ]