If you want an interesting problem to work on, come up with a solution
to
the keying problem for disk encryption. It somehow needs to allow
automated, unattended reboots during normal operations but prevent
attackers from compromising the system. Maybe you could have the
system
send an SMS
On Monday 24 November 2003 10:24 pm, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Stefan
=?iso-8859-1
And that is what this thread is about: Secure removal of data from
storage media. There definitely is a difference between RLL (as in
1,7i RLL) and modern PRML drives under this
In message [EMAIL PROTECTED], Wes Peters writes:
If you want an interesting problem to work on, come up with a solution to
the keying problem for disk encryption. It somehow needs to allow
automated, unattended reboots during normal operations but prevent
attackers from compromising the
On Fri, Nov 28, 2003 at 12:43:30PM +0100, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Wes Peters writes:
If you want an interesting problem to work on, come up with a solution to
the keying problem for disk encryption. It somehow needs to allow
automated, unattended reboots
In message [EMAIL PROTECTED], Wilko Bulte writes:
On Fri, Nov 28, 2003 at 12:43:30PM +0100, Poul-Henning Kamp wrote:
I have already described one solution to this in my GBDE paper at
BSDcon.
...
Now *that* is a DIY project for the dedicated hobbyist :-)
The terminology and principle, is
Wes Peters wrote:
On Tuesday 18 November 2003 16:31, Rayson Ho wrote:
e.g. when deleting a secure file, the OS will overwrite the file
with random data.
Better to overwrite it with a more secure pattern. See ports/
sysutils/obliterate for references. It has been mentioned before that
On 2003-11-23 17:31 +0100, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote:
Stefan Eßer [EMAIL PROTECTED] writes:
What I'm suggesting is to have the obliteration implemented as an
add on to the dirty buffer flush, with the difference that the
buffer contents is prepared for the next step of
On 2003-11-23 18:04 +0100, Poul-Henning Kamp [EMAIL PROTECTED] wrote:
1. Look for BIO_DELETE in the kernel.
Seems that BIO_DELETE isn't really supported anymore
(according to a comment in your GEOM sources ;-)
AFAICT, BIO_DELETE can't easily be made a long running
operation (taking tens of
In message [EMAIL PROTECTED], Stefan =?iso-8859-1
?Q?E=DFer?= writes:
Yes, probably. But encryption is only as good as key
management and secure storage (and deletion) of keys.
How do you implement unattended reboot, if you consider
unauthorized (physical) access to your system as one
of the
On 2003-11-23 10:11 -0800, Wes Peters [EMAIL PROTECTED] wrote:
Encrypting data and secure removal of data are orthogonal and in case
you need one, the other propbably won't be a good choice.
Both are completely adequate to protect the data on the disk from
disclosure.
Yes, if effective.
Stefan Eßer [EMAIL PROTECTED] writes:
Ok. I've also thought some about this, and I think that different media
might need different methods (i.e. MFM vs. RLL vs. PRML, but also vs.
Flash media).
PRML is not an encoding scheme like MFM or RLL, it is an algorithm for
recovering a bitstream from
On 2003-11-24 12:20 +0100, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote:
Stefan Eßer [EMAIL PROTECTED] writes:
Ok. I've also thought some about this, and I think that different media
might need different methods (i.e. MFM vs. RLL vs. PRML, but also vs.
Flash media).
PRML is not an
On Tue, Nov 18, 2003 at 04:31:32PM -0800, Rayson Ho wrote:
I am wondering if it is useful to have a secure file flag??
The secure file flag will be set for files that contain sensitive data.
Then the OS will take special care when operating on those secure
files.
e.g. when deleting
In message [EMAIL PROTECTED], Stefan =?iso-8859-1
And that is what this thread is about: Secure removal of data from
storage media. There definitely is a difference between RLL (as in
1,7i RLL) and modern PRML drives under this aspect.
No there isn't.
It's been proven again and again that you
On Friday 21 November 2003 03:56 pm, Stefan Eßer wrote:
On 2003-11-21 14:09 -0800, Wes Peters [EMAIL PROTECTED] wrote:
As for performance, you really need to flush the on-device cache on
each pass to make sure the bit patterns get written to the platter in
proper order. I don't see any
On Saturday 22 November 2003 02:54 am, Stefan Eßer wrote:
On 2003-11-22 11:04 +0100, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote:
Stefan Eßer [EMAIL PROTECTED] writes:
I may be way off, but I do not think, that a special thread or
a cache flush after each block is required: [...]
What
On 2003-11-23 00:16 -0800, Wes Peters [EMAIL PROTECTED] wrote:
On Friday 21 November 2003 03:56 pm, Stefan Eßer wrote:
A simple algorithm could just mark each buffer with a special
kind of dirty flag and a counter for the pass number (in fact,
the existing dirty flag could be used, and a
On 2003-11-23 00:19 -0800, Wes Peters [EMAIL PROTECTED] wrote:
On Saturday 22 November 2003 02:54 am, Stefan Eßer wrote:
On 2003-11-22 11:04 +0100, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote:
Stefan Eßer [EMAIL PROTECTED] writes:
I may be way off, but I do not think, that a special
Stefan Eßer [EMAIL PROTECTED] writes:
What I'm suggesting is to have the obliteration implemented as an
add on to the dirty buffer flush, with the difference that the
buffer contents is prepared for the next step of the erasure process,
written out, and then not declared free but again
1. Look for BIO_DELETE in the kernel.
2. Use GBDE or other encryption.
3. Stop bikeshed now, please.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
On Sunday 23 November 2003 04:15 am, Stefan Eßer wrote:
On 2003-11-23 00:16 -0800, Wes Peters [EMAIL PROTECTED] wrote:
On Friday 21 November 2003 03:56 pm, Stefan Eßer wrote:
A simple algorithm could just mark each buffer with a special
kind of dirty flag and a counter for the pass number
On Sunday 23 November 2003 04:46 am, Stefan Eßer wrote:
On 2003-11-23 00:19 -0800, Wes Peters [EMAIL PROTECTED] wrote:
On Saturday 22 November 2003 02:54 am, Stefan Eßer wrote:
On 2003-11-22 11:04 +0100, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote:
Stefan Eßer [EMAIL PROTECTED] writes:
Stefan Eßer [EMAIL PROTECTED] writes:
I may be way off, but I do not think, that a special thread or
a cache flush after each block is required: [...]
What happens if you yank the power cord?
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
On 2003-11-22 11:04 +0100, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote:
Stefan Eßer [EMAIL PROTECTED] writes:
I may be way off, but I do not think, that a special thread or
a cache flush after each block is required: [...]
What happens if you yank the power cord?
Worst case: The same
On Thu, Nov 20, 2003 at 01:27:29PM -0800, Wes Peters wrote:
+ On Tuesday 18 November 2003 16:31, Rayson Ho wrote:
+ I am wondering if it is useful to have a secure file flag??
+
+ The secure file flag will be set for files that contain sensitive
+ data. Then the OS will take special care when
On Fri, Nov 21, 2003 at 10:59:40AM +0100, Pawel Jakub Dawidek wrote:
Such secure flag for running process could be also implemented with
multiple meanings:
Is the secure flag intended to protect the process image from the invoking
user as well as other users?
1. All freed pages have to be
Pawel Jakub Dawidek [EMAIL PROTECTED] writes:
If this operation is able to fail (and of course it is) it should block
on unlink(2).
FreeBSD is not DOS; unlink(2) does not actually remove the file. It
is removed by the filesystem if the link count is zero when the vnode
is released, which may
On Fri, Nov 21, 2003 at 12:41:05PM +0100, Dag-Erling Sm?rgrav wrote:
+ If this operation is able to fail (and of course it is) it should block
+ on unlink(2).
+
+ FreeBSD is not DOS; unlink(2) does not actually remove the file. It
+ is removed by the filesystem if the link count is zero when
Pawel Jakub Dawidek [EMAIL PROTECTED] writes:
I'm aware of this, but what we want to think over here is something like
in-kernel 'rm -P'. So file will be overwriten even if it is opened
and/or link count is grater than 0.
That is not acceptable. First of all, it breaks a lot of assumptions
in
On Friday 21 November 2003 05:30, Dag-Erling Smørgrav wrote:
Pawel Jakub Dawidek [EMAIL PROTECTED] writes:
I'm aware of this, but what we want to think over here is something
like in-kernel 'rm -P'. So file will be overwriten even if it is
opened and/or link count is grater than 0.
That
On 2003-11-21 14:09 -0800, Wes Peters [EMAIL PROTECTED] wrote:
As for performance, you really need to flush the on-device cache on each
pass to make sure the bit patterns get written to the platter in proper
order. I don't see any clever way to coalesce the writing of the
various patterns
On Tuesday 18 November 2003 16:31, Rayson Ho wrote:
I am wondering if it is useful to have a secure file flag??
The secure file flag will be set for files that contain sensitive
data. Then the OS will take special care when operating on those
secure files.
e.g. when deleting a secure file
I am wondering if it is useful to have a secure file flag??
The secure file flag will be set for files that contain sensitive data.
Then the OS will take special care when operating on those secure
files.
e.g. when deleting a secure file, the OS will overwrite the file with
random data.
One
On Tue, Nov 18, 2003 at 04:31:32PM -0800, Rayson Ho wrote:
I am wondering if it is useful to have a secure file flag??
...
e.g. when deleting a secure file, the OS will overwrite the file with
random data.
I've got patches somewhere for zeroing out memory mappings in this way
34 matches
Mail list logo
