Hi
I use a Jessie machine since approx oct 2016.
LVM + cryptsetup (standard options of the Debian installer).
I've done updates each time it was possible.
I shut up this machine approx in march-may. When i came to boot in in june, i
was stuck with cryptsetup :
My passphrase is not ok for
On 6/06/2014 10:11 PM, Andrew McGlashan wrote:
On 6/06/2014 12:08 AM, Andrew McGlashan wrote:
The above script worked fine for around 45 minutes.
Okay, another update.
Sadly I've got a non-responsive server once again :(
It almost completed the task on the first crypt device:
DD_PID:
On 3/06/2014 5:38 AM, ken wrote:
On 06/02/2014 03:34 PM Andrew McGlashan wrote:
On 3/06/2014 5:25 AM, ken wrote:
Are you aware of FOSS 'wipe'?
Yes, thanks Ken. I watched wipe go through clearing an SSH
drive when setting up a quick test of Kali Linux on a new laptop.
It was slow, but it
On Sun, 08 Jun 2014 03:34:04 +1000
Andrew McGlashan andrew.mcglas...@affinityvision.com.au wrote:
Doing a GPG backup of the closed crypt volume would not
compress well. Obviously the more /real/ data there is on the
open crypt volume, the larger a GPG backup file will be.
Indeed, it is very
On 8/06/2014 4:06 AM, Bzzz wrote:
On Sun, 08 Jun 2014 03:34:04 +1000
Andrew McGlashan andrew.mcglas...@affinityvision.com.au wrote:
Doing a GPG backup of the closed crypt volume would not
compress well. Obviously the more /real/ data there is on the
open crypt volume, the larger a GPG
On Sun, 08 Jun 2014 06:03:07 +1000
Andrew McGlashan andrew.mcglas...@affinityvision.com.au wrote:
Sometimes you want forensic backups like having a USB image
that is /known/ to work for instance,
? AFAIK GRUB2 don't use the kernel LBA (opposite to LILO)
but only its name.
…
rsnapshot
On 8/06/2014 6:18 AM, Bzzz wrote:
On Sun, 08 Jun 2014 06:03:07 +1000
Andrew McGlashan andrew.mcglas...@affinityvision.com.au wrote:
rsnapshot doesn't compress [the backups], that might be the
biggest plus -- it does use symlinks though.
I just had a look to the link I sent you (there's some
On 8/06/2014 6:44 AM, Andrew McGlashan wrote:
On 8/06/2014 6:18 AM, Bzzz wrote:
FTR, haveged gives you a reservoir of entropy based upon
/dev/random.
Installed now looks very good!
Thanks again
A.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of
On Sun, 08 Jun 2014 07:03:32 +1000
Andrew McGlashan andrew.mcglas...@affinityvision.com.au wrote:
Installed now looks very good!
Thanks again
Well, not so fast :(
I didn't followed the RNGs analysis closely (I pick my
randomness elsewhere), but I just stumble upon this paper:
On 8/06/2014 8:02 AM, Bzzz wrote:
On Sun, 08 Jun 2014 07:03:32 +1000
Andrew McGlashan andrew.mcglas...@affinityvision.com.au wrote:
Installed now looks very good!
Thanks again
Well, not so fast :(
I didn't followed the RNGs analysis closely (I pick my
randomness elsewhere), but I
On Sun, 08 Jun 2014 08:35:21 +1000
Andrew McGlashan andrew.mcglas...@affinityvision.com.au wrote:
It seems that a /true/ hardware RNG that isn't pseudo is required,
anything less is subject to some kind of attack.
This would be the best (bestofzebest is the measure of the
decay of a
On 8/06/2014 8:53 AM, Bzzz wrote:
I'd say before these changes (it doesn't mention them),
thus, at least /dev/random might be cleared from these
flaws, which makes it quite a good candidate for crypto
(on the condition that random sources often run on the
machine, ie: web radio DVB dongle).
On Sun, 08 Jun 2014, Andrew McGlashan wrote:
saying that neither regular /dev/urandom nor /dev/random
are safe ( suggesting an attack against AES-128 CTR mode
could succeed in only 2^64 attempts).
This is a 2013 paper :(
Interesting, but I can't say that I fully understand it --
On 8/06/2014 9:48 AM, Henrique de Moraes Holschuh wrote:
Anyway, make sure you monkey around a lot with the keyboard and mouse before
you let the Debian installer generate any encrypted filesystems on a system
without a kernel-supported TRNG/HRNG/DRNG. Or get a large file of random
numbers
On Sun, 08 Jun 2014 10:03:59 +1000
Andrew McGlashan andrew.mcglas...@affinityvision.com.au wrote:
What if the installer would just pull in some live video stream(s)
such as YouTube, IPTV or even just live radio stations all via the
Internet, would that help?
No, because the RNG sampling is
On Sun, 08 Jun 2014, Andrew McGlashan wrote:
On 8/06/2014 9:48 AM, Henrique de Moraes Holschuh wrote:
Anyway, make sure you monkey around a lot with the keyboard and mouse before
you let the Debian installer generate any encrypted filesystems on a system
without a kernel-supported
On Sun, 08 Jun 2014, Bzzz wrote:
On Sun, 08 Jun 2014 10:03:59 +1000
Andrew McGlashan andrew.mcglas...@affinityvision.com.au wrote:
What if the installer would just pull in some live video stream(s)
such as YouTube, IPTV or even just live radio stations all via the
Internet, would that
On 6/06/2014 12:08 AM, Andrew McGlashan wrote:
The above script worked fine for around 45 minutes.
Okay, another update.
Hope I'm not speaking too soon, but a kernel update (Wheezy 7.5) and it
seems to be okay...
# uname -a
Linux n4800eco-a 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3+deb7u2
On 5/06/2014 11:06 AM, Andrew McGlashan wrote:
I'm not sure that pv isn't part of the problem, so I've adjusted to stop
using it.
Another failure, this time in /normal/ run, not dropbear environment.
It's not pv.
Here's a simple bash script that will do the job for me, just started it
again
On 4/06/2014 6:17 AM, Bob Proulx wrote:
Andrew McGlashan wrote:
[ 3839.679711] INFO: task kworker/3:3:392 blocked for more than 120 seconds.
This message and the ones that follow seem the most concerning to me.
First, I don't know. If I were having those messages I would suspect
that my
On 4/06/2014 11:35 AM, Jochen Spieker wrote:
Bob Proulx:
Andrew McGlashan wrote:
[ 3839.679711] INFO: task kworker/3:3:392 blocked for more than 120 seconds.
This message and the ones that follow seem the most concerning to me.
First, I don't know. If I were having those messages I would
Andrew McGlashan wrote:
[ 3839.679711] INFO: task kworker/3:3:392 blocked for more than 120 seconds.
This message and the ones that follow seem the most concerning to me.
First, I don't know. If I were having those messages I would suspect
that my hardware was having problems. Or that the
Bob Proulx:
Andrew McGlashan wrote:
[ 3839.679711] INFO: task kworker/3:3:392 blocked for more than 120 seconds.
This message and the ones that follow seem the most concerning to me.
First, I don't know. If I were having those messages I would suspect
that my hardware was having
On Mon, Jun 02, 2014 at 05:12:39AM +1000, Andrew McGlashan wrote:
Hi,
I am trying to write /dev/zero across an entire RAID1 encrypted volume.
The RAID1 partition is new, I opened it fine with luksOpen ...
and the next step is to write the /dev/zero across the whole partition.
Thank you Darac for your input.
Here's an update on what I'm doing now.
I caused the RAID1 mirrors to complete the sync in a dropbear boot
environment.
Now I'm writing /dev/zero to the crypt mounted volumes. No changes yet
to the form of the command, but if I see troubles, then I'll consider
On Tue, 03 Jun 2014 05:16:21 +1000
Andrew McGlashan andrew.mcglas...@affinityvision.com.au wrote:
Now I'm writing /dev/zero to the crypt mounted volumes. No
Just one silly question: why don't you first zero the
raw partition, then create whatever you want on it?
--
L'homme n'est pas fait
On 06/02/2014 03:16 PM Andrew McGlashan wrote:
Thank you Darac for your input.
Here's an update on what I'm doing now.
I caused the RAID1 mirrors to complete the sync in a dropbear boot
environment.
Now I'm writing /dev/zero to the crypt mounted volumes. No changes yet
to the form of the
On 3/06/2014 5:25 AM, ken wrote:
Are you aware of FOSS 'wipe'?
Yes, thanks Ken. I watched wipe go through clearing an SSH drive when
setting up a quick test of Kali Linux on a new laptop. It was slow, but
it worked -- when it finished, Kali had trouble allocating /itself/
enough root file
On 06/02/2014 03:34 PM Andrew McGlashan wrote:
On 3/06/2014 5:25 AM, ken wrote:
Are you aware of FOSS 'wipe'?
Yes, thanks Ken. I watched wipe go through clearing an SSH drive when
setting up a quick test of Kali Linux on a new laptop. It was slow, but
it worked -- when it finished, Kali had
On Mon, 02 Jun 2014 15:25:57 -0400
ken geb...@mousecar.com wrote:
Are you aware of FOSS 'wipe'?
IMHO, shred (pkg coreutils) is much faster and
as secured (except with SSD that have a special
sector recycle; but that applies to both programs).
--
I could dance with you till the cows come
On 3/06/2014 5:38 AM, ken wrote:
It would be better to write /dev/random or /dev/urandom than
/dev/zero... if you want to stay with whatever it is you're using.
Okay, well /dev/urandom is pseudo random, /dev/random is real random and
will block if there isn't enough entropy.
All the randomness
On 3/06/2014 5:24 AM, Bzzz wrote:
On Tue, 03 Jun 2014 05:16:21 +1000
Andrew McGlashan andrew.mcglas...@affinityvision.com.au wrote:
Now I'm writing /dev/zero to the crypt mounted volumes. No
Just one silly question: why don't you first zero the
raw partition, then create whatever you
On Tue, 03 Jun 2014 06:07:31 +1000
Andrew McGlashan andrew.mcglas...@affinityvision.com.au wrote:
The problem with that is that you will only have crypted data
where you write data in the volume. The rest will still be
zeroed ... better to have a fully crypted volume from first to
last byte,
On 3/06/2014 6:13 AM, Bzzz wrote:
On Tue, 03 Jun 2014 06:07:31 +1000
Andrew McGlashan andrew.mcglas...@affinityvision.com.au wrote:
The problem with that is that you will only have crypted data
where you write data in the volume. The rest will still be
zeroed ... better to have a fully
On Tue, 03 Jun 2014 06:22:46 +1000
Andrew McGlashan andrew.mcglas...@affinityvision.com.au wrote:
Okay, but my understanding is that once you have a LUKS crypt
volume (with the right setup), it doesn't matter what data you
write across the whole volume, it will all be fully encrypted
using
On 3/06/2014 6:32 AM, Bzzz wrote:
On Tue, 03 Jun 2014 06:22:46 +1000
Andrew McGlashan andrew.mcglas...@affinityvision.com.au wrote:
Okay, but my understanding is that once you have a LUKS crypt
volume (with the right setup), it doesn't matter what data you
write across the whole volume, it
Andrew McGlashan writes:
Yes, maybe so, but these are brand new 4TB drives that haven't had any
other data on them before (factory fresh). I've done badblock testing
on them as a first step after removing them from their new packaging
and so far, they haven't seen any data other than
On 3/06/2014 6:58 AM, John Hasler wrote:
Andrew McGlashan writes:
Yes, maybe so, but these are brand new 4TB drives that haven't had any
other data on them before (factory fresh). I've done badblock testing
on them as a first step after removing them from their new packaging
and so far, they
Hi,
I am trying to write /dev/zero across an entire RAID1 encrypted volume.
The RAID1 partition is new, I opened it fine with luksOpen ...
and the next step is to write the /dev/zero across the whole partition.
Right now I am working in a crafted [with extra tools] dropbear
environment,
On 2/06/2014 5:12 AM, Andrew McGlashan wrote:
md0 is all good:
No that is on a different machine not the right /dev/md0
Whoops.
I also get no response back with /sbin/madm -D /dev/md0 on the problem
machine.
A.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with
40 matches
Mail list logo
