>WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues
WHAT DOES THIS MEAN?
They stopped developing it, so any unfixed bugs or security issues found will not be fixed.
>>54731451
is there a fork?
what is an alternative?
>>54731456
VeraCrypt
>>54731456
best option now is probably VeraCrypt which is a direct fork of TrueCrypt 7.1a
I heard they are close to making system drive encryption work with UEFI bios aswell
https://veracrypt.codeplex.com/
>>54731479
No. Don't use that. Only TrueCrypt.
>>54731486
>veracrypt.codeplex.com
>hosting security software on a m$ platform
>>54732488
>using veracrypt on a windows os
>>54732502
why did you quote me? i would never use windows
>>54731426
>WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues
>TrueCrypt is not secure as
>TrueCrypt is NSA
I use CipherShed, another fork of TrueCrypt. Does exactly what I need it to.
Devs got grabbed by the balls and there will be no more updates, though source code audit shows that there are only a couple of minor vulnerabilities which don't affect encryption strength.
>>54731486
Which is impressive because that is almost a rewrite of some parts of it, and the build system is rusty as fuck. It is a hard piece of software to maintain.
Or, you know, so I've heard. Ahem.
>>54732579
What if I told you the vulnerability is actually Windows ?
>>54731426
Story is that Truecrypt's developer was blackmailed out of supporting the program by the NSA. Apparently version 7.1a is safe (from backdoors, etc.). But since it hasn't been updated to fix potential problems there's a strong possibility that authorities or hackers have already broken it.
>>54731479
>>54732473
Real pedos use dmcrypt implementations of the TrueCrypt/VeraCrypt "standards" (or, better, plain dmcrypt)
Step up your pedo game senpais
>>54732696
I don't have any nude pics of children or loli/shota.
I find it incredible that we STILL don't know the real identity of the developers.
They created a software used for a decade by pedos worldwide, they had a forum, they released interviews e.g. to Rutkowska.
They had their own sites up and running way before DomainsByProxy was a thing. They never bothered to run a Tor service for their site AFAIK.
Yet nobody, no one, knows their identity. Not even know.
That's enough proof for me that they are actually NSA. The fact that so many times mismatching binaries were found on their site is enough. The NSA create a standard they could cripple "ad hoc".
>>54732733
Then you don't have anything to hide. Why don't you use Bitlocker (if Windows)/Filevault (if Mac) to defend yourself against the anecdotal nigger stealing your laptop?
>>54732752
We didn't know the identity of Satoshi until last month, and even now many people are saying it isn't him. Staying anonymous isn't all that remarkable.
>>54732818
>Staying anonymous isn't all that remarkable.
In crypto, it is. Developers in crypto apps shall never be anonymous.
>>54732752
One of the original developers, back from the E4M software it was a fork of, was Paul la Roux. Look him up. He's a fascinating fellow, albeit not in a good way.
The rest? Look, cypherpunks tend to not reveal our identities when releasing controversial software. It's traditional. You, of all people, should come close to understanding our reasoning there. It's the same reason why jrand0m (and all of us really) stayed pseudonymous for I2P; the same reason Satoshi Nakamoto did for Bitcoin. Shit goes all the way back. The culture indicated "real" identity is irrelevant; trust is a weakness; nyms build reputation sans identity. To ask who they are is almost disrespectful: results are what matters, not provenance or pedigree. Source code and papers speak louder than manifestos.
I audited it before the recent audit. TC was legit. The people who made it, eh. Veracrypt's authors, I'm not sure about.
Could really use reproducible builds, but not with that toolchain they can't.
>>54731426
It's the only way they can say it has been compromised
>>54732846
Fuck that noise. My next project is being released pseudonymously, just like my last one was. I'm not even going to use the same nym: because reproducible, analysable scientific results, source code and binary integrity matters. My identity doesn't.
If you're trusting identity you're trusting them to not get compromised, probably trusting their reputation more than even they think you should. If you have audited source code, security proofs and reproducible builds, you're not.
Let's not forget even the NSA can deliver good shit (SHA-2, selinux, some DRBGs) as well as bad shit (DSA, ECDSA, Dual_EC_DRBG). Identity tells you less than you might hope. I think even the best of us wouldn't ever wish to be blindly trusted. For heaven's sake, verify.
>>54731426
BOTNET
O
T
N
E
T
>>54732937
>integrity matters. My identity doesn't
In crypto the standards for transparency are different.
>If you're trusting identity you're trusting
It's not a matter of "trusting identity". It's a matter of transparency.
>NSA can deliver good shit
Sure. One of the TC forks is lead by people with NSA/FBI ties. It's all fine if you disclose your identity and your connections.
>>54732752
It makes no difference who the developers were for TrueCrypt, since the entire product was basically a fork of E4M, developed by the cartel boss/CIA informant Paul Le Roux. Without Le Roux/E4M, there would be no TrueCrypt.
>>54733019
Not the guy you're answering
But you obviously didn't get the point and have your head too far up your own ass to review your personal opinion.
>>54733616
Ask any cryptographer, then unstuck your head from your own ass.
>>54731426
maybe you should actually ask someone who knows.
just kidding, just use it like it. :^)
>>54733655
I am one, which is part of my point: you have no reason to believe me of course. So go ask another too, and verify.
Look, you're reasonably and correctly worried about subversion: demanding and relying on trust in the identity and reputation of the developers blindly is really not the way to go. Protocols with a Trent always suck. You're right the standard of transparency is different - but the threat model demands reproducible, verifiable security proofs, thorough audits, fully open source code, reproducible binaries.
Doesnt matter who a dev is, if a trojan to the machine, a wrench to the knees or a gun to the head could coerce almost anyone into (knowingly or not) subverting the trust blindly placed into them. We need to be able to prove integrity - and that is not a function merely of developer identity, but of the actual product itself.
Why dont you just use LUKS on linux?
