Question re accepted items

[compul]

OT: I love you two. Everyday I come back from class and enjoy your little flamewars.

[Sabbath]

OT: I love you two. Everyday I come back from class and enjoy your little flamewars.

Ha ha yes, it's good fun.

We are creating these threads to allow us to demonstrate the new features have been "considered" before implementation.

I was surprised Merlin's dog had a better retort than Merlin himself

There are more threads to start for other features which would be suitable to be implemented in the ciphershed first release, however time constraints are a problem

[Sabbath]

No civilised country is going to change the law to compel a password for something they have no evidence is there

I assume you consider the UK as uncivilized, we already have such a law, it is called RIPA. Should you be found with ANY cryptographically random data on your hard drive you are compelled by law to provide a password for it, regardless of any explanation as to how that data was generated.

If they possessed evidence prior to arrest, they would not require the victim to provide a password.

Your argument has strayed into password entropy and security of a volume rather than addressing the points I made. I am willing to discuss any topic with you, but I would much prefer to stay on the subject of obfuscation and multi hidden volumes if we could please.

I apologise for being blunt, but would you please look at my points made recently specifically regarding protection from RIPA, protection for changes to RIPA, the attackers uncertainty and the congestive benefits of multi volumes.

As soon as we can demonstrate we have considered the pro's and cons of multiple volumes I am more than willing to discuss password strength with you.

[Merlin]

If you'd bothered to properly read my answers, you'd know I'd conceded the value of one level of hidden volume, and that that in and of itself deals with any points of law raised by the (explained) cryptographic data all of the area of which is readable when the outer volume password is supplied.

With one level used properly, there is no grounds to demand a password for a hidden volume they have no proof exists, no cryptographic data is unaccounted for, it all falls within the outer (apparently normal) volume.

Any data therin is completely obfuscated.

Law dealt with, no need for more than we have.

We'd moved on to the values (so far as I was concerned anyway) of creating additional layers, you contend it's the best thing since sliced bread, I contend it adds nothing, and that if the same cumulative passwords are used, your method significantly detracts from the security.

As I see it you're trying to change the subject because you find yourself faced with an argument you simply can't refute, namely that two layers are less secure than one with the combined passwords the two would be assigned (which they are).

I've yet to see any argument presented where one hidden volume isn't enough, the only one I've seen that even looked reasonable on the face of it was "when do I stop brute forcing if I break a level?", and I just proved that if you'd strung the password from the proposed second level onto the password from the first, it wouldn't have got cracked to begin with.

Either the first level is completely deniable, or it's not, add more levels if it's not and the next isn't either by extension. if it is simply deny the first and give it an unbreakable password.

I thought the project wanted to simplify the code?

Tell me in what circumstance is one properly hidden layer with a sufficiently strong password not enough?

[Sabbath]

If you'd bothered to properly read my answers, you'd know I'd conceded the value of one level of hidden volume

I did notice and saw no need to convince you further.

With one level used properly, there is no grounds to demand a password for a hidden volume they have no proof exists

Your comment above would also imply they would have no grounds to demand a password for a drive containing pure random data. Where is their proof it is actually an encrypted container, there are other reasons cryptographically random data can be on a hard drive. I am sure you would accept, the leniency you require for your point is unlikely under RIPA.

How do you prevent a change to RIPA encompassing 2 passwords per ciphershed volume without the multiple volumes option ?

The main thing I think I should perhaps make clearer, which may be helpful, is that RIPA will make it illegal not to hand over 2 passwords when they confront a user of TC or ciphershed if the number of volumes is fixed.

As I see it you're trying to change the subject because you find yourself faced with an argument you simply can't refute, namely that two layers are less secure than one with the combined passwords the two would be assigned (which they are).

You are missing the benefit of an unknown number of hidden layers. You are still talking about password length. I am not sure why. This thread is not about the security of a given volume when you deliberately choose a weak password.

"when do I stop brute forcing if I break a level?", and I just proved that if you'd strung the password from the proposed second level onto the password from the first, it wouldn't have got cracked to begin with.

You are getting closer in the quote above apart from talking about password strength again. The uncertainty forced on to the attacker. It is not a case of password strength or even if they can break the second volume, it is how many volumes are there and has the attacker cracked the correct one.

As I will continually remind you, the congestion effect of these volumes is the killer aspect.

Tell me in what circumstance is one properly hidden layer with a sufficiently strong password not enough?

Protection against an enhanced RIPA. I think this is the point you should consider most.

The added benefit of the congestion effect.

A huge uncertainty burden placed on the attacker.

False positives when cracking hidden volumes.

This enables the user to place false documents in a hidden volume and make them just about crackable whilst still retaining the real documents. Providing the impression these are the genuine documents the attacker really wanted. With only 2 volumes this is not possible, once the second is cracked the attacker knows 100% they have access to all the files. With multiple volumes the attacker does not have the confidence to stop, adding again the the congestion.

Uncertainty, to an attacker, is shear hell to deal with. It is something you need to experience to appreciate.

[Mac]

