Tails

#2 Updated by op_mb 2019-09-08 16:36:28

// if (veracrypt_outer_password() false) { if(veracrypt_inner_password() false) return tails :: error; else return tails :: success; }else return tails :: success; //

#3 Updated by op_mb 2019-09-08 16:37:21

code didnt format, i give up,lol

#4 Updated by op_mb 2019-09-08 16:38:10

@segfault hey, cool-cool, will do :)

#5 Updated by op_mb 2019-09-08 16:39:45

oh crap, i mustve accidently clicked assign, was a mistake, this is kust for discussion, i cant unedit it, lol

#6 Updated by segfault 2019-09-08 17:04:05

op_mb wrote:
> hey all,
>
> i read through some vera docs, about plausible deniability,
> seems to me that giving an option for a hidden volume tick in tails goes against plausible deniability principle -

I don’t see why having an option to unlock the hidden volume instead of the outer volume would be a problem for plausible deniability - except if you’re being watched while unlocking the volume, but then whoever watches you would probably also see you do something with the hidden volume’s content, which would be different from the outer volume’s content.

> if condition exists where you have to revieal the password for the outer volume, you get a pop up asking you to tick the hidden volume. this goes agains the veracrypt specification:
>
> “… VeraCrypt first attempts to decrypt the standard volume header using the entered password. If it fails, it loads the area of the volume where a hidden volume header can be stored (i.e. bytes 65536–131071 …”

Yeah, that’s from the VeraCrypt documentation. But cryptsetup, which we use to unlock VeraCrypt volumes, behaves differently. You have to tell cryptsetup which header to use, it doesn’t automatically try the hidden header if the outer one can’t be unlocked (which I see as a feature, it’s the reason why you only have to wait half the time in Tails when you mistype your password, compared to VeraCrypt application).

> so ticking the hidden volume dialog, when providing the password, is not only redundunt (as per specification), but can also be dangerous in that case.

Why would it be dangerous?

#7 Updated by op_mb 2019-09-11 07:56:23

dangerous not in the sense of data analisys, but in the sense of, eg:

you get your machine visually examined, on demand or voluntarily,
examiner doesnt know much about encryption, when you put in the password, examiner sees the ‘hidden volume’,
straight away, question is - whats that, whats a hidden volume, how do i know you dont have one?

how do you prove you do/dont have one? it raises questions when it shouldnt.

its dangerous, because it raises the question of ‘something might be hidden’ to the visual examiner, not
to some cybertech person, who knows, it cant be proven whether it exists or not,
but try to explain it to somone who doesnt know, just puts you into a harder position when it shouldnt

#8 Updated by op_mb 2019-09-11 08:04:29

You have to tell cryptsetup which header to use, it doesn't automatically try the hidden header if the outer one can't be unlocked

i understand what you mean,
would it be easy to implement a switch that just calls cryptsetup with the if/else condition?

// pseudo

if (cryptsetup_outer_password() false)
{
 if(cryptsetup_inner_password() false)
      return tails :: error;
 else
      return tails :: success;
}else return tails :: success;

#9 Updated by op_mb 2019-09-11 08:17:49

s.:
also,

i understand that total run time is important.

p.s:

script that will switch cryptsetup

#10 Updated by op_mb 2019-09-11 11:21:17

p.p.s.:

or maybe if you execute cryptsetup_outer volume and cryptsetup_hidden volume in parallel?

#13 Updated by intrigeri 2019-09-13 08:28:16

> OK, I understand that threat model, but I’m not sure how realistic it is. And I’m unsure about the trade-off regarding usability - unlocking a single VeraCrypt header takes up to 15s on my system (it takes that long when I enter an incorrect password and all the possible encryption and hash algorithms are tried), so if we automatically try to unlock the hidden volume afterwards, it will always take at least 15s to unlock a hidden volume, and take 30s if an incorrect password is entered.

> Also, implementing this change and upstreaming this in both unlock dialogs which allow unlocking VeraCrypt volumes will be quite some effort. That’s why I set the priority to low.

FWIW: I fully agree with this assessment. Thank you @segfault!