On Tue, 26 Feb 2008, Achim Patzner wrote:
You might want to take a look at eNova (http://www.enovatech.net/) who
are pointing at interesting hardware using their crypto technology.
=
the idea of closed-source hardware-based crypto disk drive may appeal to
some, but i've seen t
On Tue, 26 Feb 2008 22:49:37 +0300
Eygene Ryabinkin <[EMAIL PROTECTED]> wrote:
> Yes, Geoff just responded to my private question: it was Peter
> Gutmann, who pointed him to the thing you're talking about. There
> is a paper by Peter,
>
> http://www.usenix.org/publications/library/proceedings
On Tue, 26 Feb 2008 21:28:53 +0100 Joerg Sonnenberger <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 26, 2008 at 07:44:48PM +0100, Martin Laabs wrote:
> > I also made a comparison between gzip and bzip2 regarding
> > the compression ratio on a dump of my home directory (3.2GB)
> > bzip2 took about 74min
On Tue, Feb 26, 2008 at 07:44:48PM +0100, Martin Laabs wrote:
> I also made a comparison between gzip and bzip2 regarding
> the compression ratio on a dump of my home directory (3.2GB)
> bzip2 took about 74min to compress, gzip only 11minutes. And
> in terms of compression ratio bzip2 was only 3% b
On 20080226 15:17:24, Tom Evans wrote:
> Running something like 'jexec 1 /bin/sh' won't allow you to allocate a
> tty. If instead you enable sshd inside the jail, and ssh into the jail,
> sshd will allocate you a tty, and everything will work normally.
Hi.
As I mentione
Gregory, good day.
Tue, Feb 26, 2008 at 07:42:17PM +0100, [EMAIL PROTECTED] wrote:
> Quoting Eygene Ryabinkin <[EMAIL PROTECTED]>:
>
> > *) New function OPENSSL_cleanse(), which is used to cleanse a section of
> >memory from it's contents. This is done with a counter that will
> >place a
Pav Lucistnik píše v út 05. 02. 2008 v 19:16 +0100:
> Andriy Gapon píše v út 05. 02. 2008 v 16:40 +0200:
>
> > > Yay, and can you fix the sequential read performance while you're at it?
> > > Kthx!
>
> > this was almost trivial :-)
> > See the attached patch, first hunk is just for consistency.
>
Quoting Eygene Ryabinkin <[EMAIL PROTECTED]>:
> *) New function OPENSSL_cleanse(), which is used to cleanse a section of
>memory from it's contents. This is done with a counter that will
>place alternating values in each byte. This can be used to solve
>two issues: 1) the removal of
Hi,
Maybe someone could implement a memory section
that is overwritten by the bios after reboot.
Then all the sensitive keys could be stored there.
This would prevent an attack that just boots from
another media and dump the whole memory out of i.e.
an USB-stick.
Preventing the physical access
Hi,
On Tue, 26 Feb 2008 08:51:02 +0100, Peter Jeremy
<[EMAIL PROTECTED]> wrote:
[...] But it also has some gotchas. The
biggest one is that dump needs to be able to write past EOM (so it can
record an end-of-volume block).
Just even I tried the following:
-create a 50MB filesystem (with md)
Hi,
I'm not sure wheher Martin is trying to create a dump that is a single
logical volume split over multiple physical volumes or a multi-volume
dump.
I want to make a real multi-volume dump over multiple media. Because
if I had only one big volume I'd - in the worst case - have to insert
all
Hi,
Yes, gzip or bzip2 compress better, but they also:
* Are a lot slower.
Yesterday I made a comparison regarding the speed
of compress, bzip2 and gzip.
And actually compress is much slower than gzip:
$ dd if=/dev/random |compress -c > /dev/null
3883204 bytes/sec
$ dd if=/dev/random |gzip
On Sun, 2008-02-24 at 19:42 +0100, cali clarke wrote:
> Hi.
>
> pdksh and derivatives (openbsd ksh, mirbsd mksh etc) all have
> the same "bug" with regards to jails. On all of my systems, trying
> to start *ksh in a jail results in a message that /dev/tty could
> not be opened (device busy) and th
On Sat, Feb 23, 2008 at 02:08:54PM +1300, Atom Smasher wrote:
> article below. does anyone know how this affects eli/geli?
>
> from the geli man page: "detach - Detach the given providers, which means
> remove the devfs entry and clear the keys from memory." does that mean
> that geli properly w
Am 26.02.2008 um 12:45 schrieb Uwe Doering:
You might want to take a look at eNova (http://www.enovatech.net/)
who are pointing at interesting hardware using their crypto
technology.
Interesting approach as well. Thanks for the pointer. However,
given that notebooks are the most vulnerabl
Tim Kientzle wrote:
Why compress? It's ancient technology and will be vastly outperformed
Yes, gzip or bzip2 compress better, but they also:
* Are a lot slower.
* Use a lot more data memory.
* Require a lot more code.
I don't understand what "a lot more code" has to do with anything.
Am 25.02.2008 um 23:48 schrieb Uwe Doering:
Since it hasn't been mentioned so far: There are hard disk drives
that do encryption on the firmware level, so you don't have to store
keys on the OS level.
I wouldn't go that far as there isn't (better: I didn't find)
enough documentation on thei
Achim Patzner wrote:
Am 25.02.2008 um 23:48 schrieb Uwe Doering:
Since it hasn't been mentioned so far: There are hard disk drives that
do encryption on the firmware level, so you don't have to store keys
on the OS level.
I wouldn't go that far as there isn't (better: I didn't find)
enough do
18 matches
Mail list logo
