CipherShed Forum

Some ideas...

Principles
- Simplicity comes first. Clear code comes first. Cleaning up and annotating code comes above new cool features.
- Thoroughly annotating (and simplifying) TC codebase is a top priority, as it will have two effects: make all future programming much easier; make the project more attractive to auditors, new team members (it will increase the eyeballs). Any variables or strings that have bs names, need to get renamed to very clear things and comments need to be clear enough and long enough for an ape to understand.
- A new feature will not be added until all previous features are well understood by >2 team members
- New features will not be added until they are well tested. A clear distinction will be made between experimental versions and stable versions.
- Team members/code maintainers will be carefully vetted. Remember how an intel employee was pressuring Theodore Tso to only use CPU hardware random, but he couldn't explain why entropy mixing was worse? Funny how that happens.... https://plus.google.com/+TheodoreTso/posts/SDcoemc9V3J

Goals / Ideas
- perhaps fewer encryption schemes or nested schemes?
- perhaps dramatically increase max pwd strength of the TC code. (max=64 now, I think)
- maybe three password lengths? small, user defined, and huuuuuge/max?
- maybe drop windows support (to save developer time) or turn windows into a permanent legacy module without new features? (edit: someone pointed out how that will hurt the popularity. So maybe I'm totally wrong on that idea)
- warning splash screens for windows/mac users, that the OS itself might render encr. meaningless in some cases.
- maybe make a timekeeping section so that programmers can detail how much time they've spent on stuff in case God wants to give a donation later. Figure out a way to give the project way more credibility than TC did.
-perhaps set up challenge contests, where people are invited to test weaknesses in the releases or to test weakness in various containers that have varying levels of password. A level 1 contest: password = HiMom A level10 contest:password = 9Mn6C/V,Ma\f2kd9&N
-(optional): celebrate new releases with "email a container to your friends day"
-Invite people like Schneier/Green to give his opinion. "If you had to do this from scratch with only two schemes (weak, and ridiculously strong), how would you do it?" This could be part of removing any intellectual property TC concerns.
-For windows/mac versions, make some official videos or splash screens so that {edit} ANYONE could understand them easily. The more people do it, the more expensive it gets to violate their rights. Splash screen: there is no gaurantee that what is secure today is secure tomorrow, and everything on the net should be assumed to archived.

Sorry, one more idea:

Make a stripped-down, super secure LTS version every few releases.
I mean like REALLLLLY stripped. One very strong encryption scheme for containers and that's it.

Something so streamlined that auditors, hobbyists, programmers, almost anyone can read the code.

That alone will increase eyes, increase security, and may become the buck knife, not the Swiss army knife, beloved my many sysadmins, etc.

Resonance wrote:Some ideas...

Principles
- Simplicity comes first. Clear code comes first. Cleaning up and annotating code comes above new cool features.

Amen to that.

Resonance wrote:
Goals / Ideas
- maybe drop windows support (to save developer time) or turn windows into a permanent legacy module without new features?
- warning splash screens for windows/mac users, that the OS itself might render encr. meaningless in some cases.

As much as I personally would love to drop Win support to just tell Windows users to go and use Linux, that is not possible for us or them. Too much software runs only on Windows, and for many people it's too much of an effort to switch -- or even impossible. Also while Win encryption is not going to protect you against governments, NSA & co., it might protect you against other adversaries in other situations, so it's stll better than nothing. I kind of like the idea of informing the user about the weak spot on those systems though.

Resonance wrote:- maybe make a timekeeping section so that programmers can detail how much time they've spent on stuff in case God wants to give a donation later. Figure out a way to give the project way more credibility than TC did.

For credibility; against the time/donation thing. Everyone should work on it not for the fame or the money, but only to contribute to the project. It will give wrong incentives.

I like some of the ideas you give. Still, I feel we should not get too carried away. Keep it simple. E.g. something streamlined could probably be done by dm-crypt. The value in TrueCrypt lies, in my opinion, in great parts in it's nature as the swiss army's knife that is compatible with all large platforms.

Of course, things like that can be discussed.

I agree about money. Few people can keep perspective, better to let it be all about the result.

I agree with you on the 3 platforms too. Anything on 3 will be a million times more popular than something only on linux. And that popularity will enable something resembling a standard. I was just thinking about developer time. If you can do it, great!

My only beef is that win/mac users need a splash screen to be better informed. And anyone opening a container should try to figure out how many colleagues on win platforms have already opened the same file with the same pwd.

- maybe drop windows support (to save developer time) or turn windows into a permanent legacy module without new features?

And leave Windows users stranded with only obscure or unmaintained options.. When Linux already has FOSS encryption available..
This would basically leave the project as a pointless excercise.

TrueCrypt started as a Windows solution, the userbase is mainly Windows users, Unless you aim to keep it that way, you may as well throw in the towel now, truecrypt.ch will appear to be the only viable option, and people will flock there.

Merlin,
I see your point. I wasn't aware of the background. I apologize for my ignorance.

Given that TC basically mounts volumes by trying all the possible schemes in order..
I suggest a phased release program where each version checks volumes on mounting and warns if support for it is likely to be dropped in the next version, prompting for people to retire such volumes, and create new instead (unless they can be upgraded in place).
This way support for older CBC and LRW volumes could be dropped fairly painlessly.
Since one of your stated goals is simplification, this legacy support seems an obvious target, especially since you already can't create anything except XTS anyway.
In order to move the hashing iteration count forward, you may find yourselves having to support mounting volumes using the old scheme while creating them using the new, in order to make transitioning as painless as possible, rather than breaking compatibility as VeraCrypt does.
For WDE, it's probably going to take a complete decrypt/re-encrypt + new rescue CD to make the step up in security, that's fine
But please, for heaven's sakes if you do that, force CHKDSK /R before the decrypt (and before a new encrypt) the current program version causes endless issues should it encounter a grown drive defect. Stalled in-place encryption / decryption was a common issue on the old forum mainly due to this factor.

Merlin, it's fantastic you know so much about the TrueCrypt! I hope you'll join us in moving the code forward. I don't think we have anyone on the team yet that is quite this knowledgeable about the TrueCrypt details. Having you on the team would be wonderful.

Given that TC basically mounts volumes by trying all the possible schemes in order..
I suggest a phased release program where each version checks volumes on mounting and warns if support for it is likely to be dropped in the next version, prompting for people to retire such volumes, and create new instead (unless they can be upgraded in place).
This way support for older CBC and LRW volumes could be dropped fairly painlessly.
Since one of your stated goals is simplification, this legacy support seems an obvious target, especially since you already can't create anything except XTS anyway.
In order to move the hashing iteration count forward, you may find yourselves having to support mounting volumes using the old scheme while creating them using the new, in order to make transitioning as painless as possible, rather than breaking compatibility as VeraCrypt does.
For WDE, it's probably going to take a complete decrypt/re-encrypt + new rescue CD to make the step up in security, that's fine

I think your suggestion for warning users to upgrade volume formats due to pending depreciation is a good one. Maybe would could switch to the common *nix convention of major and minor release numbers, and require that the user remember the major version number in addition to the password and key file if any. When we switch major version numbers, we could drop support for the outdated formats.

But please, for heaven's sakes if you do that, force CHKDSK /R before the decrypt (and before a new encrypt) the current program version causes endless issues should it encounter a grown drive defect. Stalled in-place encryption / decryption was a common issue on the old forum mainly due to this factor.

That's good to know! I would make that mistake.

compul wrote:

Resonance wrote:Some ideas...

Principles
- Simplicity comes first. Clear code comes first. Cleaning up and annotating code comes above new cool features.

Amen to that.

I think we're all in agreement here. I also agree with every point compul made. How's this for a lame reply

I think it is significant that so many people are pushing the same ideas, such as simplicity and security first before new features.

@Resonance, @Merlin, @compul

I applaud what you guys are doing -- it is noble and useful. As far as I know TrueCrypt is the only OPEN-SOURCE cross-platform WDE available -- anyway, it is certainly the most venerable. It's worth preserving and its massive user base will be grateful.

I recently worked in proximity to a team making local feature changes to TC. While I have no direct knowledge of the code, I have spent numerous hours discussing issues with those developers.

Let me offer some observations:

I generally agree with @Resonance's set of stated "Principles". However I have observations about some of the other "Goals/ideas", and concur with most comments by Merlin and compul.

1) You are discussing cutting down the number of algorithms.

