Page 1 of 2

Re: hidden full system encryption on gnulinux?

Posted: 2016-05-20 10:08
by dryden
edbarx wrote:Police represent authority which means a citizen's refusal to cooperate with their investigations is often seen as a corroborate that there is something sinister to hide on the part of the investigated.
You disregard experience just fine. And common sense as well. I mean how .... can you be? The rule of law implies that criminal facts need to be proven.

Unless hiding evidence itself is a criminal act, you cannot be prosecuted for hiding any form of information.

I repeat: you cannot be prosecuted for such things.

They *have* no information on you. Therefore, they can also not really get away with doing anything to you based on nothing but the "random thought" that you are hiding something sinister based on nothing, particularly if you can justify what you do against a judge, or argue your way out of it, no matter how you wish to express that.

I have hidden data and this has made no difference whatsoever in a case against me, because it was not even a computer case to begin with, and the only consequences have been
  • some amusement as law enforcement first tells me that they "will crack it just fine" but subsequently continues to plead with me and beg with me, even 6 months after the fact, for the passwords
  • a measure of respect from these people as I did not comply, and as such, they had to see me as an equal of sorts
  • the fact that due to their decryption attempts, I did not get my stuff back within the same time frame as I otherwise would have.
In reply to your argument about "privacy", well, I value more my freedom, rather than risking a free stay at some police lockup facility or a prison.
Then I will respond by saying that you are rather uneducated, and it was none other than Theodore Roosevelt who said "Those, who would give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety", perhaps as a citation of others, I do not know. This was in response to the statement, or following the statement, that "No realistic American can expect from a dictator’s peace international generosity, or return of true independence, or world disarmament, or freedom of expression, or freedom of religion - or even good business". And it implies exactly what is being said here.

So, people who "reason like me" are sometimes people in very good standing and far greater people than you or me have ever been thus far.

Your freedom then, is a lack of freedom. You sacrifice your ability to encrypt in the first place, only to bow down to law enforcement who tries to take that freedom away with you, with the promise that then they won't imprison you. And in the end you will find out you have been scammed.
People who reason like you are forgetting the state has authority and I, you and every common Joe have none.
Only if the state is without laws, and can act like a complete and utter tyrant, does your statement make any sense. The laws of the state often serve to protect civilians from abuse of authority. And even then, if you stand tall enough, you will garner respect, and I can tell you from experience that thus far they have had nothing on me as a result of encrypting some disks. I really doubt you have any experience whatsoever, in that sense.

Judges in my country at least are critical beings who often have their own doubts as to the proper behaviour of police, and do not necessarily fall in line with whatever police is doing. They are usually rather intelligent people or they would not take office like that. They study law and are used to complex reasoning, they are also used to disregarding "underbelly sentiments" in favour of what the law actually says is allowed, and what not.

If you read jurisprudence (in this case, civil) you will often find extremely logical reasonings reducing a case to a single point that needs to be proven, disregarding everything else, because it has already been dealt with. Even though this takes away the heart out of it, and reduces it to something formal and nothing more, it does indicate that, especially in the case of criminal proceedings, judges are not unwilling to follow the letter of the law, and if you know it, the law provides much more protection for civilians than the random and spurious opinions of law enforcement officials.

In this my country it is not possible really to use a hiding of electronic information as proof in anything not related to it. If you are charged with hacking, stalking, theft, whatever, it doesn't matter, you cannot be convicted for any such thing simply based on something unrelated such as the hiding of data, because many times a proof needs to be "beyond reasonable doubt". Also even if police did use it as reason to pick you up and arrest you, they could not hold you for longer than a few hours unless it was for interrogation, but an official from the public ministry (a prosecutor) must give them permission for it. This is also a maximum of I believe 3 days -- not that it is pleasant being there. In practice it is never longer than a single night, but that depends on the case, and clearly "encryption" is no reason to keep you longer by itself. "Encryption" cannot even (in this country) be a reason to keep you for longer than those few hours. This is because the reason for keeping you is to keep you at the disposal of police, or, to prevent you from interfering with an investigation.

Moreover, the police that arrest you do not inspect your stuff, they send it off to the detectives apartment. "Your stuff was encrypted" is no reason to arrest you again. They will seek other ways to get at you, but cannot ever arrest you based solely on that. So what you are saying implies police having been witness to electronic communication, and arresting you based on that.

However, you make some kind of blanket statement that in essence only applies to "countries that enforce censorship" whatever that may be. Many countries enforce censorship, our western countries do as well. I have said that I live in a European country and you know full well that most of the web uses encryption constantly. Your statement, therefore, seems to be rather irrelevant to begin with, and more a way of saying something smart, than something that actually applies.

Now I will not say that if police were aware of such reasonings, they would not use that to hurt you on purpose. They probably have more means than I am aware of here, but this implies an ongoing relationship with them here, in which case you are already a "known person" to them. So just from the hypothetical position that you live in a country where all encryption is outlawed: from SSL/TLS to SSH to whatever Whatsapp uses these days.

It is obvious that China is not going to be this country. I doubt Iran is going to be this country. Maybe North Korea could be this country, but in that case you have different problems.

Not even Egypt, or anything like it, is really going to be this country. Sure China may block a lot of foreign websites, but they cannot in honesty block all SSL. So your theoretical country may not even exist on the planet earth. I don't say I know everything, I just say that it seems rather impractical for anyone these days.

So theoretically, someone using encrypted communication may very well set himself apart in a strong way. However if you keep a clear view, stand tall, and don't bargain, they may still not have anything against you. They still only have one bit of information. Even if they roughed you up and searched all your stuff. They might still only have 1 bit of information. And in that case, you have different problems. In that case, you live in a country that has not any sense of democracy. You probably get terrorized by police for other things as well (such as wearing condoms, or having them on you). Electronic communication is really a step beyond that and you have other challenges to meet in the meantime. So the point is really moot to begin with. It is like superimposing atomic bomb concerns on countries that have not even yet developed guns.

Not saying it could never be an issue. Just saying you'd have more things to worry about. Encryption may very well be the least of your concerns (or at least further down the line) and even without encryption, they could still hurt you. And even in that situation, hiding an encrypted USB stick might not hurt you all that much. Not really.
If you can afford a very expensive lawyer, it is completely a different story.
Or you study a bit of law yourself, I don't know. I will testify and vouch though that the inexpensive lawyers get in the way more than that they help.

