ALeine wrote:
Algebraic attacks on AES show that AES may indeed be broken sooner than
we would hope, at least according to the information at:
http://www.cryptosystem.net/aes/
Please stop referring to this website.
Sorry, but everybody in the field of cryptology, except Nicolas
Courtois, agree
In message [EMAIL PROTECTED], ALeine writes:
I find using a single key for the whole disk less secure and not
very practical when one wants to change the key because it takes
a very long time to re-encrypt the entire disk. However, having
a separate per-sector key which is changed on every write
[EMAIL PROTECTED] wrote:
This does not work. The problem is that in GBDE for sector n
which is written, there are two operations:
1. change the key by which sector n is encrypted, and
2. write sector n ecnrypted with the new key.
If one of these fails, how could the
On 1109628121 seconds since the Beginning of the UNIX epoch
ALeine wrote:
Yes, the data sector is written first and then the key sector.
Since, as you pointed out, GBDE is more susceptible to dictionary
attacks than CGD one can then use this advantage (it's a feature,
not a design flaw!) to
[EMAIL PROTECTED] wrote:
You would need to maintain some sort of journal. With CGD, I
specifically avoided any strategy which tied the write of one
sector to the write of another sector for this reason. And so,
I use one key to encrypt the disk rather than storing randomly
generated keys
[EMAIL PROTECTED] wrote:
I confess that I still don't see the threat model here. What
sort of cryptanalytic breakthrough would make this a requirement?
I will state categorically that I know of no threat to AES that
would be addressed by this, but wouldn't require replacing AES entirely.
On 1109641515 seconds since the Beginning of the UNIX epoch
ALeine wrote:
And, GBDE is obviously already less secure than a simpler
approach such as CGD with AES-256 (which is around twice as fast).
I believe it is not less secure because eventhough it might require
less steps to brute force
On 1109715311 seconds since the Beginning of the UNIX epoch
Steven M. Bellovin wrote:
It's worth noting that there is a very real threat not addressed here:
detecting unauthorized changes to an encrypted disk. For a very
elegant solution, see
On 1109549715 seconds since the Beginning of the UNIX epoch
Maxim Sobolev wrote:
Well, I think that this is quite minor item, since GBDE doesn't govern
transformation of the passphrase into the actual key, so that another
scheme more bullet-prof against dictionary attacks (PKCS#5 or any other)
On Monday 28 February 2005 00:15, Maxim Sobolev wrote:
Roland Dowdeswell wrote:
[ cc'ing [EMAIL PROTECTED], because there has been talk
of GBDE there in the past.]
So what? If the write fails in the middle, reading sector will just
produce garbage. I don't think that it's different from
On 1109635700 seconds since the Beginning of the UNIX epoch
Thomas Sparrevohn wrote:
I could be wrong but I would assume that if it is correctly handled within
softupdates there should be no need for journalling - e.g. If both
transactions are not completed the writes are ignored
This does
[EMAIL PROTECTED] wrote:
[ cc'ing [EMAIL PROTECTED], because there has been talk
of GBDE there in the past.]
Well, I thought that since I saw this:
ALeine wrote a while ago:
[EMAIL PROTECTED] wrote:
Wouldn't be easier porting cgd* from NetBSD ?
*
The problem with NCryptFS is that so far no code has been released and
since it looks like it might get released a day after Duke Nuke 'em
Forever I thought I would see what I can do about backporting GDBE
to the 4.x branch. :-/
What about porting NetBSD's cgd(4) [1] driver ? It *might* be
[EMAIL PROTECTED] wrote:
What about porting NetBSD's cgd(4) [1] driver ? It *might* be
easier to port since it does not require GEOM.
Thanks for the suggestion, but IMHO GBDE is superior to CGD, as I have
already explained in detail a couple of weeks ago:
[EMAIL PROTECTED] wrote:
The subject of doxygen has come up a few times, and people haven't been
too keen on it:
http://leaf.dragonflybsd.org/mailarchive/kernel/2003-10/msg00197.html
http://leaf.dragonflybsd.org/mailarchive/kernel/2003-10/msg00199.html
I'm assuming you'd have to have the
[EMAIL PROTECTED] wrote:
What you may want to do is create a character device driver that
resembles the md(4)/vn(4) mechanism: it consumes another file or
device, forwards I/O from its own device node to the underlying
device after performing the transformation. If possible, you'd
want to
[EMAIL PROTECTED] wrote:
I guess the interesting question is why to do this?
Thank you for your very thorough and insightful reply. :-) I've
already discussed my reasons in detail with Matt Dillon, you can
read our exchange at:
[EMAIL PROTECTED] wrote:
This may not be exactly what you are looking for, but I think it
may be important to look at it at least :
http://www.filesystems.org/
The project is named FiST and it uses stackable layers so you
can, for example, encrypt file content.
Thanks, I'm
I would hereby like to politely request your comments on backporting
GEOM to the 4.x branch. I personally would like to see GEOM backported
to the 4.x branch and I would appreciate it if all the developers
(especially Mr. Poul-Henning Kamp) who are familiar with the inner
workings of GEOM could
On Wed, 2 Feb 2005, ALeine wrote:
I would hereby like to politely request your comments on backporting
GEOM to the 4.x branch. I personally would like to see GEOM backported
to the 4.x branch and I would appreciate it if all the developers
(especially Mr. Poul-Henning Kamp) who are familiar
On Thu, 3 Feb 2005, ALeine wrote:
[EMAIL PROTECTED] wrote:
I guess the interesting question is why to do this?
...
Basically, it seems like I should save myself a lot of trouble and just
deGEOMify GBDE so it can be integrated into FreeBSD 4.x and DragonFly
BSD. I can live without GEOM
Geom requires DEVFS and requires that you DON'T have a static /dev.
ALeine wrote:
I would hereby like to politely request your comments on backporting
GEOM to the 4.x branch. I personally would like to see GEOM backported
to the 4.x branch and I would appreciate it if all the developers
Basically, it seems like I should save myself a lot of trouble and just
deGEOMify GBDE so it can be integrated into FreeBSD 4.x and DragonFly
BSD. I can live without GEOM GATE, but GBDE (or dGDE as it will probably
be called once I'm done botching it :-) is something I really really
need
23 matches
Mail list logo