I suggest this is not necessarily a useful notion.

The bulk of complexity you'll need to deal with is not in the crypto or the algorithms. You will find the system interfaces to be many binary orders of magnitude more complex than the crypto algorithms -- which are pretty simple, stable, self-contained and cut-and-dried.

Handling a variety of them should be, if it is not already the case (as I believe it is), done with tables. So if you can handle more than one -- have a way of handling options -- then dealing with an indefinite number should be easy (even with cascaded suites -- where a cascaded suite is really just an interface wrapper for a compound set). And building the table of active algorithm objects is a rather minor piece of code.

So eliminating algorithms is not really going to meaningfully reduce the complexity, or make a software audit significantly easier.

However, what is does do is make your new version pretty much incompatible with every existing user's TrueCrypt'ed disks, media, and file containers.

This is pointlessly painful and will be, or at least seem to be, almost punitive. Not user friendly at all. Much of the appeal of preserving T/C is operational continuity and consistency. The world is not begging for yet another incompatible WDE product.

2) It is suggested

-Invite people like Schneier/Green to give his opinion. "If you had to do this from scratch with only two schemes (weak, and ridiculously strong), how would you do it?" This could be part of removing any intellectual property TC concerns.

a) I don't understand your artificial dichotomy of "weak" and "ridiculously strong". Who in the world would possibly desire "weak"?

