[dm-crypt] Luks, use the double force! :)

[dm-crypt] Luks, use the double force! :)

[JAC]

<EN>
Good morning everyone!

Thanks in advance to all the people who support and make possible the strong and free encryption in our favorite operating systems!

I have been using Luks for some time to encrypt some of my partitions, and I am delighted!

But over time I have read in various media, that if you get caught with an encrypted partition on one of your devices (with Luks headers in clear or such), you can end up in prison if you refuse to reveal your password, or you can get a beating if they try to steal your information or your data.

The thing is that to avoid any of these situations, it has occurred to me that you could surely implement these two options in Luks:

1. To have a password with which to decrypt the support correctly (the usual one, the real one).
2. To have a second password with which to decrypt the support in a covert way (the forced one).

Option 1 is already implemented, with its corresponding keys and so on, and it works perfectly (it is the usual one).
But option 2 does not exist (or at least I don't know it).

I will explain my idea with a little more detail:

If in some occasion the user would be forced to reveal his password, he will use the password of option 2.

Once the option 2 password is entered, the system will decrypt correctly but "covertly".
The partition will be presented containing a series of files and/or directories that the user has previously wanted to incorporate and present to whoever has tried to force him to reveal his data. 

By having this option (option 2), the user could incorporate photos, videos, pdfs, etc. of his life, with which to cover the mouth of the forcer, and he would be forced to abandon the use of force.

Sorry if you do not understand me well what I say, I speak English quite bad.


I suppose that I am not the first person who thinks about this solution, but I leave it there, in case it is possible to implement this second option (or password).

With this functionality, we would give a real Hand strike in terms of the privacy of our things. That they are ours and that nobody or anything has why to investigate or inquire in them!

Thank you all again.

And sorry for my English, I speak it very badly.


Greetings from Spain!

Jac's


P.D: By the way, I am not subscribed to the list. I don't want to interfere with the developers' work. 
</EN>





<ES>
Buenos dias a tod@s!

Gracias de antemano a todas las personas que dais soporte y haceis posible el cifrado fuerte y libre en nuestros sistemas operativos preferidos!

Hace tiempo que utilizo Luks para cifrar alguna que otra de mis particiones, y estoy encantado!

Pero a lo largo del tiempo he leido en diversos medios, que si te trincan con una particion cifrada en alguno de tus dispositivos (con las cabeceras de Luks en claro o tal), puedes acabar en prision si te niegas a desvelar tu contraseña, o te pueden dar una paliza si pretender robarte tu informacion o tus datos.

El caso es que para evitar cualquiera de estas situaciones, se me ha ocurrido que seguramente se podrian implementar estas dos opciones en Luks:

1. Disponer de una contraseña con la que descifrar el soporte de manera correcta (la habitual, la real).
2. Disponer de una segunda contraseña con la que descifrar el soporte de manera encubierta (la forzada).

La opcion 1 ya esta implementada, con sus correspondientes llaves y tal, y funciona perfectamente (es la de siempre).
Pero la opcion 2, no existe (o al menos yo no la conozco).

Voy a explicar mi idea con un poco mas de detalle:

Si en alguna ocasion el usuario se viese forzado a desvelar su contraseña, utilizara la contraseña de la opcion 2.

Una vez que se introduzca la contraseña de la opcion 2, el sistema se descifrara correctamente pero de manera "encubierta".
Se realizara la presentacion de la partcion conteniendo una serie de archivos y/o directorios que previamente el usuario haya querido incorporar y presentar a quien haya intentado forzarle a desvelar sus datos.

Al disponer de esta opcion (la opcion 2), el usuario podria incorporar fotos, videos, pdfs, etc. de su vida, con los que tapar la boca al forzador, y este verse obligado a abandonar el uso de la fuerza.


Disculpar si no se me entiende bien lo que digo, hablo ingles bastante mal.


Supongo que no soy la primera persona que piensa en esta solucion, pero ahi lo dejo, por si es posible implementar esta segunda opcion (o contraseña).

Con esta funcionalidad, dariamos un autentico golpe de mano en cuanto a lo que se refiere a la privacidad de nuestras cosas. Que son nuestras y no tiene nadie ni nada por que indagar en ellas!

Gracias a todos otra vez.

Y lo dicho, disculpar por mi Ingles, lo hablo muy mal.


Un saludo desde España!
Jac.

P.D: Por cierto, no estoy suscrito a la lista. No quiero interferir con el trabajo de los desaroyadores.
</ES>
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: Luks, use the double force! :)

[Michael Kjörling]