I've been following this debate with some interest. I appreciate that the concept of multiple hidden volumes (MHV) is intriguing, but I wonder if it's really presently worthy of so much attention.

How many users actually want MHV? How many even use ONE hidden volume? MHV is an esoteric feature that mainly appeals to those with an inner crypto-geek -- but may be far too complicated for most users to operate in practice.

What users really want plausible deniability (aside from criminals); for whom is it actually important and not just a "neat feature" or a toy? Human rights workers in despotic regimes (think Somalia,Taliban, big Asian countries, ...)? Reporters (or their significant others) crossing unfriendly foreign territory -- or dealing with antagonistic local authorities? Whistleblowers? Diplomats? Ordinary citizens under duress by criminals who want to steal bit-coin stashes, or bank account info? The list goes on.

Under harsh enough duress, one might ultimately be willing to turn over the hidden volume access. Only very rarely are people willing to sacrifice life for data. I am sensitive to Merlin's arguments that providing ONLY (at most) a single hidden volume could allow convincing demonstration full compliance. Allowing MHV creates a situation where such proof (that there is no N+1) is never possible. (A corollary to take away from this thread is that every TC user should consider always defining a hidden-volume -- even if nominal -- just to prove innocence under dire pressure.) This question harbors many subtle issues, not readily answered.

There are an unlimited number of new TrueCrypt features that could be implemented. I suggest that MHV could be added any time it becomes a pressing issue. Why spend so much effort debating it now? We should be more concerned with important features with KNOWN demand -- such as UEFI support.

Where do we really want to devote our creative capital?

[Sabbath]

I've been following this debate with some interest.

I am disappointed you have read through almost 3 pages and still write some of the comments / questions you have. I guess we have not been explaining ourselves well enough, I apologise and it is useful to know for further discussions.

I appreciate that the concept of multiple hidden volumes (MHV) is intriguing, but I wonder if it's really presently worthy of so much attention.

Merlin answers in this thread.

It's called "Devil's Advocate", it makes no odds whatsoever in my own personal use case, but unless someone argues the counter case, it can't be called considered.

Just a selection of my previous points in this thread.

Another benefit is it prevents an expansion of RIPA. How long would it be before RIPA is changed to force the user to reveal 2 passwords per container ? You have effectively offered them this option by restricting the number of hidden volumes. Laws have to be worded carefully and multiple hidden volumes make this impossible to define. The only legal wording that could possibly be used to counter multiple volumes is, a victim must continue to provide correct passwords until sufficient evidence is found to convict. Obviously this would be laughable.

Multiple volumes have another very neat and devastating feature. I communicate daily with experienced hackers and crackers on my forums and the single most feared subject is that of uncertainty.

Hidden volumes introduce doubt, an attacker may brute force a volume and it opens up. If the number of volumes is fixed to 1 the attacker knows his job is done. If the total number of possible volumes is 2 then the attacker will continue, if the contents of the first volume doesn't look plausible enough.

With this "doubt" increasing with multiple hidden volumes the attacker will never know when it is reasonable to stop. This is a considerable drag on resources and extremely expensive to apply to many hard drives. The feasibility of the cost to reward escalates so dramatically the powers that be will be choked with work. Not only are you protecting your own volumes, but should your volumes be seized and worked on, you are contributing to the greater good of others who follow you.

The more I think of multiple hidden volumes the better protection I realise they provide. It is a devastating feature if you look on it from the side of an attacker.

How many users actually want MHV?

Due to RIPA being a UK law, if you require an actual figure for the number who may potentially benefit from it I would estimate about 63 to 65 million people and possibly others throughout the world. I am unable to tell you how many of those use TC or ciphershed, you would have to do your own research.

How many even use ONE hidden volume?

It should be clear, it is not how many use the feature, it is the fact the feature exists as a legal defence against RIPA.

but may be far too complicated for most users to operate in practice.

It was precisely this kind of argument which crippled TC's development in the past. Continuously rejecting advanced security features because they failed to be compliant with the lowest skilled user. I am so happy ciphershed has a better vision and reduced the value of these sorts of considerations.

What users really want plausible deniability

This thread is not about the validity of the hidden volume feature, both Merlin and myself agree on it and made it clear in our posts.

I'd conceded the value of one level of hidden volume

I did notice and saw no need to convince you further.

A corollary to take away from this thread is that every TC user should consider always defining a hidden-volume -- even if nominal -- just to prove innocence under dire pressure.

This has been covered in this thread.

You will effectively be forcing them to create a hidden volume when they don't need one. If they fail to do so, or forget the second password, they will be suspected of concealing one and a lengthy prison sentence awaits them.

We should be more concerned with important features with KNOWN demand -- such as UEFI support

Your personal bias towards a particular new feature request has no impact on the validity of MHV. Can you honestly say there is no KNOWN demand for protection from RIPA ? Really ??

It should also perhaps be made clearer, MHV is in the "Long Term Goals".

[Mac]

I am disappointed you have read through almost 3 pages and still write some of the comments / questions you have. I guess we have not been explaining ourselves well enough, I apologise and it is useful to know for further discussions.