If there is any dichotomy, it would be "faster" vs "stronger". But even these are relative to a user's needs, perceptions, and opinions. Some judge Serpent or Twofish stronger or swifter than AES; others want or need AES because it is officially blessed. Some may be required by policy to use AES, yet harbor doubts, and want to layer another algorithm as belt-and-suspenders. I actually think the TrueCrypt designers did a pretty good job: allowing so many layered different options of strength vs speed (any non-trivial subset of AES, TwoFish, and Serpent). It is brilliant, effective, meaningful.

If you feel algorithm selection is confusing for users with less crypto expertise, you might suggest a suite optimized for speed, and one optimized for strength. But I urge you not to discard customized specification.

b) What TrueCrypt Intellectual Property concerns are referring to? As I understand the license, especially as apparently recently amended, the main issue is with using the name, Anyway, not sure how changing algorithms is particularly meaningful when you are subsuming thousands of lines of code.

3) Allowing for longer passwords is fine. But for the reasons already given -- compatibility -- existing length passwords should still function seamlessly. It is unclear why having explicitly three password lengths (or even just two) is useful. Confusing at best. Just allow the single password field to be longer. However long the password is, will be its length. Simple. While you might offer advice as to why longer is better, I think is a mistake to meddle too much in a user's choice.

However, a password maximum of 64 is probably fine for now; there must be higher priority issues to worry about at the moment.

4) The comment about

warning splash screens for windows/mac users, that the OS itself might render encr. meaningless in some cases

applies to ALL operating systems.

I believe Snowden's revelations indicate penetration of many Linux servers running Apache and other product. Weren't Linux servers were also affected by the Heartbleed bug.

5) The gratuitous comment about

apes and older people

comes across as rather arrogant and demeaning. I think the process should be streamlined so that *anyone* -- whether they be elderly corporate executives, young housewives, or grad students; computer savvy or otherwise -- could install and use the product easily.

6) I firmly concur with compul and Merlin: the bulk of users are probably on Windows, or use at least one Windows system to access their data -- and they probably constitute the bulk of your audience.

7) I am alarmed about WaywardGeeks' suggestion that older (data) formats become unsupported. Changing the format of a sitting volume is an arduous and risky proposition for anyone, especially those who are ordinary users and not IT professionals. Many people in the real world do not have enough time, inclination, or expertise to copy over entire hard disks except in dire circumstances,and then they often turn to someone else. It may seem straightforward to you, but I guarantee for most people it is not.

Once you have a large infrastructure of existing users locked into a hard-to-change format, the software should make every effort to maintain compatibility. Consideration of this eventuality should be built-in to the thought process and software design at the outset. This is one thing that separates user-friendly software from "geeky" developer-centric product.

If you must deprecate a format or algorithm because it is has become notoriously broken, then you should, at worst, inhibit that format or algorithm being further used to create *fresh* instances -- but do not invalidate existing instances.

My knowledge of Linux history is incomplete, so I hope I get this analogy correct: However I do not think Linus forced users to upgrade all their "ext3" formatted file systems to "ext4" when that new file system was introduced, nor to convert FAT32 file systems to a Linux preferred file system in order to access them (even though ext4 is no doubt a more robust format).

The goal of "Simplicity" for is laudable. Simplicity for users is even more important.