[kwlug-disc] Truecrypt

[unsolicited]

 > So, the assumption that if a piece of code is OK now then it will be
 > OK forever is deeply and dangerously flawed.

Which is neither what I said, nor what I intimated.

The things you mention are in use despite any flaws, and there is 
nothing to think doing so inappropriate.

Given the context, there is no reason to believe the same is not true of 
TrueCrypt at this time.

To say otherwise is irresponsible.

Else the world would be shutting down TrueCrypt now, and every other system.

They are not.

Your characterization was and is offensive and actionable.


On 14-05-30 06:46 PM, Bob Jonkman wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Even if a piece of software passes both a code review and a security
> audit to verify that its code properly implements the security
> algorithms (assuming those algorithms are sound in the first place),
> it is possible that the audit team will miss some minor flaw that can
> be exploited later. After all, the OpenSSL code passed a code
> review[1] that completely missed the Heartbleed bug. And GotoFail. And
> Debian PRNG. And any flavour of Windows. Think Microsoft doesn't do
> code reviews/audits?
>
> Even if the code is flawless, bugfree and properly implemented there
> may be bugs in the compiler that cause the binaries to behave in ways
> that the source code doesn't predict.  Will there be a code
> review/audit of the compiler? AFAIK the targeted compiler for
> TrueCrypt is a 10-year-old version of Microsoft C. Good luck in
> getting the Open Crypto Audit Project access to that source code.  And
> even then, it's worth re-reading Reflections On Trusting Trust[2].
>
> And even if the compiler is flawless, bugfree and creates flawless and
> bugfree binaries, there will be updates to the Operating System that
> runs the binaries.  It is entirely possible that a shift in the OS
> paradigm (init.d? Upstart? SystemD?) invalidates some compiler
> assumption, so that the binaries no longer behave as expected. Or
> worse, that the compiler is designed to work around some flaw in the
> OS, so that when that OS flaw is fixed the compiled binaries exhibit a
> new flaw that doesn't exist today.
>
> So, the assumption that if a piece of code is OK now then it will be
> OK forever is deeply and dangerously flawed.
>
> - --Bob.
>
> [1] http://veridicalsystems.com/blog/of-money-responsibility-and-pride/#9
>
> [2] http://cm.bell-labs.com/who/ken/trust.html
>
>
>
> On 14-05-30 05:57 PM, Khalid Baheyeldin wrote:
>> If I read Bob's comment correctly, he is objecting to the
>> extrapolation on that the future audit is most likely positive.
>>
>> On Fri, May 30, 2014 at 4:40 PM, unsolicited <unsolicited at swiz.ca>
>> wrote:
>>
>>> And others from here below:
>>>
>>> On 14-05-29 12:03 PM, Khalid Baheyeldin wrote:
>>>> ... If the previously audited version was safe, i.e. works as
>>>> designed,
>>> then ...
>>
>>
>> The initial audit was to verify that the binaries do indeed
>> correspond to the published source code, and that no backdoors have
>> been slipped in the binaries. That much was verified.
>>
>> But all that applies to the 2012 version (7.1a). The one that was
>> just published this month removes a lot of features, and has not
>> been audited in any way (beyond the diff between it and the
>> previous version).
>>
>> Another note: someone is saying that a flaw will disclosed soon.
>>
>> http://soylentnews.org/article.pl?sid=14/05/30/1318243