On 25 May 2021 11:44 +0000, from xxjacs@yahoo.com (JAC):
> Once the option 2 password is entered, the system will decrypt
> correctly but "covertly".
> The partition will be presented containing a series of files and/or
> directories that the user has previously wanted to incorporate and
> present to whoever has tried to force him to reveal his data.
> /.../
> I suppose that I am not the first person who thinks about this
> solution, but I leave it there, in case it is possible to implement
> this second option (or password).

No, you're not the first person to think about having something like
this. In fact, it's covered in the LUKS FAQ, and has been for a while.
<https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions>

See in particular questions 5.2 "Is LUKS insecure? Everybody can see I
have encrypted data!" and 5.18 "What about Plausible Deniability?".

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”

_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: Luks, use the double force! :)

[Milan Broz]

On 26/05/2021 08:00, Michael Kjörling wrote:
> On 25 May 2021 11:44 +0000, from xxjacs@yahoo.com (JAC):
>> Once the option 2 password is entered, the system will decrypt 
>> correctly but "covertly". The partition will be presented
>> containing a series of files and/or directories that the user has
>> previously wanted to incorporate and present to whoever has tried
>> to force him to reveal his data. /.../ I suppose that I am not the
>> first person who thinks about this solution, but I leave it there,
>> in case it is possible to implement this second option (or
>> password).
> 
> No, you're not the first person to think about having something like 
> this. In fact, it's covered in the LUKS FAQ, and has been for a
> while. 
> <https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions>
>
>  See in particular questions 5.2 "Is LUKS insecure? Everybody can see
> I have encrypted data!" and 5.18 "What about Plausible
> Deniability?".

Just from the LUKS maintainer side, I'll repeat my opinions to two ideas
that appears here again and again:

1) LUKS will not implement any "self destruct" passphrases or anything like this.

   Everyone doing forensic analysis will work on the copy to prevent destruction
   of the master device. LUKS is designed to work on common hardware that is not
   tamper resistant - we cannot avoid that someone make copies of the encrypted drive.

2) LUKS is not designed to provide strong plausible deniability.

   While you can store header detached, and you can play with data offsets
   to unlock one device with two headers pointing to two content views of the drive,
   this is not a strong plausible deniability.

   Even if you invent some clever steganographic techniques, there will
   be problem with current storage devices that track used space (TRIM etc),
   I do not believe we can implement reliable plausible deniability system these days
   without help of a hardware level (FTL - flash translation layer, for example).

If you know about any paper or publication that tries to solve these problems
(and it has some proved concept behind it), please share it with us!

Thanks,
Milan
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: Luks, use the double force! :)

[Michael Kjörling]

On 26 May 2021 08:47 +0200, from gmazyland@gmail.com (Milan Broz):
> 1) LUKS will not implement any "self destruct" passphrases or anything like this.
> 
>    Everyone doing forensic analysis will work on the copy to prevent destruction
>    of the master device. LUKS is designed to work on common hardware that is not
>    tamper resistant - we cannot avoid that someone make copies of the encrypted drive.

Not just for that reason, either; certainly in a law enforcement
environment, forensic work must maintain the integrity of all evidence
throughout the process, lest the defense can argue in court that the
evidence may have been tampered with. (It doesn't even need to have
been tampered with; just the possibility may be sufficient to cast
doubt on the integrity of the evidence.) A relatively easy way to be
able to rebut such claims with regards to digital evidence is to
ensure the existence of a guaranteed pristine master and detailed
records of what actions have been performed; the easiest way to do
that is almost certainly to never, ever do anything that might
possibly write anything to the master, and _always_ work on copies
which have been created through write-blocked means.

After all, last I looked, likely-certified-as-good write blockers were
commercially available, and they can be tested independently as
black-box devices.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”

_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: Luks, use the double force! :)

[Arno Wagner]

On Wed, May 26, 2021 at 08:00:32 CEST, Michael Kjörling wrote:
> On 25 May 2021 11:44 +0000, from xxjacs@yahoo.com (JAC):
> > Once the option 2 password is entered, the system will decrypt
> > correctly but "covertly".
> > The partition will be presented containing a series of files and/or
> > directories that the user has previously wanted to incorporate and
> > present to whoever has tried to force him to reveal his data.
> > /.../
> > I suppose that I am not the first person who thinks about this
> > solution, but I leave it there, in case it is possible to implement
> > this second option (or password).
> 
> No, you're not the first person to think about having something like
> this. In fact, it's covered in the LUKS FAQ, and has been for a while.
> <https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions>
> 
> See in particular questions 5.2 "Is LUKS insecure? Everybody can see I
> have encrypted data!" and 5.18 "What about Plausible Deniability?".

If you have feedback, comments or questions for these (or other)
FAQ items, please let me know.

Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de