Re: hidden full system encryption on gnulinux?

Posted: 2016-05-20 10:41
by edbarx
dryden wrote:Then I will respond by saying that you are rather uneducated, and it was none other than Theodore Roosevelt
Insults?! :shock: :?

That is enough as proof to disregard your argument.

Re: hidden full system encryption on gnulinux?

Posted: 2016-05-20 12:33
by dryden
I'm sorry, but you do not really espouse any sense of what in Dutch we call "ontwikkeling" (Asian term, I guess, would be "cultivation") if you start saying things that in common culture have already been dealt with, or at least, recognised, or at least, understood by some. If you make the same argument that has been made centuries ago, and if one common great man in modern human history, at least in the West, has already made unforgettable statements regarding your very issue.

And then you claim that I do not care about freedom (which is also an insult, in a sense) and that you would rather have freedom over the risk of ending up in jail. You basically attribute to me a disregard for freedom.

When the great Theodore Roosevelt has already made that speech aeons ago so to speak. And *many* people know about it and his words are world-renowned.

Then don't make me say those things.

Don't act as if you are so wise, and as if you have no regard for, and knowledge of, current history.

Don't paint a picture of yourself as being vastly uneducated, or "underdeveloped" as we would say in Dutch. Another word would be unevolved, but that is also not something any language uses, probably.

You know what I mean: being oblivious to previous achievements in our culture, requiring me to restate them, but also, attacking and insulting me, in a general sense, because I tend to agree with Rooseveld here, or, more likely and more appropriately, and more accurately, because I say the same things he has said.

Achieving anything in the Linux world becomes rather hard when the people that live in it claim to be so highly advanced, and then espouse a disregard, or lack of knowledge, or lack of awareness, of important achievements in our culture.

In general I feel Linux people consider themselves to be more advanced than others (because of the FLOSS principles) and will attack you if you say anything that goes in opposition of it, while the principles themselves, that they believe in, may go in direct opposition of previous achievements, that have founded our society. So basics tenets of democracy, no matter how sullen, are being thrown away, and the wheel supposedly reinvented.

And then someone who claims, apparently, to know a lot about safety, security, and fighting for freedom (?) then attacks someone who actually does so.

The very thing Roosevelt uttered back then, I utter here. Also based on experience, I might add. Why do we have a need to redo what has already been done in the past? Do we need to be unaware of everything, not learn from history, and try to do all those things, try to achieve all those things, try to reach that level that has already long since been reached?

I know current culture is succumbing and degenerating, and in many assets and aspects, in many facets, is going down the drain, and that many people are unaware of such things, and many people even want to do away with, on occasion, and repeatedly, common achievements (we call them "verworvenheden" in Dutch -- things we have acquired or obtained or attained) such as that everyone is equal under the law, or that prisoners have a right of fair treatment, etc. etc.

I know that many people espouse brutality. Many people disagree with a system of law that protects everyone.

But if you say that you would rather have "freedom" (of being in a jail cell for 2 days) and that you would rather give up any right of encryption (which is basically what your stance comes down to) then I would consider you a weakling but also someone unaware of these issues at heart.

Yet you try to convince me that I have it wrong and that I am saying stupid and uneducated things.

Then don't make me say these things.

Don't make me object to such rudimentariness.

Don't make me object to such a scared way of living life. To think that, even in our current societies, governments are tyrants and can get away with anything. And that your only defense is a really expensive (or good) lawyer, but you won't do it for yourself, and the way I hear you speak, you do not have access to that attorney or lawyer.

And in a certain sense you are trying to dissuade me (or others) from using encryption in the first place, or using hidden encryption, or using stacked encryption, or using any whatever scheme we may have to be safe. Because apparently you do not believe you have any power.

Do not make me object to any statement that we are powerless, please.

Re: hidden full system encryption on gnulinux?

Posted: 2016-05-20 12:39
by dryden
Another way of phrasing this is:

The people who say it cannot be done, should not prevent the people who say it can be done, from doing it.

Re: hidden full system encryption on gnulinux?

Posted: 2016-05-20 13:03
by edbarx
Value laden subjects are always open to discussion no matter for how long and by whom they have been debated. This twisted view that certain subjects are not to be discussed as they are generally accepted is similar to religious and political dogma.

Re: hidden full system encryption on gnulinux?

Posted: 2016-05-20 13:41
by dryden
In this case you are discussing as a way of dissuading someone, which is not nice to begin with.

Also, that takes away from the fact that certain positions have definitely been recognised in common culture. I know people do this more often. For instance.

Some people will hold that software quality is completely subjective, irrespective of what people want, or say they want, from the software.

While in principle quality is a subjective phenomenon, this depends on the requirements and requests that the user makes of the software.

Given those requirements, it becomes an objective assessment. Of course, still depending on a group of users and their needs.

But some people defend creating lousy software on the basis that no one ever could say anything meaningful about software quality.

Which they then use as an argument, that creating better software is in the eye of the beholder, and subsequently they even argue that good or perfect software is even an impossibility because "all software has bugs".

So these people defend bug-ridden software by saying that good software is not possible anyway, because some random different person might say that this good software is actually bad software.

In a sense, they are avoiding having to form an opinion themselves based on the excuse that their opinion is going to be subjective anyway.

Meanwhile they continue creating bad software.

And attacking attempts to improve it.

Do we see anything different here? I don't think we do. Saying that there can be no consensus on anything (which is basically what you are saying or attesting to here) is void. A certain group can certainly agree on some things. You are hiding your underdevelopment behind a façade of superiority in saying that all opinions are equal, and there is no difference in quality between one such opinion, or mode of living, and another.

We call this nihilism. And sorry I come across as so arrogant, which was never my intent, but you believe that.

Some people call it cultural relativism, which is also in that sense deeply nihilistic.

One of the tenets of this thought system is "We can never know the truth" or "We can never find a way of living that really objectively, works". "We can never develop a morality that we can really be confident in is going to lead us to the good life". "Human life is doomed to fail, because we have not the ability to discern functional ethics from nonfunctional ones" even though they then go on to defend a mode of living that is deeply dysfunctional.

