Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

hidden full system encryption on gnulinux?

Here you can discuss every aspect of Debian. Note: not for support requests!
Message
Author
dryden
Posts: 80
Joined: 2015-02-04 08:54

Re: hidden full system encryption on gnulinux?

#21 Post 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.

User avatar
cpoakes
Posts: 99
Joined: 2015-03-29 04:54

Re: hidden full system encryption on gnulinux?

#22 Post by cpoakes »

What was the OP again?

dryden
Posts: 80
Joined: 2015-02-04 08:54

Re: hidden full system encryption on gnulinux?

#23 Post 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.

dryden
Posts: 80
Joined: 2015-02-04 08:54

Re: hidden full system encryption on gnulinux?

#24 Post 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.

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: hidden full system encryption on gnulinux?

#25 Post 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.
Odi profanum vulgus

dryden
Posts: 80
Joined: 2015-02-04 08:54

Re: hidden full system encryption on gnulinux?

#26 Post 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).

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: hidden full system encryption on gnulinux?

#27 Post 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 ;)
Odi profanum vulgus

hthi
Posts: 213
Joined: 2015-05-09 15:43
Has thanked: 1 time

Re: hidden full system encryption on gnulinux?

#28 Post 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.

dryden
Posts: 80
Joined: 2015-02-04 08:54

Re: hidden full system encryption on gnulinux?

#29 Post 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²²

dryden
Posts: 80
Joined: 2015-02-04 08:54

Re: hidden full system encryption on gnulinux?

#30 Post 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.

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: hidden full system encryption on gnulinux?

#31 Post 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.
Odi profanum vulgus

Post Reply