Is there any on-the-fly encryption app that truly support work with containers? EDS is shit btw

I am unfortunately less versed in what is available on arm / android.

It sounds like luks meets what you are asking for if you just want the disk itself to be encrypted. But it sounds like veracrypt should be able to do the same thing. is this just a limitation of android?

you should be able to mount an encrypted sd card and r/w to it on the fly. moving a container to the sd card will automatically encrypt the container resident on that drive. Drawbacks are the container is not encrypted across systems, and as long as the device is on and the card is mounted the crypto key must be in memory.

You realize TrueCrypt's license explicitly forbids forks, and with good reason. TC has been audited, VeraCrypt has not. For all you know, VeraCrypt is just some NSA backdoor fork of TC.

>but out-of-date software isn't secure

Yes it is. That was the entire fucking point of the audit. TC is proven secure, and it's going to remain secure no matter how dated it is. At least until the government can effectively crack the encryption strength available to TC.

hmmm... that is true. also, fully encrypted sd card is "locked" to the specific phone and will not work if removed in ecrypted state. and it is pain in the butt to decrypt say 32 or 64 G just to be able to remove the card. this is why i'm looking for piece of software that is able to create containers on sd card. anyway, thanx for your effort.

en.wikipedia.org/wiki/Paul_Le_Roux
i guess one should respect the boss...

the data on disk is always encrypted once it has been encrypted. the only place it gets *unscrambled is in memory where any work on the data is being done. all you should have to do is dismount the disk and its good to go. it shouldnt take more than a few seconds.

>i guess one should respect the boss...

That's curious. Although I'm not sure how this makes a case for using VeraCrypt, since it's a fork of the same software designed by this individual.

The most important thing to consider is this: TC is audited. The audit found nothing suspicious. TC has been objectively proven to be safe and secure. VeraCrypt has not been audited. You have no idea what respective changes VC's author has made to the codebase, including the possibility of any backdoors. So why are you using VeraCrypt?

>But it will be known if the suspect used encryption. Encrypted hard drives don't magically decrypt themselves. Depending on encryption scheme one can try to figure out how they were decrypted.

So the obvious choice for a thought experiment here is the kill of OBL and the recovery of his laptops / devices. We can probably safely assume that his everything was encrypted, and yet we got into it "his favorite pornstar, he thinks isis shouldnt start a state etc...."

Now we can look through the obvious psyops games going on here. For this specific example lets focus on the lack of controversy surrounding the claimed decryption of high value data. Because of the secrecy involved in the exfiltration of data from these devices, nobody has gone of the deep end pointing fingers at truecrypt or bitlocker and nobody claims a backdoor.

all it would take in a fisa court or in the OBL case to impune any allegations of a backdoor is to suggest the currier or some witness / wistleblower exfiltrated the keys before prosecution.

>I seriously doubt there is a backdoor in the bitlocker scheme. If it was Microsoft would lose their enterprise customers and it would be impossible to sell their solutions to defence contractors.

defense contractors would be the last ones to jump ship imho.

There were some minor problems with TC found during the audit, nothing earth shattering. but problems nevertheless.

There are good arguments to using both TC and VC, in reality I think both are probably good options.

>but problems nevertheless

Problems intrinsic to every full-disk encryption method, such as cold-boot attacks. VeraCrypt has not and cannot do anything to address these flaws because they are intrinsic to the method of encryption. The only way around something like this is using a boot disc instead of a bootloader, which TC allows you to do.

>There are good arguments to using both TC and VC
>and VC

No there aren't, and you've yet to post anything that supports VC.

there were some problems with the TC rng in windows and vulnerabilities to cache timing attacks.

and yes VC HAS fixed these.

No idea what you're referring to. The only "vulnerability" I've seen VeraCrypt patch out was an obscure exploit involving DLL injection. The party injecting the DLLs had to go through very specific means to plant the DLLs in your Downloads folder *before* you ever ran the TC installer. If you're installing TC on a freshly reformatted computer - or you already have TC installed, or are using a portable version - then there's no way you could ever feasibly be the victim of such an exploit. It's not even worth mentioning.

EFI, new implemented algorithms, SHA-256 for Master Boot Record encryption, detects evil-maid attacks in the MBR, additional compatibility for TrueCrypt volumes that allow for an easier transition to VeraCrypt, and a new feature called PIM, or Personal Iterations Multiplier, which enables the user to choose different security levels for volumes, fix TrueCrypt vulnerability allowing detection of hidden volumes presence, russian encryption and hash standards Kuznyechik, Magma and Streebog, including for Windows EFI system encryption, support Japanese encryption standard Camellia, including for Windows system encryption (MBR & EFI)

I havent read this, but I did google it.

veracrypt.codeplex.com/discussions/569777#PostContent_1313325

it is specifically relating to the audit

i'll also point out that you are defending TC like I'm trying to impune it. I'm not the disclosed issues with TC are existant but minor. Nonetheless VC has patched them.

Thanks for correcting the record, although none of these issues seriously compromise TC and can be subverted largely by exercising common sense... or not using Windows.

The fact still remains that VeraCrypt has not undergone an audit. There is a very real possibility the person(s) maintaining the fork are working for the NSA and have backdoored the program. The fact that so much pro-VeraCrypt editing and discussion is directed at the TC article over at Wikipedia definitely raises my suspicion.

the suspicion is not unwarranted, and there are oldfags among us who also watched the same suspicion leveled against TC for MANY reasons. Even allegations that TC! was developed by the NSA "how can we know, nobody knows who develops it".

It seems that after the audit, those allegations can be put to rest.

However even if TC is safe today, there will be attacks against TC that get better over time, the recent SWEET32 attack on cyphers such as blowfish are good case study of this. We should be looking to the future for something that can carry the weight that truecrypt has carried, and veracrypt appears to be the phoenix from the ashes. I think it will stabilize and be the standard going forward for people looking for cross platform encryption.

>TrueCrypt's license explicitly forbids forks, and with good reason
it's a civil violation. For some reason, I don't really see the Truecrypt authors popping up and pursuing legal action against forks. It's essentially abandonware at this point.

Priviledge escalation attack on Winows platforms isn't exactly minor. Also, the iteration count of password based key derivation isn't as good as it could be. Not that it matters with strong passwords / when keyfiles are used.

Sweet32 isn't an issue with 128-bit blocks sizes AES, Twofish and Serpent use.

The algorithms are all 256 bit so no, I don't think the attacks are going to break key sizes either.

The only attacks that improve over time are against weak passwords.