Basically, this thought system says that knowledge about human life is an impossibility.

That life will always be hell, poverty and war will never be solved, and you must consider yourself lucky if you have anything worth of value. But what if you *could* understand human life in a way that would directively show you the way of living a better life? That would clearly indicate "works" from "doesn't work"? That would distinguish "reaches our goals" versus "doesn't reach our goals?"

And what if the same would apply to software development? :P.

I'm not saying you are considerably or considered to be underdeveloped on your own. I don't think you are. I think you know full well these things. I think some people just deny that they know these things. I think some people just don't believe in it, and then profess that they do not have this knowledge. The believe they cannot have it, and subsequently believe they DO not have it, all the while having it. So I don't think you are underdeveloped at all, and I'm sorry I said so.

But you can convince yourself that you are, and you can convince yourself that certain knowledge is not to be had, and if you are then using that to promote and "prove" a mode of living that clearly doesn't work.....

Simply because you don't believe a real mode of living that DOES work is even possible at all......

That's called cynicism you know. So now you are nihilistic AND cynical ;-).

But this is just a stance you take, and you are allowed to take that stance. So you are not trying to prove that your thing works. You are just trying to prove that my thing won't. That's why I call it "not nice". There is no need for you to tell other people that what they believe in, won't work, that it is a lie. You haven't tried it for yourself, don't take it away from other people.

So the basic tenets are:
- real knowledge is not possible
- we cannot achieve our dreams

And I disagree with that, sorry but I do. Sorry but my leg is hurting, and I need to quit this. Bye.

Re: hidden full system encryption on gnulinux?

Posted: 2016-05-21 11:37
by cpoakes
What was the OP again?

Re: hidden full system encryption on gnulinux?

Posted: 2016-05-21 15:11
by dryden
I cannot say if the following is correct. I read about countries that have legal means or plan to get legal means to make a person tell a password for decryption. Countries that may not use violence to get the password. The windows versions of truecrypt have the ability to create and run a hidden encrypted operating system whose existence may be denied. I am not aware of gnulinux having this feature. It is important that gnulinux gets this encryption option that people in these countries get another means to provide privacy. If it can be made for windows it can be made for gnulinux? Can I get to know, how difficult it is to provide this option? Expensive? Many programmers required? Technically advanced?
Thanks.
hthi

Here, I have done it for you. See how nice I am :p.

Not sure what to add, but I don't think anyone (but me) has tried answering the questions.

Re: hidden full system encryption on gnulinux?

Posted: 2016-05-22 00:15
by dryden
Check this madness:

"The VeraCrypt extension only increases iteration count for the key derivation function (on-disk format is the same as TrueCrypt format)."

That is from cryptsetup version 1.6.7. Debian 8 and Kubuntu (Ubuntu) 16.04 still feature version 1.6.6.

The very thing everyone complains about is that it takes too long to unlock a VeraCrypt volume.

Apparently they have massively increased the iteration count for no purpose really that I can see.

Completely sacrificing usability for a little bit of added security, but probably not by a factor 2, 3 or 4, but probably by a factor 300.

And indeed, it was mentioned that TrueCrypt used 1000 or 2000 iterations, whereas VeraCrypt by default uses about 200.000 to 330.000 for system encryption.

Even my estimate is correct.

No prior knowledge lol. You can go as low as 2048 for system passwords provided your password is longer than 20 characters. But the idea is that they added a number as a form of variable iterations. The number needs to be specified on the (boot) prompt, so now you need 2 values: your password and the number of iterations used to derive the header for it.

It was said that in 2002, an iteration count of 86.000 for English text (words) of 40 characters would cost about $200.000 to crack. That is assuming low entropy because you have English sentences with dictionary words and grammar and no other characters. It was estimated at 56 bits of entropy. A lowercase password + 10 additional characters (36) of length 28 without dictionary advantage or grammar would have ~144 bits if completely random. That's a logarithmic difference of 2^88. In practice without additional information, anything not found in a dictionary would suffice for that. These iteration counts are linear. A factor 300 increases "brute force time" by 300. That seems rather irrelevant and insignificant compared to that 2^88. So it seems that huge factor, or so it seems, is rather completely moot depending on how strong your password is to begin with, which makes a much larger difference. If you mix in more ascii, then non-predictable 95-character passwords of length 28 will be impossible to crack, no matter what iteration count.

Clearly these days an iteration count of 10.000 these days would have been a good thing and would not have significantly lengthened boot times. That default of ~300.000 is thus complete nonsense.
This is the default if you don't use a PIM (that second number). If you do use a PIM, and supposing it were in the range of 1-300, that would significantly increase the cost, but anything above 150 would give the same long boot times. So more likely people would choose something between 10 and 30. Supposing then 20 different PIM values and an average of 20, you would get an average of 20 x 2048 = 40.960 iterations times 20 values is worst case 819.200 iterations per password to crack. (Hash). Average case ~400.000 iterations because you use a PIM, whereas unlocking with the right PIM takes ~40.000, provided, of course, the attacker makes this right guess.

Personally typically I would not even want to use a PIM, which voids my ability to set the iteration count. This software does not allow you to set an iteration count unless you use a PIM, that you will have to enter at every boot.

Hence, an unusable system for most people in most cases. That extreme iteration count is dwarfed by the effects of even adding 3 random non-alphanumeric characters at random places, provided the attacker knows how many there are (62^3 / 26^3 * 28C3 ≃ 44.000 more attempts required). Making it look completely silly to use the iteration count as the main security measure.

With the right guesswork and expanding from that, perhaps different. Still improving your password in any way is going to significantly improve its strength way beyond that factor 300.

But now everyone not using a PIM, suffers for that. And everyone that does use a PIM, has to pick a low value or suffer regardless, and the PIM itself then only provides a factor 10, although you'd have a factor 20 to begin with (average 40.000 its) which comes down to a factor 200 for using that PIM + the higher iteration count. My calculations are off, a higher PIM also increases iteration count, so the average is not correct and will become higher than a plain "mid average" I think. But that also means anyone cracking it will start at a low PIM (basically 1) and go up, because low values are cheaper. Basically forcing you to pick a higher PIM again.

