Victor Ivanov wrote:
> From what I gather, taking into account your other email as well, there
> are two separate things going on which may or may not be related:
>
> 1) The (now open) filesystem isn't being mounted where it should as per
> fstab
>
> 2) Even then, there appears to be a bogus 'priva
From what I gather, taking into account your other email as well, there
are two separate things going on which may or may not be related:
1) The (now open) filesystem isn't being mounted where it should as per
fstab
2) Even then, there appears to be a bogus 'private' parent directory:
/run/media/
Victor Ivanov wrote:
> On 10/06/2020 21:52, Dale wrote:
>> I've got that in dmcrypt and fstab as the wiki says. That part works.
>> It's the KDE part that isn't working correctly. However, I did do one
>> thing different, I put users instead of user. Plural not singular.
>> Should users work t
On 10/06/2020 21:52, Dale wrote:
> I've got that in dmcrypt and fstab as the wiki says. That part works.
> It's the KDE part that isn't working correctly. However, I did do one
> thing different, I put users instead of user. Plural not singular.
> Should users work the same as user?
This make
Michael wrote:
> On Wednesday, 10 June 2020 07:59:19 BST Dale wrote:
>> Howdy,
>>
>> Same topic just new question. I use KDE and am wanting to have it so
>> the Device Notifier will allow me to mount the drive when I turn it on.
> I probably missed in earlier threads, but is this is an externally
Victor Ivanov wrote:
> On 10/06/2020 07:59, Dale wrote:
>> It tells me I don't have permission to access but it also mounts it
> This KDE bug re Device Notifier has been present for a long time and
> it's seriously infuriating. Mounting from Dolphin, on the other hand,
> seems to work just fine, th
On 10/06/2020 07:59, Dale wrote:
> It tells me I don't have permission to access but it also mounts it
This KDE bug re Device Notifier has been present for a long time and
it's seriously infuriating. Mounting from Dolphin, on the other hand,
seems to work just fine, though it too doesn't miss the
On Wednesday, 10 June 2020 07:59:19 BST Dale wrote:
> Howdy,
>
> Same topic just new question. I use KDE and am wanting to have it so
> the Device Notifier will allow me to mount the drive when I turn it on.
I probably missed in earlier threads, but is this is an externally powered USB
device?
Howdy,
Same topic just new question. I use KDE and am wanting to have it so
the Device Notifier will allow me to mount the drive when I turn it on.
So far, I got it set up and when I turn the drive on and click for it to
mount it, it asks me for a password. I type in the password but it
mounts
antlists wrote:
> On 07/06/2020 10:07, antlists wrote:
>> I think it was LWN, there was an interesting article on crypto recently.
>
> https://lwn.net/Articles/821544/
>
> Cheers,
> Wol
>
>
Looks like they are getting ready to toss sha1 overboard. If it is not
secure, they should. At least most
On 07/06/2020 10:07, antlists wrote:
I think it was LWN, there was an interesting article on crypto recently.
https://lwn.net/Articles/821544/
Cheers,
Wol
On Fri, Jun 05, 2020 at 11:37:23PM -0500, Dale wrote:
> Howdy,
>
> I think I got a old 3TB hard drive to work. After dd'ing it, redoing
> partitions and such, it seems to be working. Right now, I'm copying a
> bunch of data to it to see how it holds up. Oh, it's a PMR drive too.
> lol Once I'
On 07/06/2020 12:52, Victor Ivanov wrote:
> Indeed. I second Rich and too would recommend sticking with AES for this
> reason. LUKS will support an AES key of up to 512 bits. It's fast and
> hardware acceleration is widely available.
> ...
> For example, Intel's native AES extensions work in 4x4
On 07/06/2020 09:08, Dale wrote:
> You can have a password, a key file, both or likely other options as
> well. On one video, the guy generated a key file with urandom that was
> 1024 characters. As he put it, try typing that in.
Indeed! All of these techniques have various pros/cons which is pa
On Sun, Jun 7, 2020 at 4:08 AM Dale wrote:
>
> I still don't think I'm ready to try and do this on a hard drive. I'm
> certainly not going to do this with /home yet.
If you have a spare drive or just a USB stick lying around, set it up
on that. Then you can test that it mounts on boot and prom
On 07/06/2020 09:08, Dale wrote:
I notice that one can use different encryption tools. I have Blowfish,
Twofish, AES and sha*** as well as many others. I know some have been
compromised. Which ones are known to be secure? I seem to recall that
after Snowden some had to be redone and some ne
Dale wrote:
>
>
> My take. Bad password, easy to guess, easy to crack because it is
> simple or common; not very secure even if the password is changed
> since one could use the old password in certain situations and get at
> the data. Good strong password, changed or not; hard to crack even if
>
On 06/06/2020 21:12, Rich Freeman wrote:
To do this I'm just going to store my
keys on the root filesystem so that the systems can be booted without
interaction. Obviously if somebody compromises the files with the
keys they can decrypt my drives, but this means that I just have to
protect a c
Sebastiaan L. Zoutendijk wrote:
> Dear Dale,
>
> On Friday 5 June 2020, 11.37pm -0500, Dale wrote:
>
>> Is this a secure method or is there a more secure way? Is there any
>> known issues with using this? Anyone here use this method? Keep in
>> mind, LVM. BTFRS, SP?, may come later.
> A
Rich Freeman wrote:
> On Sat, Jun 6, 2020 at 8:47 PM Victor Ivanov wrote:
>> On 06/06/2020 21:12, Rich Freeman wrote:
>>> Maybe we're miscommunicating, but it seems like you're moving the
>>> goalposts here.
>>> ...
>>> Your original point was, "The problem here is that a leaked header
>>> immedia
On Sat, Jun 6, 2020 at 8:47 PM Victor Ivanov wrote:
>
> On 06/06/2020 21:12, Rich Freeman wrote:
> > Maybe we're miscommunicating, but it seems like you're moving the
> > goalposts here.
> > ...
> > Your original point was, "The problem here is that a leaked header
> > immediately means a compromi
On 06/06/2020 21:12, Rich Freeman wrote:
> My point remains:
>
> The header is as secure as the disk. If the disk is secure against
> brute-force, then so is the header.
I never said otherwise. This was, in fact, explicitly stated in my
concluding remarks of my original post where I say "If using
Dear Dale,
On Friday 5 June 2020, 11.37pm -0500, Dale wrote:
> Is this a secure method or is there a more secure way? Is there any
> known issues with using this? Anyone here use this method? Keep in
> mind, LVM. BTFRS, SP?, may come later.
Another thing to keep in mind: if you only
On Sat, Jun 6, 2020 at 3:38 PM Victor Ivanov wrote:
>
> On 06/06/2020 19:51, Rich Freeman wrote:
> > Sure, if the attacker has a copy of the header they can spend as much
> > time as they wish brute-forcing it. However, the same is true if they
> > have the entire disk, and that is precisely the
On 06/06/2020 19:51, Rich Freeman wrote:
> If you're talking about the drive header that is actually written to
> disk, it is as secure as the entire drive is, since the drive contains
> the header.
I never said it was any less secure. It would be daft to even assume
something like that as it's de
On 6 June 2020 17:07:37 CEST, Dale wrote:
>antlists wrote:
>> On 06/06/2020 08:49, Dale wrote:
>>> First drive seems to have died. Got part way copying files and
>>> things got interesting. When checking smartctrl, it even puked on
>my
>>> keyboard. Drive only had a few hundred hours on it so m
On Sat, Jun 6, 2020 at 10:07 AM Victor Ivanov wrote:
>
> The problem here is that a leaked header immediately means a compromised
> volume. An adversary who gets hold of the header can now spend as much
> time as they would like to brute force a password (depending on password
> strength) and deri
antlists wrote:
> On 06/06/2020 08:49, Dale wrote:
>> First drive seems to have died. Got part way copying files and
>> things got interesting. When checking smartctrl, it even puked on my
>> keyboard. Drive only had a few hundred hours on it so maybe the
>> drive was iffy from the start or that
On 6/6/20 10:10 AM, Rich Freeman wrote:
One of the problems with drive-managed SMR is that it can seem to be
ok when you're just doing light duty access, and then when one of your
other drives fails and you're doing a zfs resilver the SMR drive
starts performing an order of magnitude or more wors
On 06/06/2020 14:57, antlists wrote:
Oh - the other thing - if it's PMR and you're copying files onto it,
expect a puke! That thing on WD Reds going PMR, I copied most of that on
to the linux raid mailing list and the general feeling I get is "PMR is
bad".
Whoops have I got my PMR and SMR mixe
On 06/06/2020 11:32, Michael wrote:
Of particular interest to me is recovery of encrypted files/partitions, using
a different installation than the original. Having to keep a copy of the
original installation kernel keys for ext4 with any data backups and
additionally remembering to refresh them
On Sat, Jun 6, 2020 at 9:57 AM antlists wrote:
>
> Oh - the other thing - if it's PMR and you're copying files onto it,
> expect a puke! That thing on WD Reds going PMR, I copied most of that on
> to the linux raid mailing list and the general feeling I get is "PMR is
> bad".
>
You're mixing up P
On 06/06/2020 05:37, Dale wrote:
> One other question, can one change the password every once in a while?
> Or once set, you stuck with it from then on?
A point I forgot to mention in my previous email is regarding passwords.
While most encryption methods will allow for a password change (CryFS
On 06/06/2020 08:49, Dale wrote:
First drive seems to have died. Got part way copying files and things
got interesting. When checking smartctrl, it even puked on my
keyboard. Drive only had a few hundred hours on it so maybe the drive
was iffy from the start or that enclosure did damage some
On 06/06/2020 12:05, Rich Freeman wrote:
> Usually you want the encryption as close to the disk as possible
> because if somebody gets your disk it gives them less to work with.
> They don't know that you have a logical volume called "home" on it,
> and so on.
I concur with Rich on this.
One of
On Sat, Jun 6, 2020 at 3:49 AM Dale wrote:
>
> Thanks for both replies. I found one other Gentoo one but it was encrypting
> the whole thing, /boot and all, plus they used efi. I didn't find the one
> you linked too.
The Gentoo guide that was linked uses an example of encrypting a partition.
On Saturday, 6 June 2020 08:49:54 BST Dale wrote:
> J. Roeleveld wrote:
> > On 6 June 2020 06:37:23 CEST, Dale wrote:
> >> Howdy,
> >>
> >> I think I got a old 3TB hard drive to work. After dd'ing it, redoing
> >> partitions and such, it seems to be working. Right now, I'm copying a
> >> bunch
J. Roeleveld wrote:
> On 6 June 2020 06:37:23 CEST, Dale wrote:
>> Howdy,
>>
>> I think I got a old 3TB hard drive to work. After dd'ing it, redoing
>> partitions and such, it seems to be working. Right now, I'm copying a
>> bunch of data to it to see how it holds up. Oh, it's a PMR drive too.
On 6 June 2020 06:37:23 CEST, Dale wrote:
>Howdy,
>
>I think I got a old 3TB hard drive to work. After dd'ing it, redoing
>partitions and such, it seems to be working. Right now, I'm copying a
>bunch of data to it to see how it holds up. Oh, it's a PMR drive too.
>lol Once I'm pretty sure it
On 6 June 2020 06:37:23 CEST, Dale wrote:
>Howdy,
>
>I think I got a old 3TB hard drive to work. After dd'ing it, redoing
>partitions and such, it seems to be working. Right now, I'm copying a
>bunch of data to it to see how it holds up. Oh, it's a PMR drive too.
>lol Once I'm pretty sure it
40 matches
Mail list logo
