4 ms·

Cryptanalysis IMO is an on-going process and it needs to be done at every version. The funding will not last. True we need the first analysis, but who is there

by yeukhon 13y ago

Cryptanalysis IMO is an on-going process and it needs to be done at every version. The funding will not last. True we need the first analysis, but who is there to fund the 2nd, 3rd, 4th, etc? edit I am not shooting down. Just thought we have to be explicit that this is not a one time thing. I do think once it is verified and studied, and people like it, the contribution will continue to come. We might be able to build new products out of truecrypt.

munin 13y ago
in theory, it doesn't need to be. you could formalize the definition of the TrueCrypt cryptographic protocol in cryptol[1] and then have a checker run as part of unit tests that verifies the source code is still a faithful implementation of the protocol... 1: http://corp.galois.com/cryptol/ http://corp.galois.com/cryptol/
- yeukhon 13y ago
  I am not familiar with this, but an implementation flaw or bug could be an intentional backdoor. Can we automate checking process? That probably requires humans to audit the source code. How big is TrueCrypt and how many contributions does it get? Certainly Linux kernel is so big and gets so many patches a day that even changeset analysis can be hard.
- 0x0 13y ago
  Would that be able to detect even /accidental/ bugs like the ultra-weak Debian OpenSSL random number generator?
rinon 13y ago
Analyzing changesets is a much more manageable process than an initial audit, so keeping this going via community involvement might be quite possible.
- yeukhon 13y ago
  Yeah. I am not shooting down. I agree if this is a good software and people like it people will probably contribute. Just thought the process can't be stopped after its initial.
tptacek 13y ago
That's not the goal of the project. The bar isn't "spend this money and we can assure Truecrypt is strong in perpetuity". It is instead "Truecrypt is very popular and nobody knows the provenance or trustworthiness of any of its low-level crypto design, and that needs to be fixed". The project makes more sense when you realize how untrustworthy that code might be today.

by yeukhon 13y ago

munin 13y ago

in theory, it doesn't need to be. you could formalize the definition of the TrueCrypt cryptographic protocol in cryptol[1] and then have a checker run as part of unit tests that verifies the source code is still a faithful implementation of the protocol... 1: http://corp.galois.com/cryptol/ http://corp.galois.com/cryptol/

yeukhon 13y ago
I am not familiar with this, but an implementation flaw or bug could be an intentional backdoor. Can we automate checking process? That probably requires humans to audit the source code. How big is TrueCrypt and how many contributions does it get? Certainly Linux kernel is so big and gets so many patches a day that even changeset analysis can be hard.
0x0 13y ago
Would that be able to detect even /accidental/ bugs like the ultra-weak Debian OpenSSL random number generator?

rinon 13y ago

Analyzing changesets is a much more manageable process than an initial audit, so keeping this going via community involvement might be quite possible.

yeukhon 13y ago
Yeah. I am not shooting down. I agree if this is a good software and people like it people will probably contribute. Just thought the process can't be stopped after its initial.

tptacek 13y ago

That's not the goal of the project. The bar isn't "spend this money and we can assure Truecrypt is strong in perpetuity". It is instead "Truecrypt is very popular and nobody knows the provenance or trustworthiness of any of its low-level crypto design, and that needs to be fixed". The project makes more sense when you realize how untrustworthy that code might be today.