You could probably work out what values people are most likely to use. You'd start out with a value that still gave a reasonable user experience, as the upper bound, something that doesn't annoy. Increase that upper bound slightly, and then work your way down. Start out with a lower bound that is barely noticeable. Likely that your PIM is going to be in that range if people are experienced. More likely they won't be using a PIM, and you just have a constant factor 300, so to speak.

A system is only as good as the willingness of people to use it.

So good going VeryCrypt, but my assumptions turn out to be just about correct. This seems to be practically the only thing they have added, or changed, and it is worthless in that sense. You took a good product and made it worse. Because you thought you were so smart.

Re: hidden full system encryption on gnulinux?

Posted: 2016-05-22 22:51
by tomazzi
dryden wrote:So good going VeryCrypt, but my assumptions turn out to be just about correct. This seems to be practically the only thing they have added, or changed, and it is worthless in that sense. You took a good product and made it worse. Because you thought you were so smart.
Actually, I would like to hear technical terms instead of bullshits: what exactly is wrong with VeraCrypt? - list the details, if You can...
(maybe You're unaware of the fact, but I've actually tested that code under Linux - so please... - facts only - bullshits will not work here - and I'll just report them as a spam)

...
edit: perhaps this will be helpful:
Header Key Derivation, Salt, and Iteration Count

edit2:
Since it's rather unlikely to see the correct answer from that spammer, here is the explanation for everyone who's interested:
TrueCrypt_Security_Assessment.pdf

Section 3.3 "Detailed Vulnerability List":
FINDING ID: iSEC-OCAP-11
TARGETS: Encrypted Volume Header
DESCRIPTION:
The key used to encrypt the TrueCrypt Volume Header is derived using PBKDF2, a standard key derivation algorithm [5]. Developers are responsible for specifying an iteration count that influences the computational cost of deriving a key from a password. The iteration count used by TrueCrypt is either 1000 or 2000, depending on the hash function and use case.

In both cases, this iteration count is too small to prevent password guessing attacks for even
moderately complex passwords. The paper that introduces scrypt[6], an alternate key derivation function, demonstrates the challenge of using PBKDF2 even with a very high iteration count – brute-forcing key derivation is easily parallelized and becomes more efficient each year with advances in CPU performance. The use of a small iteration count in TrueCrypt permits efficient brute-force attacks against its header key.
edit3: ... and today even cheap gfx cards have at least 100 cores, 500 is nothing unusual - a lot of computing power, which can be used to reap the passwords in days, not years.

Regards.

Re: hidden full system encryption on gnulinux?

Posted: 2016-05-25 00:03
by dryden
tomazzi wrote:Actually, I would like to hear technical terms instead of bullshits: what exactly is wrong with VeraCrypt? - list the details, if You can...
(maybe You're unaware of the fact, but I've actually tested that code under Linux - so please... - facts only - bullshits will not work here - and I'll just report them as a spam)
I don't know why you are lying. I guess that is just the kind of thing a person like you does.

The first document you link I have already read, of course. It clearly specifies that the algorithm hasn't changed from TrueCrypt, and still uses PBKDF2. That means it uses the same algorithm with a ~300 times higher iteration count. The original count is as you specify, 1000 (with SHA256) or 2000 (with RIPEMD-160). The VeryCrypt default is now 200.000 (for SHA256) or 327.661 (for RIMEMD-16) which indicates the factor of about "300" that I mentioned; actually it is a factor 200 vs. 160; I had not read yet which truecrypt thing did what, sorry. However the numbers I mentioned were more or less exactly those. So apart from 300 having to be 200, please show me more of that bullshit I have written, that you can testify so well with your linked documents that you have aparently not read very well, of you would have recognised the figures mentioned there.

Maybe it is time you read your own documents instead of only "linking them against others".

Also just from the mere fact that you have tested it, doesn't mean you would not be lying. So please come up with data if you have so much to say.

"I have tested it under Linux" means nothing. The test might very well have revealed its utter insanity (if I am to believe others) but you choose to deny it, hide it, or not relate it. Only if you give me actual data, does it mean anything. Yes, that very same data you say I should provide, but which I have already provided.
This one yes. How hard for you not to imagine that I could not have ventured across it already, when it is the most easy to find document out there.
Since it's rather unlikely to see the correct answer from that spammer, here is the explanation for everyone who's interested:
TrueCrypt_Security_Assessment.pdf
Obviously that formed the basis of the changed system. I never said there was not any need for a higher iteration count, however I did say that even an iteration count of x300 will only make it 300x harder. I also said that any different kind of password strength improvement, would easily top that 300. IF it is not going to get defeated by some guessing strategy or a collection of terms (for instance from someone's harddrive). In a general sense prior knowledge of terms (that you can combine) is the highest threat it seems; which is why full-disk encryption is so important really. The more an attacker knows about you, the much easier it gets. Without full disk encryption you require constant vigilence and sfills.
Section 3.3 "Detailed Vulnerability List":
FINDING ID: iSEC-OCAP-11
TARGETS: Encrypted Volume Header
DESCRIPTION:
The key used to encrypt the TrueCrypt Volume Header is derived using PBKDF2, a standard key derivation algorithm [5]. Developers are responsible for specifying an iteration count that influences the computational cost of deriving a key from a password. The iteration count used by TrueCrypt is either 1000 or 2000, depending on the hash function and use case.

In both cases, this iteration count is too small to prevent password guessing attacks for even
moderately complex passwords. The paper that introduces scrypt[6], an alternate key derivation function, demonstrates the challenge of using PBKDF2 even with a very high iteration count – brute-forcing key derivation is easily parallelized and becomes more efficient each year with advances in CPU performance. The use of a small iteration count in TrueCrypt permits efficient brute-force attacks against its header key.
What makes you think VeraCrypt is any safer? You think a factor of 200 is going to matter much? Do you even think, or calculate? Or just read the words of others without further interpretation?

Sure, one day or 200 days makes a lot of difference. But in the end, if you are in range of 200 days, you are severely at risk anyway. Even very affordable dedicated hashing machines have a power that dwarfs even the best GPU.

This is just extremely cheap:
https://www.bitmaintech.com/productDeta ... Q3Yr280661

For a mere 450 USD you have something that can do 4.7 TERA hashes per second of "double SHA256" that is used for BitCoin, whatever it means (the double part).

Those are the same hashes used for TrueCrypt (and VeraCrypt) I'm sure. That means that with an iteration count of 200.000, this machine can check at least 23.5 million passwords per second.

I am saying exactly what you are saying, but you seem to believe this 200x factor will you do any (or much) good. For TrueCrypt, that'd be 4.7 billion passwords per second. Of course, big difference.

But it is clear that such a path is not tenable in the long run, or even now. This 200x factor comes, reportedly, at a very high cost to the user experience and enjoyment, to the usability of the entire thing. However I was not vying against an increase in iteration count. I was saying that a number of about 40.000 (factor 40) would be much saner. That would still give 117.5 million passwords per second, but now the difference is only a factor of 5; instead of 5 hours it now takes 1 hour.

That is not going to save your ass okay. If you are in range of 5 hours, you are already screwed. If you are in range of 5 years, you are already screwed. This is what they call "morrelen aan de marge" in Dutch. It means making small improvements and then pretending that they are the holy grail, when they in fact do not amount to much, and in the end do not solve the problem at all.

It is clear, that when professional hardware continues to improve, the problem cannot be solved by increasing that factor even more, whereas actual consumer systems cannot even process it. That is of course why they introduced the PIM. A second password multiplies with the original one, and greatly increases the length required, in principle, even if it is only by a factor 20 maybe.

No people, what you really need is something else. You need security around your passwords to begin with; not using terms that other people can find. Not using combinations that can be guessed with easy modifications. I can tell you that in my case some individuals with the power of the state behind them, came back to me begging for the passwords (that they didn't really need, but that aside) because after 6 months they still had not cracked anything.

That was TrueCrypt and that is those "days" for you. So tell me about your experience then.

Please, do. I'd love to hear, but I doubt there'd be any.

Oh and on one of the OpenSUSE lists there is a forensic examiner. He tells us about the techniques he uses, so I am not entirely without information here, in case you wonder.

So much for the bullshit then? Why don't you start doing what you ask of others? Why don't you start providing data, and experiences, of your own?

Like I said, was that you? The evil is in you.

And just in case you wonder, the reason why you at this time appear to be so holy about VeraCrypt is that it is open source, not because of its actual quality.

If it was not open source, you would never staunchly defend it like that. And this tells the lie, over your arguments and their merit.

You think I was saying TrueCrypt is safe. What I was actually saying is that VeraCrypt is not safe, and not actually much safer than TrueCrypt, and that its usability issues cause actual users to default to less-than-ideal strategies, obviating the solutions and the requirements and the advancements that the VeraCrypt designers intended. Oh, and most of the jargon in the manual for VeryCrypt is just the original TrueCrypt text, with the word "TrueCrypt" replaced by "VeraCrypt" because they do not actually perform any kind of acquisition or whatever that term is. Taking something from someone else and claiming it is your own.

In a general sense also a form of theft to begin with.

Making your software less user friendly to ensure that people use it in a better way, is no solution.

You work against people instead of with them, and hence the solution you arrive at, or the end result of your actions, will be negative. For me it is no surprise these open source developers do something that I would consider maybe 10% of the quality of what the TrueCrypt authors would have done. Of course TrueCrypt may not have changed the iteration count because of backwards compatibility, I don't know. So there is reason for a new version, yes, but many users apparently claim that the new boot times are just unacceptable.

I could test it, but I would need to encrypt a live system with it (FX 6300) and I'm not too happy about exposing my system to such risks.

Here is some more bullshit for you:

https://news.ycombinator.com/item?id=7586644

There are some pretty smart people there. I have now read the paper on scrypt. I do not believe it is uncrackable; there are flaws in the reasoning I think, without being able to tell why. It is designed to exponentially increase the cost of parallel computation by increasing memory cost and introducing an algorithm that cannot actually be performed on parallel circuits. The "HMAC" family of iteration algorithms seems already to be explicitly designed to increase the (memory) cost of computation such that parallel circuits have a difficulty in obtaining advantages as compared to a regular general purpose system. Both TrueCrypt and VeraCrypt uses the same HMAC hashes, which may mean that my estimates in the number of passwords that you can crack per seconds, were much too high. Nevertheless neither TrueCrypt or VeraCrypt use scrypt, even if it is what they say it is. That means that, in actual fact, we are still looking at a factor 200 difference, and nothing else here.

I was for a moment scared that VeraCrypt had actually implemented scrypt, at which point all my allusions would have proven false :p.
But this is not the case.

They still use the same algorithms as TrueCrypt, only a factor 200 more, an apart from the PIM that you can also use *that is the only difference*.

Important to note from the scrypt paper:
Using these values, we estimate the cost of computing 9 key derivation functions: the original CRYPT; the MD5 hash (which, although not designed for use as a key derivation function, is nonetheless used as such by many applications); Kamp’s MD5-based hash; PBKDF2-HMAC-SHA256 with an iteration count of 86,000; PBKDF2-HMAC-SHA256 with an iteration count of 4,300,000; bcrypt with cost = 11; bcrypt with cost = 16; scrypt with (N, r, p) = (2^14,8,1); and scrypt with (N, r, p) = (2^20,8,1). For the parameterized KDFs the parameters are chosen such that the running time on one core of a 2.5 GHz Intel Core 2 Duo processor 18 is less than 100 ms (for the lower parameters) or less than 5 s (for the higher parameter s); we chose these values since 100 ms is a reasonable upper bound on the delay which should be cryptographically imposed on interactive logins, while 5 s is a reasonable amount of time to be spent encrypting or decrypting a sensitive file.
I don't know how they can say that an iteration count of 86.000 for PBKDF2-HMAC-SHA256 will cause a less than 100ms delay, and one of 4.3M will cause a 5s delay.

If that were true, and we were still talking about the same thing, then VeraCrypt could never cause more than a 230ms boot time delay for such a system. But this is not the case.
Too slow. Both in creating a container as well as mounting. On my machine it takes 30 seconds just to tell me I chose the wrong hash or entered the wrong password. Not Good.
I mean. This was a post from 2015. March 2015. Just more than a year ago. If you can create a software that takes 30 seconds for each failed password attempt, you are a turd faced motherfucker idiot moron for creating usable systems. I can give you as many links as you wish, here are just a few:

http://www.wilderssecurity.com/threads/ ... pt.374694/
https://sourceforge.net/p/veracrypt/dis ... /e75045a8/
TrueCrypt use of really small iterations count made it very quick to mount volume, which is not good from the security point of view. Compared to that, VeraCrypt will always be slower but this affects only mounting and not read/write operations.
Translation: our software is now unusable but we don't care about that, we only want to brag about security bragging rights. We don't actually care about you, or what you want, or what you say you want, but WE provide the more secure system, so put that in your bags people, we are the more secure ones. TrueCrypt sucks, and we rule!

That's about the literal translation of their level of disinterest in actual user (or usability) problems.

If I told you the number of times I sometimes type my (long) passwords wrong.... It would mean I would have to start typing as slowly as 1 character per second to avoid mistakes just to avoid this penalty.

That is probably going to mean at least one 30 second delay on average, EXTRA due to a failed password. This penalty is not acceptible. If they were a real software vendor they'd go bankrupt. Much of the Linux world would. You can't sell that stuff. It's too abysmal and only concerns itself about the wishes of the authors, never the users. In rare cases the conditions warrant users being more important than developers, but not often.

Another one from Reddit:

https://www.reddit.com/r/VeraCrypt/comm ... _too_slow/

Impossibly long delays in mounting anything. About the equivalent of mounting eCryptFS on my hardware appliance networking storage consumer device with very slow CPU.

Technology is not the solution, not like that. If you want to be safe, you first have to ensure usable systems, and then people choosing strong passwords or good strategies, but that is their own choice, and not something you should enforce. (You are not responsible for their lives in that sense, and have no say in what they do -- or SHOULD have no say in what another person does or doesn't do, even if it is with your software).

Re: hidden full system encryption on gnulinux?

Posted: 2016-05-25 07:47
by tomazzi
dryden wrote:So good going VeryCrypt, but my assumptions turn out to be just about correct. This seems to be practically the only thing they have added, or changed, and it is worthless in that sense. You took a good product and made it worse. Because you thought you were so smart.
Your blatant tirades are just a waste of server resources, since You have completely no idea of what You're talking about.

What the VeraCrypt team did, is that they took old, insecure TrueCrypt and fixed *most of its confirmed vulnerabilities*

Iteration Count:
Master key derivation is the most important part of the whole encryption concept.
Today, it's trivially easy to generate millions of passwords per core per second -> the only problem is to generate master keys and verify if one of them is correct - this is the essence of so called "off-line" brute force attack.

So, by increasing the iteration count to a very high level, the VeraCrypt makes that kind of attack impractical, because the high delay needed to derivate master key from a generated password kills the performance.

Of course, this has side effects.

There are alternative solutions, like the one proposed in the aforementioned scrypt, which is based on adding another hashing level, but this solution is only theoretically tested.

Edit:
My first devilish plan was to wait for another few pages filled with Your "funny" posts, but, let's finish this.
If You would actually *read* the documentation instead of spreading bullshits, then You would quickly discover, that it's not about 300, it's around 300^4. That's because the attacker doesn't know the PRF setting for the header, so he must try all the PRF variants.

The difference in delay with the default VeraCrypt settings, compared to Your "sufficient" 10000 setting, is: 1.9×10²², and 2.1×10²² when compared to original TrueCrypt settings.

VeraCrypt team claims that it should be sufficient for the next 10 years - we'll see ;)

Re: hidden full system encryption on gnulinux?

Posted: 2016-06-18 13:03
by hthi
A person posts a useless post. I tell him to stay out. Then several offensive posts emerge.

I may have misread how truecrypt technically provides a hidden encrypted system enabling plausible deniability. What should be clear, my question is about, can gnulinux provide a solution comparable to the windows truecrypt solution?

I have tested hidden system on windows 7. When you start the computer, the familiar password input screen displays. Anyone who knows truecrypt will know that they are dealing with encryption. If a law says, you must hand over the password, truecrypt provides the option to hand over a password that will open a decoy system. My truecrypt guide reading is, that an adversary cannot prove, that another system is present. If the decoy system's content is nothing but irrelevant data, it does not prove that another system is present. Should you deny to hand over any password that starts a system, the law may authorize fines or prison.

I do not know if any country has a law that forces you to hand over passwords. I have read uk either has such law or is planning it. Next step would be to forbid encryption. I have read about no country planning such law.

People knowledgeable about encryption say it must be tested and verified by many. Else do not use it. No one here has provided links to any official step by step guide on how to get a hidden gnulinux system. Referring to generic software is reckless. You do not know my skills and to suggesting I should find out for myself is unacceptable about encryption.

I was not clear enough in my first post on what solution I think gnulinux should provide. I think a hidden system should be an option during installation. That minimizes errors the user can do.

Garry, claiming my post was inflammatory is wrong. The first poster made a stupid post and I told him. Pointing out if you think windows does something better and you think gnulinux should get it too, is legitimate. Telling people to reject gnulinux is not a favor to free software.

Dryden, thank you for your answer. I cannot say, I understood it all. I agree, that using external memory devices is an option. I still think that a truecrypt like option should be put into gnulinux. Can you tell how big a task it would be? Manpower? Level of difficulty?
Do you know who started writing truecrypt? https://mastermind.atavist.com/
Do you know gnulinux tcplay? I have tried to make a container and full device encryption. I am not able to. If you want to, can you write me instructions? That is if you believe tcplay is valid software.
If edbarx is an oppressed person located in a country known to strike on their citizens and you are not, then I do not think you can relate.

Re: hidden full system encryption on gnulinux?

Posted: 2016-06-18 14:49
by dryden
tomazzi wrote:Your blatant tirades are just a waste of server resources, since You have completely no idea of what You're talking about.
You really don't know much, do you? This was a serious thought of mine.
Master key derivation is the most important part of the whole encryption concept.
Today, it's trivially easy to generate millions of passwords per core per second -> the only problem is to generate master keys and verify if one of them is correct - this is the essence of so called "off-line" brute force attack.
Who are you repeating that wisdom to? Are you also going to explain how a numerical analyzer works? No, just kidding. Are you going to explain how to tie shoe laces as well?

You are repeating the mantra that must form the basis for this whole discussion, and is so trivial to understand that you are insulting your own intelligence, not mine.
So, by increasing the iteration count to a very high level, the VeraCrypt makes that kind of attack impractical, because the high delay needed to derivate master key from a generated password kills the performance.
No kidding, sherlock.
There are alternative solutions, like the one proposed in the aforementioned scrypt, which is based on adding another hashing level, but this solution is only theoretically tested.
It actually greatly complicates computation by making it impossible to "parallellize" the computation of any single key, but okay. Maybe that's the same.
Edit:
My first devilish plan was to wait for another few pages filled with Your "funny" posts, but, let's finish this.
So your original plan was to repeat basic truths that everyone on this forum is basically going to know about, and leave it at that, and then imply that you have said something new?

I mean, who are you insulting here? Yourself or me?
If You would actually *read* the documentation instead of spreading bullshits, then You would quickly discover, that it's not about 300, it's around 300^4. That's because the attacker doesn't know the PRF setting for the header, so he must try all the PRF variants.
So maybe I don't know much. But what are those PRF variants? A PRF is a function that is random given a certain seed. Or that looks random. The attacker does not need to try all seeds. So if there are 4 different PRF families being used, it means that your calculation comes down to 300x4, not 300^4. And even so, the same would be true for TrueCrypt, I don't see anything changed here? What documentation are you talking about? Am I insulting my own intelligence now by even talking to you?
The difference in delay with the default VeraCrypt settings, compared to Your "sufficient" 10000 setting, is: 1.9×10²², and 2.1×10²² when compared to original TrueCrypt settings.
So you are basically saying that they created a program that takes 2.1x10²² longer to boot?

Was that the intent? To increase boot times?

Where do you get that number from? How is it calculated? Still doesn't seem like a very smart thing to do for me, but it does increase the boot length as was indicated to that much larger extent than I could imagine. Still doesn't answer the question whether the choice for that number was a good choice to begin with, which was the whole point of the complaints.

By the way, 2.1 / 1.9 = 10%. You are saying that 10.000 iterations takes 10% longer than the 2.000 iterations of TrueCrypt. Please explain your math to me then, oh bright person.

By the way, this is the complete side by side diff between the TrueCrypt and the VeraCrypt manual, for that section, if trivial changes are neglected or ignored:

Code: Select all

derivation function is based on HMAC-SHA-512,                                      |    derivation function is based on HMAC-SHA-512, HMAC-SHA-256, 
HMAC-RIPEMD-160, or HMAC- Whirlpool (see [8, 9, 20, 22]) –                         |    HMAC-RIPEMD-160, or HMAC-Whirlpool (see [8, 9, 20, 22]) – 
information, refer to [7]. 1000 iterations (or 2000                                |    information, refer to [7]. A large number of iterations of 
iterations when HMAC- RIPEMD-160 is used as the underlying                         |    the key derivation function have to be performed to derive a 
hash function) of the key derivation function have to be                           |    header key, which increases the time necessary to perform an 
performed to derive a header key, which increases the time                         |    exhaustive search for passwords (i.e., brute force attack) 
necessary to perform an exhaustive search for passwords                            |    [7].
(i.e., brute force attack) [7].                                                    |
                                                                                   >    Prior to version 1.12, VeraCrypt always used a fixed number 
                                                                                   >    of iterations depending on the volume type and the 
                                                                                   >    derivation algorithm used:
                                                                                   >
                                                                                   >    For system partition encryption (boot encryption), 200000 
                                                                                   >    iterations are used for the HMAC-SHA-256 derivation 
                                                                                   >    function and 327661 iterations are used for HMAC-RIPEMD-160. 
                                                                                   >    For standard containers and other partitions, 655331 
                                                                                   >    iterations are used for HMAC-RIPEMD-160 and 500000 
                                                                                   >    iterations are used for HMAC-SHA-512, HMAC-SHA-256 and 
                                                                                   >    HMAC-Whirlpool. Starting from version 1.12, the PIM field 
                                                                                   >    (Personal Iterations Multiplier) enables users to have more 
                                                                                   >    control over the number of iterations used by the key 
                                                                                   >    derivation function.
                                                                                   >
                                                                                   >    When a PIM value is not specified or if it is equal to 
                                                                                   >    zero, VeraCrypt uses the default values expressed above.
                                                                                   >
                                                                                   >    When a PIM value is given by the user, the number of 
                                                                                   >    iterations of the key derivation function is calculated as 
                                                                                   >    follows:
                                                                                   >
                                                                                   >    For system partition encryption (boot encryption): 
                                                                                   >    Iterations = PIM x 2048 For standard containers and other 
                                                                                   >    partitions: Iterations = 15000 + (PIM x 1000)
Meaning, they added one hash function (HMAC-SHA-256) and the PIM functionality. Now explain to me how I can derive from this documentation your magic number of 1.9x10²²

Re: hidden full system encryption on gnulinux?

Posted: 2016-06-18 16:33
by dryden
hthi wrote:Dryden, thank you for your answer. I cannot say, I understood it all. I agree, that using external memory devices is an option. I still think that a truecrypt like option should be put into gnulinux. Can you tell how big a task it would be? Manpower? Level of difficulty?
Do you know who started writing truecrypt? https://mastermind.atavist.com/
Do you know gnulinux tcplay? I have tried to make a container and full device encryption. I am not able to. If you want to, can you write me instructions? That is if you believe tcplay is valid software.
If edbarx is an oppressed person located in a country known to strike on their citizens and you are not, then I do not think you can relate.
I don't think edbarx has alluded to any such thing, or even experience in dealing with law enforcement, but I might be mistaken.

Enabling a hidden system for LUKS in its first idea, would not be more difficult than doing that for TrueCrypt, I'm sure. But I do not know. If a header key is indistinguishable from encrypted data, then you can hide it anywhere. Providing a password to unlock a header key, means the system needs to search for a hidden key if the main key doesn't match; I do not know how this works. Handing over your key to the outer system would indicate unlocking of that initial header. If the visible delay in unlocking a hidden "container" gives no indication to the existence of you opening something hidden as opposed to you opening something visible, then nothing can ever prove the existence of the hidden container. Moreover, even if this delay existed, no one would ever notice it unless they were watching you closely while unlocking containers. But it does mean, that if the number of possible locations of a hidden header, based on the size of the filesystem, is limited, finding such a key and trying all possible locations, would be rather fast. It means that the software would by default check those locations for an attempt. This by itself is not suspicious, the system would do it for all failed initial-header-attempts.

Supposing there were 20 possible locations for any hidden header, then on average you would need 10 attempts to find it, but 20 to discover that none exist given the current key (password).

I do not know if TrueCrypt works this way, but I do not think there is anything much wrong with it if it does.

Now to contain a hidden system without a block device you must basically avoid overwriting filesystem metastructure. By default an ext4 filesystem has "block groups" worth 128MB, and of that 128MB some 2MB is reserved for inodes. This means that normally the amount of contiguous unallocated space is only 126MB, or chunks of 126MB spread all over the filesystem.

That means that hiding a filesystem larger than 126MB is not possible unless you too, spread it out. That would require a form of mapping that is probably going to be possible in some way, but using the device mapper. If you can use the device mapper to map sequences of dispersed data blocks (of the outer volume) to the stuff you are going to be presented with (your logical volume) and if you can encode this in a special format new header, that will need to be recognised or activated prior to loading the filesystem, then you could have something that might work very well, although in general you would still need to protect your inner volume while mounting your outer volume, which means that LUKS (in this case) would need to prevent writing to the ranges mapped by your inner volume (if loaded), which means that this functionality needs to be part of LUKS now, and you would need something that not only provides a new format header on disk providing a form of device mapper table, which is easily achieved, using a concatenation of linear targets. Given that you can load this table from your new header, or derive it based on parameters, you can easily calculate the table and map your dispersed "safe space" (from the outer volume) to a new logical view onto those fragments that is in fact contiguous and meant for creating a filesystem upon.

Equally, it is possible to add "zero" ranges to a regular crypt mapping, I'm sure, that would protect data areas against overwriting. This would silently discard the blocks being written.

That seems to require breaking up the regular crypt mapping, I'm not sure. Otherwise you have no control over writes, since LUKS does not really do much of itself, it just sets up dmcrypt. I could probably do it in a month, to have something like this operational.

Given normal, regular, or supposedly perhaps a bit ideal circumstances for my person and my life ;-). And provided I could dedicate most of my time to it, in that sense.

Not very feasible I think, for me, currently. Basically it would be nothing other than an advancement and patch to LUKS.

It requires no additional device mapper targets. It requires obtaining information on the underlying filesystem. Ext4 supports "flex" block groups that slightly complicates it, but not by much. It should be possible to calculate the safe zones easily.

It would require a choice of where to put the hidden volume. I would probably guess or venture that the end of the volume would be best for it. You would then search for the hidden key in fixed positions depending on either block group size, or flex block group size. That means that normally you search the disk in jumps of 128MB. You would position the key simply at the start of the data area. For a 500GB drive and given a maximum hidden volume size of say 80%, you would exhaust the search space in 3000 attempts, but if we assume slightly coarser division of 4x, it means that the key can be found at 512MB intervals and you would require about 750 attempts to find it, given that you do not know the size of the hidden volume. That means you require 750 disk seeks and reads to try them all and discover that none exists ;-). However usually hidden volumes are meant for smaller volumes, and I would guess a typical person would create hidden volumes smaller than 50GB. If you position it at the end, then the search time required to open it becomes dependent on its size, but to exhaust all key locations, you still need to scan the entire disk.

I could easily be done to make the search interval a multiple or division of the size of the volume (outer volume) such that give or take 256 locations would exist per outer volume to search.

If your volume is 500GB or ca. 480.000 real MBs, dividing it by 128MB gives 3725 block groups, which means that you would be able to store a key one in every 14 block groups, or every 1792 MB. You would need to scan every 14th block group and attempt your key, totaling 256 attempts before deciding that nothing is to be found. This seems reasonable.

Once you discover a hidden header, you need to obtain the size of the hidden volume from it, and then create the mapping table based on that. This depends on parameters of the outer volume, that you must utilize at creation time. Given a few of those parameters (not much, just regular ext2/3/4 parameters) you can craft the "jump-mapping" table and then load the regular LUKS/dmcrypt mapping from that. At that point you have a functioning system. Note that this is not encryption within encryption. But since encryption produces "random" data, you won't be able to discern different blocks encrypted using different keys.

I think for me, it would require about 2000 man hours to get it functional to the point that you can start creating packages out of it and passing it to mainstream distributors. But that is about 10 months, normally. Let's say 250 days. To get it functional where a person can use it, not be surprised by failure, but without additional safety precautions, and without support for initramfs and additional "boot" procedures, and without additional GUIs, and with limited support for various alternative ext configurations (probably) and without support for other filesystems, including ntfs (so only ext?) it would probably take a month if I don't end up in jail in the meantime ;-).

What you are looking for (hthi) is a hidden operating system. This is just a part of it. This would just be one hidden container within one outer volume. But typically that would mean that you could hide something in your root filesystem, that used the *same* kernel and initrd, but loaded a *different* root filesystem together with a different /var, and potentially a different /home. Whether that different "OS" is going to access the same other volumes or not, is up to the user. It doesn't require a great deal of work to get this working; because you only need LUKS to map a different thing for you.

So for creating something that works, and that is functional, possibly without hidden volume protection, I would say about 240-400 hours.

Maybe faster but I wouldn't count on it, not for me. I hope that answers your question ;-).

To get it to the point where installers can use it requires much cooperation, but that is outside the scope of what a single person can do.

Re: hidden full system encryption on gnulinux?

Posted: 2016-06-24 21:12
by tomazzi
dryden wrote:So if there are 4 different PRF families being used, it means that your calculation comes down to 300x4, not 300^4
Oh, so it's not just 1x300 anymore?
What a pity - You have wasted the time writing Your previous rants about "how the VeraCrypt team took a good product and made it worse"...

Keep trying ...

...And taking into account that your previous attack was targeting the GPL, I'm starting to think that You're a paid troll, not just a troll.