Am 23.10.2023 um 12:04:35 Uhr schrieb Michael Kjörling:
> Encrypted /boot has been supported with GRUB 2 for a while. That
> leaves only a minimal portion of GRUB in plaintext on storage.
Although it is not default, so users should be aware that they need to
do additional steps to encrypt /boot.
On 23 Oct 2023 13:59 +0200, from m...@dorfdsl.de (Marco M.):
> Be aware that the boot loader and the /boot aren't encrypted by default
> and they can be attacked (e.g. simply place a tainted kernel inside) by
> anybody who has access to the harddisk.
Encrypted /boot has been supported with GRUB 2
Am 23.10.2023 um 12:53:14 Uhr schrieb lester29:
> 1. Does an encryption key on the USB protect against rubber-hose
> cryptanalysis?
No, the LUKS headers are viewable. You need another layer around that
supports hidden containers.
> 2. Is it true that key on pendrive is more r
On 23 Oct 2023 12:53 +0200, from leste...@gazeta.pl (lester29):
> 1. Does an encryption key on the USB protect against rubber-hose
> cryptanalysis?
I don't see how it would. Presumably you would have access to it;
therefore that access could potentially be exploited through coercion
Hi
I need to set up full disk encryption of the linux in my laptop.
Questions:
1. Does an encryption key on the USB protect against rubber-hose
cryptanalysis?
2. Is it true that key on pendrive is more risky than password because
someone can steal the usb key and access data without the need
Bottenberg, Michael (12023-03-10):
> > Of course not. [...]
> Quite the contrary.
Indeed, this bit is backward in my mail. Sorry.
Regards,
--
Nicolas George
space, at least 1/1000, probably more around 1/256 or 1/128.
Its indeed not a theoretical aspect, it is quite practical.
See Authenticated disk encryption via AEAD, cryptsetup(8) man page:
"Since Linux kernel version 4.12 dm-crypt supports authenticated disk
encryption."
Perfo
On Friday, March 10, 2023 02:54:39 AM Nicolas George wrote:
> rhkra...@gmail.com (12023-03-09):
> > Didn't you mean "of course"?
>
> I meant the rest of the paragraph and the ones after that.
Ahh, ok.
rhkra...@gmail.com (12023-03-09):
> Didn't you mean "of course"?
I meant the rest of the paragraph and the ones after that.
> If you reply: snip, snip, and snip again
Please apply good mail hygiene to what you send yourself. Signatures are
max four lines.
--
Nicolas George
On Thursday, March 09, 2023 04:16:14 PM Nicolas George wrote:
> rhkra...@gmail.com (12023-03-08):
> > The question: Suppose disk corruption corrupts one block in the data
> > storage area of a LUKS partition / filesystem (I'm not asking about
> > corruption in the headers or some other area of "me
On Thursday, March 09, 2023 04:03:20 PM David Christensen wrote:
> I believe I changed a byte somewhere in the middle of file blocks on
> disk using dd(1) and then I saw a bad byte somewhere in the middle of
> the file with less(1).
>
>
> I suggest that you repeat the experiment. Just going thro
rhkra...@gmail.com (12023-03-08):
> The question: Suppose disk corruption corrupts one block in the data storage
> area of a LUKS partition / filesystem (I'm not asking about corruption in the
> headers or some other area of "metadata"). In the case of one block of
> corruption in the data sto
applied
a partitioning scheme, created a partition, formatted the partition with
LUKS (with default encryption), opened the LUKS container, created an
ext4 filesystem, mounted the filesystem, and wrote a large file
containing a predictable pattern. I used hexdump(1) to find the
encrypted blocks on
created a partition, formatted the partition with
> LUKS (with default encryption), opened the LUKS container, created an
> ext4 filesystem, mounted the filesystem, and wrote a large file
> containing a predictable pattern. I used hexdump(1) to find the
> encrypted blocks on disk th
t including the corrupted block) be read
correctly?
Something I don't know is whether LUKS does encryption separately for each
block (or maybe for each file) or whether somehow the result of encryption is
one big "lump" of data (all files intermixed in the filesystem) and if
corr
kely not _all_ data if one excludes the
precious metadata from the consideration.
[...]
> Something I don't know is whether LUKS does encryption separately for each
> block (or maybe for each file) or whether somehow the result of encryption
> is one big "lump" of data [
probably yes (see below)
>* assuming the file with the corrupted block is bigger than one block, can
> the other parts of the file (not including the corrupted block) be read
> correctly?
>
> Something I don't know is whether LUKS does encryption separately for each
read
correctly?
Something I don't know is whether LUKS does encryption separately for each
block (or maybe for each file) or whether somehow the result of encryption is
one big "lump" of data (all files intermixed in the filesystem) and if
corruption of any individual block wil
On 2/3/22 14:07, john doe wrote:
> On 2/2/2022 9:57 PM, Georgi Naplatanov wrote:
>> Hi all,
>>
>> I saw that the installer of Debian 11 supports encrypted volumes.
>>
>> Is this LUKS2?
>>
>
> Yes for the root partition, works pretty well.
>
Thank you, Jhon and Andrew for the answers.
Kind regar
On 2/2/2022 9:57 PM, Georgi Naplatanov wrote:
Hi all,
I saw that the installer of Debian 11 supports encrypted volumes.
Is this LUKS2?
Yes for the root partition, works pretty well.
--
John Doe
On Wed, Feb 02, 2022 at 10:57:35PM +0200, Georgi Naplatanov wrote:
> Hi all,
>
> I saw that the installer of Debian 11 supports encrypted volumes.
>
> Is this LUKS2?
>
> If it's not, what is it?
>
> Kind regards
> Georgi
>
LUKS 2 as of Debian 10, apparently. Works really well for me in Debian
Hi all,
I saw that the installer of Debian 11 supports encrypted volumes.
Is this LUKS2?
If it's not, what is it?
Kind regards
Georgi
Hi,
thanks for all your help. It's working now as expected.
Fun fact: Had a small issue with the UUIDs, where I added a quote on left
side to a system config file, but none was allowed there. Therefore
(auto-)mounting failed (/dev/disk/by-uuid/\x22...) and it took some time
till the system came u
On Thu, 18 Nov 2021 18:17:43 +0100
Hans wrote:
> as far as I know, you also have to edit /etc/crypttab.
Correct. Sorry, I forget that. "man crypttab".
Do this before you run update-grub.
>
> If one has forgotten to encrypt a partition, the easiest way is, to
> boot from a livefile system. Th
Hi all,
as far as I know, you also have to edit /etc/crypttab.
If one has forgotten to encrypt a partition, the easiest way is, to boot from
a livefile system. Then backup the whole content of this partition to an
external partition. Note, this should be a ext3 or ext4 partition, so you
preser
ty
space. It would have been better to include the encryption and LVM as
part of installing,
--
Does anybody read signatures any more?
https://charlescurley.com
https://charlescurley.com/blog/
Hi,
I installed Debian 11 (bullseye) on a fresh PC.
I created 3 partitions: /, swap, /home.
...and forgot during installation dialog to encrypt the /home partition.
- how can I encrypt the /home partition now?
- In such a way that the password is asked for manual input during every boot?
- do
On Tue 12 Oct 2021 at 01:12:21 (-0400), Cindy Sue Causey wrote:
> On 10/11/21, detr...@tuta.io wrote:
> > Hello friends, I'm sending this last email to inform you that I have given
> > up on trying to recover the contents of my external hard drive and that I
> > formatted it.
> > Thank you to ever
On 10/11/21, detr...@tuta.io wrote:
> Hello friends, I'm sending this last email to inform you that I have given
> up on trying to recover the contents of my external hard drive and that I
> formatted it.
> Thank you to every single one of you who spared their time to try and help
> me.
> On one l
On Mon 11 Oct 2021 at 23:25:07 (+0200), deloptes wrote:
> David Christensen wrote:
>
> > When I boot my Debian machines with LUKS encrypted root filesystems, I
> > see a bunch of time-stamped bootloader messages followed by the prompt:
> >
> > Please unlock disk sda3_crypt:
> >
> >
> > When I t
David Christensen wrote:
> When I boot my Debian machines with LUKS encrypted root filesystems, I
> see a bunch of time-stamped bootloader messages followed by the prompt:
>
> Please unlock disk sda3_crypt:
>
>
> When I type on the keyboard, nothing is echoed to the screen.
I use plymouth or a
On Mon 11 Oct 2021 at 12:43:21 (-0700), David Christensen wrote:
> On 10/11/21 05:50, detr...@tuta.io wrote:
> > Hello friends, I'm sending this last email to inform you that I have given
> > up on trying to recover the contents of my external hard drive and that I
> > formatted it.
>
> I hope y
On 10/11/21 05:50, detr...@tuta.io wrote:
Hello friends, I'm sending this last email to inform you that I have given up
on trying to recover the contents of my external hard drive and that I
formatted it.
I hope you have implemented backups procedures, to prevent losing data
in the future.
Hello friends, I'm sending this last email to inform you that I have given up
on trying to recover the contents of my external hard drive and that I
formatted it.
Thank you to every single one of you who spared their time to try and help me.
On one last note, I should I drag attention to what see
, mounting the
filesystem(s), and backing up the data.
Tried it and when it asks for the encryption password it doesn't work. It just
goes back to the same screen asking for /dev/sdb5's password and doesn't even
show an error message.
You are talking about the system boot scre
On 29.08.21 07:09, detr...@tuta.io wrote:
(...)
Before:
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE%
MOUNTPOINTS
sda
├─sda1
│ vfat FAT32 A2BD-D233 70,8M 26%
/boot/efi
├─sda2
│
├─sda3
│ ntfs 2AD4C9CED4C9
you tried them all?
No, it's only one and the recovery mode and I have tried both.
>If none of the kernel choices work, try booting the Debian installer media,
>navigate into a recovery console, opening the LUKS container(s), mounting the
>filesystem(s), and backing up the dat
detr...@tuta.io:
>
> Around May I installed Debian 10 on my (external) hard drive in BIOS
> (not UEFI) mode for backup purposes. In the end of June I took the
> drive out of the drawer and tried to boot into it but to my surprise
> my LUKS encryption password does not work anymore.
order.
>
> Around May I installed Debian 10 on my (external) hard drive in BIOS (not
> UEFI) mode for backup purposes. In the end of June I took the drive out of
> the drawer and tried to boot into it but to my surprise my LUKS encryption
> password does not work anymore.
> I
nstalled Debian 10 on my (external) hard drive in BIOS (not UEFI)
mode for backup purposes. In the end of June I took the drive out of the drawer
and tried to boot into it but to my surprise my LUKS encryption password does
not work anymore.
I'm very sure I am typing it right because I h
Sorry about no quotes in my previous message. I don't know where did
they went? ;)
On 26/08/2021 02:37, detr...@tuta.io wrote:
my LUKS encryption password does not work anymore.
Can you paste system logs showing that, so we know *why* it doesn't work
I have tried to unlock and mount it inside my OS (Manjaro) instead of
booting it directly but it also didn't work
On Thu 26 Aug 2021 at 03:37:54 (+0200), detr...@tuta.io wrote:
> Around May I installed Debian 10 on my (external) hard drive in BIOS (not
> UEFI) mode for backup purposes. In the end of June I took the drive out of
> the drawer and tried to boot into it but to my surprise my LUKS e
ve in BIOS (not UEFI)
mode for backup purposes. In the end of June I took the drive out of the drawer
and tried to boot into it but to my surprise my LUKS encryption password does
not work anymore.
I'm very sure I am typing it right because I had written it into a piece of
paper. I have tried
On 7/2/21 8:02 AM, David Wright wrote:
On Thu 01 Jul 2021 at 20:43:09 (-0700), David Christensen wrote:
On 7/1/21 7:55 PM, David Wright wrote:
On Mon 28 Jun 2021 at 13:36:35 (-0700), David Christensen wrote:
I do not set the 'discard' (trim) option in fstab(5). If and when I
want to erase un
On Fri, Jul 02, 2021 at 10:02:18AM -0500, David Wright wrote:
But what happens with an SSD? If, after the rm step above, you
# fstrim /home
the mountpoint, where /etc/fstab has the line
/dev/mapper/luks-fedcba98-7654-3210-… LABEL1 ext4 /home
then what gets zeroed
If everything's appropriately
On Thu 01 Jul 2021 at 20:43:09 (-0700), David Christensen wrote:
> On 7/1/21 7:55 PM, David Wright wrote:
> > On Mon 28 Jun 2021 at 13:36:35 (-0700), David Christensen wrote:
> >
> > > I do not set the 'discard' (trim) option in fstab(5). If and when I
> > > want to erase unused blocks (such as b
On 7/1/21 7:55 PM, David Wright wrote:
On Mon 28 Jun 2021 at 13:36:35 (-0700), David Christensen wrote:
I do not set the 'discard' (trim) option in fstab(5). If and when I
want to erase unused blocks (such as before taking an image), I use
fstrim(8).
Can you elaborate on a couple of things:
On Mon 28 Jun 2021 at 13:36:35 (-0700), David Christensen wrote:
> I do not set the 'discard' (trim) option in fstab(5). If and when I
> want to erase unused blocks (such as before taking an image), I use
> fstrim(8).
Can you elaborate on a couple of things:
How do you "take an image". Is this
>> > Along with SED, I suggest that you also implement Secure Boot.
>> Can someone give me pointers to actually known attacks (not
>> hypothetical ones, which I can invent myself without much difficulty)
>> that would have been prevented by Secure Boot?
> [2] https://en.wikipedia.org/wiki/Evil_ma
urity
researchers at the Radboud University in the Netherlands, titled:
"Self-Encrypting Deception: Weaknesses in the encryption of solid-
state drives."
https://ieeexplore.ieee.org/abstract/document/8835339
Interesting. The IEEE paper seems to cover Crucial, Samsung, and
Western Digital/Sandis
On 6/29/21 12:47 AM, to...@tuxteam.de wrote:
On Mon, Jun 28, 2021 at 07:56:47PM -0400, Stefan Monnier wrote:
Along with SED, I suggest that you also implement Secure Boot.
Can someone give me pointers to actually known attacks (not
hypothetical ones, which I can invent myself without much diff
Hi David,
Thanks for your reply.
On 28/06/2021 21:36, David Christensen wrote:
Software encryption (dm-crypt, Linux Unified Key System (LUKS), etc.)
for a system drive is typically applied to the swap, root, and/or data
partitions, but the master boot record (partition table and boot
loader
On Mon, Jun 28, 2021 at 01:36:35PM -0700, David Christensen wrote:
I do not set the 'discard' (trim) option in fstab(5). If and when I
want to erase unused blocks (such as before taking an image), I use
fstrim(8).
I believe this is installed and enabled by default in Bullseye (at least
new in
On Mon, Jun 28, 2021 at 07:56:47PM -0400, Stefan Monnier wrote:
> > Along with SED, I suggest that you also implement Secure Boot.
>
> Can someone give me pointers to actually known attacks (not
> hypothetical ones, which I can invent myself without much difficulty)
> that would have been prevente
> Along with SED, I suggest that you also implement Secure Boot.
Can someone give me pointers to actually known attacks (not
hypothetical ones, which I can invent myself without much difficulty)
that would have been prevented by Secure Boot?
I can see that subverting the early boot might be a goo
On 6/28/21 1:36 PM, David Christensen wrote:
(Dell factory default for drives is 'RAID'; 'ACPI' may be required).
Correction: AHCI.
David
On 6/28/21 7:52 AM, piorunz wrote:
Hi all,
I've got about 5 years old HP laptop with SSD SATA drive 240 GB. Debian
Bullseye will be installed on it once it's released, as my secondary
computer to use.
I have question regarding whole disk encryption. What technology should
I us
piorunz:
>
> I have question regarding whole disk encryption. What technology should
> I use, to have encryption of everything, or at least /home, but preserve
> free blocks and have TRIM?
The canonical answer is "LUKS". You can configure it during installation
if you wan
Hi all,
I've got about 5 years old HP laptop with SSD SATA drive 240 GB. Debian
Bullseye will be installed on it once it's released, as my secondary
computer to use.
I have question regarding whole disk encryption. What technology should
I use, to have encryption of everything, or at l
rhkra...@gmail.com wrote:
> Darn, please ignore the previous message -- didn't mean to send, was
> working on a draft, meant to save as a draft instead of send.
>
> (Of course, if you want to reply, feel free.)
.
> But in any case, I'm not sure about booting Grub on an SSD from the
> BIOS, because AIUI Grub uses sector addresses to find its core.img,
> and AIUI sectors get shuffled around by the SSD controller.
That shuffling is purely internal and hence completely invisible
(barring bugs and the need to s
On Thu 10 Jun 2021 at 23:43:12 (-0700), David Christensen wrote:
> On 6/10/21 9:31 PM, David Wright wrote:
> > I'm about to install buster or bullseye on a newly acquired laptop
> > with an SSD (a first for me). I'm intending to clean (zero or
> > randomise) the entire drive with dd before I start,
n/purging. I'm just encrypting stuff like personal bank
records etc, and not looking for anything like plausible deniability.
Cheers,
David.
Why do you really want so much encryption level (swap with discard,
encrypted swap, encrypted all the partition, etc).
Other than your user data
On 6/11/21 6:01 AM, Reco wrote:
On Fri, Jun 11, 2021 at 05:55:02AM -0700, David Christensen wrote:
On 6/10/21 11:49 PM, Reco wrote:
On Thu, Jun 10, 2021 at 11:43:12PM -0700, David Christensen wrote:
I don't bother with the 'discard' option in /etc/fstab, but perhaps I
should. The fstab(5) and
On Thu, Jun 10, 2021 at 11:31:07PM -0500, David Wright wrote:
I'm about to install buster or bullseye on a newly acquired laptop
with an SSD (a first for me). I'm intending to clean (zero or
randomise) the entire drive with dd before I start, and am
interested in any pitfalls with that.
Do not
On Fri, Jun 11, 2021 at 06:19:37PM +0300, Reco wrote:
Encryption costs me whopping 13 MB/s out of 385.
Right now on my desktop I can read about 1.4GByte/s on an unencrypted
partition and 1.3Gbyte/s on an encrypted partition. Whether that's
significant is subjective.
er/sda3_crypt is active and is in use.
type:LUKS1
cipher: aes-xts-plain64
keysize: 512 bits
key location: dm-crypt
device: /dev/sda3
# pv /dev/mapper/sda3_crypt > /dev/zero
^C68GiB 0:00:05 [ 372MiB/s]
Encryption costs me whopping 13 MB/s out of 385.
And note that it's a 4
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
‐‐‐ Original Message ‐‐‐
On Thursday, June 10th, 2021 at 10:31 PM, David Wright
wrote:
> I'm intending to clean (zero or
> randomise) the entire drive with dd before I start
Have you considered dban? Takes a while, but works real goo
Darn, please ignore the previous message -- didn't mean to send, was working
on a draft, meant to save as a draft instead of send.
(Of course, if you want to reply, feel free.)
On Friday, June 11, 2021 11:01:40 AM rhkra...@gmail.com wrote:
> On Friday, June 11, 2021 02:49:03 AM Reco wrote:
> > O
On Fri, Jun 11, 2021 at 11:01:40AM -0400, rhkra...@gmail.com wrote:
> On Friday, June 11, 2021 02:49:03 AM Reco wrote:
> > On Thu, Jun 10, 2021 at 11:43:12PM -0700, David Christensen wrote:
> > > I don't bother with the 'discard' option in /etc/fstab, but perhaps I
> > > should. The fstab(5) and m
On Friday, June 11, 2021 02:49:03 AM Reco wrote:
> On Thu, Jun 10, 2021 at 11:43:12PM -0700, David Christensen wrote:
> > I don't bother with the 'discard' option in /etc/fstab, but perhaps I
> > should. The fstab(5) and mount(8) manual pages are unclear if
> > 'discard' applies to swap or ext4.
>
ent,
> ie so-called logical and digital sanitisation, but not analogue
> sanitisation/purging. I'm just encrypting stuff like personal bank
> records etc, and not looking for anything like plausible deniability.
>
> Cheers,
> David.
>
Why do you really want so much encryptio
On Fri, Jun 11, 2021 at 05:55:02AM -0700, David Christensen wrote:
> On 6/10/21 11:49 PM, Reco wrote:
> > On Thu, Jun 10, 2021 at 11:43:12PM -0700, David Christensen wrote:
> > > I don't bother with the 'discard' option in /etc/fstab, but perhaps I
> > > should. The fstab(5) and mount(8) manual pa
On 6/10/21 11:49 PM, Reco wrote:
Hi.
On Thu, Jun 10, 2021 at 11:43:12PM -0700, David Christensen wrote:
I don't bother with the 'discard' option in /etc/fstab, but perhaps I
should. The fstab(5) and mount(8) manual pages are unclear if
'discard' applies to swap or ext4.
swapon(8):
On Thu, Jun 10, 2021 at 11:31:07PM -0500, David Wright wrote:
> I'm about to install buster or bullseye on a newly acquired laptop
> with an SSD (a first for me). I'm intending to clean (zero or
> randomise) the entire drive with dd before I start, and am
> interested in any pitfalls with that.
>
Hi.
On Thu, Jun 10, 2021 at 11:43:12PM -0700, David Christensen wrote:
> I don't bother with the 'discard' option in /etc/fstab, but perhaps I
> should. The fstab(5) and mount(8) manual pages are unclear if
> 'discard' applies to swap or ext4.
swapon(8):
-d, --discard[=policy]
On 6/10/21 9:31 PM, David Wright wrote:
I'm about to install buster or bullseye on a newly acquired laptop
with an SSD (a first for me). I'm intending to clean (zero or
randomise) the entire drive with dd before I start, and am
interested in any pitfalls with that.
I will also encrypt the new /h
David Wright wrote:
...
> I don't work for the CIA, so "basic" erasure methods are sufficient,
> ie so-called logical and digital sanitisation, but not analogue
> sanitisation/purging. I'm just encrypting stuff like personal bank
> records etc, and not looking for anything like plausible deniabili
On 11/6/21 12:31 pm, David Wright wrote:
I'm about to install buster or bullseye on a newly acquired laptop
with an SSD (a first for me). I'm intending to clean (zero or
randomise) the entire drive with dd before I start, and am
interested in any pitfalls with that.
I will also encrypt the new
I'm about to install buster or bullseye on a newly acquired laptop
with an SSD (a first for me). I'm intending to clean (zero or
randomise) the entire drive with dd before I start, and am
interested in any pitfalls with that.
I will also encrypt the new /home partition, but for the remaining
parti
On Sat Aug 31 2019 at 03:40 PM +0200, Stefan Krusche wrote:
> Am Freitag, 30. August 2019 schrieb Bill Brelsford:
> > My 64-bit buster installation was created using its installer, with
> > / and /home partitions in an encrypted logical volume (sda3_crypt).
> > On shutdown, it pauses near the end w
Am Freitag, 30. August 2019 schrieb Bill Brelsford:
> My 64-bit buster installation was created using its installer, with
> / and /home partitions in an encrypted logical volume (sda3_crypt).
> On shutdown, it pauses near the end with
>
> Stopping remaining crypto disks... sda3_crypt (busy) sda3_
My 64-bit buster installation was created using its installer, with
/ and /home partitions in an encrypted logical volume (sda3_crypt).
On shutdown, it pauses near the end with
Stopping remaining crypto disks... sda3_crypt (busy) sda3_crypt busy...
The busy messages continue for about 30 second
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/02/2019 12:26, Étienne Mollier wrote:
> Dider Gaumet, on 2019-02-03 : >> In my previous test I did not close
> Thunderbird before reopening the
>> signed and encrypted draft message. >> this time I did it and nothing
changed: The right titl
Dider Gaumet, on 2019-02-03 :
> In my previous test I did not close Thunderbird before reopening the
> signed and encrypted draft message.
> this time I did it and nothing changed: The right title of the draft was
> still there.
Good Day,
It could have been temporary, I've seen these symptoms som
In my previous test I did not close Thunderbird before reopening the
signed and encrypted draft message.
this time I did it and nothing changed: The right title of the draft was
still there.
I prefer to stick to Stable but my main laptop is fairly new, that is
why Buster is installed on it.
So
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/02/2019 20:08, Cindy-Sue Causey wrote:
> On 2/2/19, Thomas D Dial wrote: >> I noticed this a few weeks
> or a month ago and took it to be a
somewhat >> inelegant, maybe incompletely implemented, feature intended
to improve >> metadata secu
On 2/2/19, Thomas D Dial wrote:
> I noticed this a few weeks or a month ago and took it to be a somewhat
> inelegant, maybe incompletely implemented, feature intended to improve
> metadata security. I believe "Encrypted message" also becomes the
> subject of the transmitted message.
>
> Exposure o
On Fri, 2019-02-01 at 18:26 +, Paul Sutton wrote:
> Hi
>
> Thunderbird + Enigmail has an option in "account settings" OpenPGP
> Security to save a draft of a message with encryption, as expected
> this
> saves the draft but with a new subject as "Encrypted me
On 02/02/2019 13:12, Paul Sutton wrote:
> On 02/02/2019 09:14, didier gaumet wrote:
>> Hello Paul,
>>
>> Same versions of thunderbird and Enigmail here but Debian Buster.
>>
>> I do not observe the same thing as you do: the draft is saved with the
>> intended title
>>
>> It is probably of no impor
On 02/02/2019 09:14, didier gaumet wrote:
> Hello Paul,
>
> Same versions of thunderbird and Enigmail here but Debian Buster.
>
> I do not observe the same thing as you do: the draft is saved with the
> intended title
>
> It is probably of no importance but my Debian (and Thunderbird) is in french
Hello Paul,
Same versions of thunderbird and Enigmail here but Debian Buster.
I do not observe the same thing as you do: the draft is saved with the
intended title
It is probably of no importance but my Debian (and Thunderbird) is in french
On 01/02/2019 21:24, Étienne Mollier wrote:
> On 2/1/19 7:26 PM, Paul Sutton wrote:
>> If you save the message, close the compose window, then go to Drafts,
>> then reopen the message for more editing before sending the subject
>> remains as "Encrypted message" and you lose the original subject
On 2/1/19 7:26 PM, Paul Sutton wrote:
> If you save the message, close the compose window, then go to Drafts,
> then reopen the message for more editing before sending the subject
> remains as "Encrypted message" and you lose the original subject header.
>
> I just wondered if this is what is m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi
Thunderbird + Enigmail has an option in "account settings" OpenPGP
Security to save a draft of a message with encryption, as expected this
saves the draft but with a new subject as "Encrypted message" and it
appears in dra
On 13/01/2019 12.46, Celejar wrote:
On Fri, 11 Jan 2019 21:45:57 +
I believe that the most commonly used software for file level
encryption is EncFS. I haven't really used it much, and can't speak to
its long term stablity.
EncFS should not be used for any new file encrypti
On Fri, 11 Jan 2019 21:45:57 +
Jonathan Dowland wrote:
> On Wed, Jan 09, 2019 at 10:18:47PM -0500, Celejar wrote:
> >The standard encryption technology for linux is LUKS. It works on the
> >block device level, not the file level.
>
> LUKS would be no good if the us
On 11.01.19 22:45, Jonathan Dowland wrote:
> EncFS should not be used for any new file encryption project, IMHO.
> There was the following report in 2014:
> https://defuse.ca/audits/encfs.htm
> This is referenced in the NEWS file in the EncFS package
> https://salsa.debian.org/de
On Wed, Jan 09, 2019 at 10:18:47PM -0500, Celejar wrote:
The standard encryption technology for linux is LUKS. It works on the
block device level, not the file level.
LUKS would be no good if the user wants to move/copy/share the encrypted
files, encrypted, elsewhere: they didn't s
1 - 100 of 605 matches
Mail list logo
