On Sun, 08 Jun 2014, Bzzz wrote:
> On Sun, 08 Jun 2014 10:03:59 +1000
> Andrew McGlashan 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 s
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 TRN
On Sun, 08 Jun 2014 10:03:59 +1000
Andrew McGlashan 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 rare, so you need
some time to fill th
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, 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 understa
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 dong
On Sun, 08 Jun 2014 08:35:21 +1000
Andrew McGlashan 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 radioactive element… which will be feasible
in
On 8/06/2014 8:02 AM, Bzzz wrote:
> On Sun, 08 Jun 2014 07:03:32 +1000
> Andrew McGlashan 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 p
On Sun, 08 Jun 2014 07:03:32 +1000
Andrew McGlashan 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:
https://eprint.iacr.org/2013/338.pdf
saying t
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 8/06/2014 6:18 AM, Bzzz wrote:
> On Sun, 08 Jun 2014 06:03:07 +1000
> Andrew McGlashan 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 times
> I didn't installed Bac
On Sun, 08 Jun 2014 06:03:07 +1000
Andrew McGlashan 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 doesn't compress [the backups], that m
On 8/06/2014 4:06 AM, Bzzz wrote:
> On Sun, 08 Jun 2014 03:34:04 +1000
> Andrew McGlashan 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,
On Sun, 08 Jun 2014 03:34:04 +1000
Andrew McGlashan 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 bad practice to bit backup (except
i
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 sl
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_
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 x86_
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
> ag
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 messa
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
> t
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 p
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 ker
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 f
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 encry
On 3/06/2014 6:32 AM, Bzzz wrote:
> On Tue, 03 Jun 2014 06:22:46 +1000
> Andrew McGlashan 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
>>
On Tue, 03 Jun 2014 06:22:46 +1000
Andrew McGlashan 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 your own specific key. There are wea
On 3/06/2014 6:13 AM, Bzzz wrote:
> On Tue, 03 Jun 2014 06:07:31 +1000
> Andrew McGlashan 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
>> l
On Tue, 03 Jun 2014 06:07:31 +1000
Andrew McGlashan 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, then there is no way for anybody t
On 3/06/2014 5:24 AM, Bzzz wrote:
> On Tue, 03 Jun 2014 05:16:21 +1000
> Andrew McGlashan 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?
The problem with that
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 randomnes
On Mon, 02 Jun 2014 15:25:57 -0400
ken 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 home. On second though
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 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 syst
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 comm
On Tue, 03 Jun 2014 05:16:21 +1000
Andrew McGlashan 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 pour travailler, la preuve c'est que cela
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
dr
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.
>
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
wi
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,
39 matches
Mail list logo