You're explanations are clear; no need to apologize. I just think the MHV feature is not sufficiently useful to warrant much development effort at this time. Even as a long term goal I think the marginal benefits of MHV -- versus a single hidden volume -- are esoteric and probably not useful in practice. I've been involved for over 30 years developing commercial encryption software (I am out of that business now)-- and long ago learned that often the more sophisticated features -- which appeal to crypto developers (including myself) -- are almost never used in reality; and that implementation and support efforts are typically wasted. It is difficult to even persuade users who need encryption to use it -- much less to understand, implement and use hidden volumes.

Although MHV is fun to debate and imagine how a human rights worker in namibia could hide her data by clever use of MHV, there is also the possibility she is killed when she can't prove that she has indeed revealed all of her encrypted material -- an onion with no discernible depth. Actually the far greater likelihood is that she never uses TrueCrypt at all, much less understands and uses Hidden Volumes properly.

Your personal bias towards a particular new feature request has no impact on the validity of MHV. Can you honestly say there is no KNOWN demand for protection from RIPA ? Really ??

Clearly Sabbath cares passionately about MHV as a protection from RIPA, so demand provably exists.

In terms of the the validity of MHV:
(1) Merlin says it well

I've yet to see any argument presented where one hidden volume isn't enough, ... Either the first level is completely deniable, or it's not...

(2) In addition, as I have described, having an unknown number of MHV levels may actually increase coercive risk in some jurisdictions. So, on balance, it's not clear whether the meager (IMO) MHV benefits outweigh the risks of mortal duress. So, arguably (and I suspect we could debate this indefinitely), MHV may be even sometimes be a liability. As I indicated "This question harbors many subtle issues, not readily answered." -- Including matters of game theory, jurisprudence, psychology, philosophy, as well as technology, and marketplace demand and utilization. As I indicate, MHV might actually increase risk. I doubt either of us will dissuade the other from their world view and risk assessment.

So putting aside that IMO MHV might create net risk, I once again mix practical concerns with theoretical merits: Everyone has pet features, but development resources are scarce. In weighing the effort to properly design, implement, document and provide ongoing support for, MHV my opinion is that there are many other more useful things on which developers should be spending energy. Software development is always a matter of feature triage.

Of course, the opinions here are those of an audience. The developers will take whatever course they deem best and most useful. They can always revisit MHV later once they have contact with a real consumer base (who could vote on feature priority?). My vote now, with explanation, is to not be distracted by MHV. In the meantime I am certain their plates will be overflowing with Windows/8 integration, UEFI, and other urgent matters.

[Sabbath]

I think the marginal benefits of MHV -- versus a single hidden volume -- are esoteric and probably not useful in practice

I apologise for repeating myself, but we have an issue called RIPA, probably coming to a country near you sometime soon.

RIPA, if you are not already aware, basically denies 63 - 65 million people a right to encryption / privacy. A small enhancement to RIPA is a very real possibility.

benefits of MHV -- versus a single hidden volume -- are esoteric and probably not useful in practice
sophisticated features -- which appeal to crypto developers (including myself) -- are almost never used in reality

I believe the above quotes demonstrate you have misunderstood the point of MHV, certainly in the context of RIPA. MHV do not have to be used by an individual to be significantly effective, their existence and potential is enough. I hope you understand this very important point, if not please ask and I will explain further. Sincerely, I am not being sarcastic.

Clearly Sabbath cares passionately about MHV as a protection from RIPA, so demand provably exists.

Yes, this is correct. It is the only protection as far as I know, I would be the first to welcome an equally effective alternative.

Your first point where you use Merlins statement.

I've yet to see any argument presented where one hidden volume isn't enough, ... Either the first level is completely deniable, or it's not...

As I mentioned at the time, the argument is enhanced RIPA.

Your second point is a variation of your "human rights worker in namibia" argument. A similar question has already been answered in this thread, however...

Your Namibian protagonist should choose (TC, DiskCryptor or the first release of ciphershed etc) which are restricted in functionality to 2 volumes. She must set up and remember both passwords for each volume. Otherwise perhaps a file based encryption tool.

In return, can you suggest alternative software for millions of potential users faced with enhanced RIPA ?

Undoubtedly you will find this hard to believe, but I am unlikely to be using multiple hidden volumes personally. I still regard them as VERY important for the many reasons I have mentioned. The simple fact MHV are available is enough to protect myself and others. Without MHV, single hidden volumes are useless to us when confronted with enhanced RIPA. I could repeat the other benefits but I am reluctant to appear as if I am bombarding you with quotes, rather than replying directly.

Rather than simply denying the valuable need for MHV, it would be far more productive if you could provide an alternative, particularly something as effective against enhanced RIPA. Even better if your idea also encompassed the other benefits of MHV I mentioned throughout this thread. Your 30 years experience will provide you with an enormous head start over me, so I already anticipate being overwhelmed. If you can demonstrate or even just describe such a feature, then I will happily back your case to drop or delay the implementation of MHV.