On Mon, Jan 17, 2005 at 08:14:58PM +0100, Fruhwirth Clemens wrote:
> http://clemens.endorphin.org/LinuxHDEncSettings
I found two typos on your page:
- In LinuxHDEncSettings: at the beginning, 'pose a thread', should be 'threat'
- In 'cryptography': AFsplitter written as AFspliter.
On Mon, Jan 17, 2005 at 08:14:58PM +0100, Fruhwirth Clemens wrote:
http://clemens.endorphin.org/LinuxHDEncSettings
I found two typos on your page:
- In LinuxHDEncSettings: at the beginning, 'pose a thread', should be 'threat'
- In 'cryptography': AFsplitter written as AFspliter.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-01-17 at 22:26 +0100, markus reichelt wrote:
>
> > Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> > > This is FUD. To get serious in-depth information about the problems
> > > associated
On Wed, 19 Jan 2005, Fruhwirth Clemens wrote:
> On Wed, 2005-01-19 at 12:03 -0500, Bill Davidsen wrote:
> > On Tue, 18 Jan 2005, Dan Hollis wrote:
> >
> > > On Tue, 18 Jan 2005, Venkat Manakkal wrote:
> > > > As for cryptoloop, I'm sorry, I cannot say the same. The password
> > > > hashing
> >
On Wed, 19 Jan 2005, Fruhwirth Clemens wrote:
On Wed, 2005-01-19 at 12:03 -0500, Bill Davidsen wrote:
On Tue, 18 Jan 2005, Dan Hollis wrote:
On Tue, 18 Jan 2005, Venkat Manakkal wrote:
As for cryptoloop, I'm sorry, I cannot say the same. The password
hashing
system being
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
On Mon, 2005-01-17 at 22:26 +0100, markus reichelt wrote:
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
This is FUD. To get serious in-depth information about the problems
associated with dm-crypt and
On Wed, 2005-01-19 at 16:24 -0500, James Morris wrote:
> On Wed, 19 Jan 2005, Fruhwirth Clemens wrote:
>
> > I've rewritten some CBC code to fit the facilities I introduce in my LRW
> > patch[1]. Here are the results for my [EMAIL PROTECTED]:
> >
> > loop-aes, CBC: ~30.5mb/s
> > dm-crypt, CBC
On Wed, 19 Jan 2005, Fruhwirth Clemens wrote:
> I've rewritten some CBC code to fit the facilities I introduce in my LRW
> patch[1]. Here are the results for my [EMAIL PROTECTED]:
>
> loop-aes, CBC: ~30.5mb/s
> dm-crypt, CBC prior to my rewrite: ~23mb/s
> dm-crypt, CBC with my LRW patch: ~27mb/s
On Wed, 2005-01-19 at 12:03 -0500, Bill Davidsen wrote:
> On Tue, 18 Jan 2005, Dan Hollis wrote:
>
> > On Tue, 18 Jan 2005, Venkat Manakkal wrote:
> > > As for cryptoloop, I'm sorry, I cannot say the same. The password hashing
> > > system being changed in the past year, poor stability and
On Tue, 18 Jan 2005, Dan Hollis wrote:
> On Tue, 18 Jan 2005, Venkat Manakkal wrote:
> > As for cryptoloop, I'm sorry, I cannot say the same. The password hashing
> > system being changed in the past year, poor stability and machine lockups
> > are
> > what I have noticed, besides there is
On Tue, 18 Jan 2005, Dan Hollis wrote:
On Tue, 18 Jan 2005, Venkat Manakkal wrote:
As for cryptoloop, I'm sorry, I cannot say the same. The password hashing
system being changed in the past year, poor stability and machine lockups
are
what I have noticed, besides there is nothing like
On Wed, 2005-01-19 at 12:03 -0500, Bill Davidsen wrote:
On Tue, 18 Jan 2005, Dan Hollis wrote:
On Tue, 18 Jan 2005, Venkat Manakkal wrote:
As for cryptoloop, I'm sorry, I cannot say the same. The password hashing
system being changed in the past year, poor stability and machine lockups
On Wed, 19 Jan 2005, Fruhwirth Clemens wrote:
I've rewritten some CBC code to fit the facilities I introduce in my LRW
patch[1]. Here are the results for my [EMAIL PROTECTED]:
loop-aes, CBC: ~30.5mb/s
dm-crypt, CBC prior to my rewrite: ~23mb/s
dm-crypt, CBC with my LRW patch: ~27mb/s
On Wed, 2005-01-19 at 16:24 -0500, James Morris wrote:
On Wed, 19 Jan 2005, Fruhwirth Clemens wrote:
I've rewritten some CBC code to fit the facilities I introduce in my LRW
patch[1]. Here are the results for my [EMAIL PROTECTED]:
loop-aes, CBC: ~30.5mb/s
dm-crypt, CBC prior to my
On Jan 18, 2005, at 19:18, Dan Hollis wrote:
On Tue, 18 Jan 2005, Venkat Manakkal wrote:
As for cryptoloop, I'm sorry, I cannot say the same. The password
hashing
system being changed in the past year, poor stability and machine
lockups are
what I have noticed, besides there is nothing like the
On Tue, 18 Jan 2005, Venkat Manakkal wrote:
> As for cryptoloop, I'm sorry, I cannot say the same. The password hashing
> system being changed in the past year, poor stability and machine lockups are
> what I have noticed, besides there is nothing like the readme here:
cryptoloop is also unusably
http://clemens.endorphin.org/LinuxHDEncSettings
Did you ever take a look at that page?!
I did. I´d say the best are the photos. The rest isn
´t much of a help.
Ever since I grabbed me SuSE Linux 8.2 and managed to
compile some standard kernel according to the
loop-aes.readme it´s proven
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Andries et all,
As a loop-aes *user* and ex-cryptoloop user, I can tell you one thing - it
works, and is stable over multiple kernels, and backwards compatibility is
maintained as it evolves.
As for cryptoloop, I'm sorry, I cannot say the same. The
On Tue, Jan 18, 2005 at 05:35:48PM +0200, Jari Ruusu wrote:
> Fruhwirth Clemens wrote:
> > Nothing about kernel crypto is backdoored. If Ruusu thinks different, he
> > should show me source code. Till then, treat it as FUD.
>
> I have been submitting fix for this weakness to mainline mount (part
jerome etienne wrote:
> 3 years ago i published a paper describing how an attacker would be able
> to modify the content of the encrypted device without being detected.
> http://off.net/~jme/loopdev_vul.html
>
> i was just curious about the current state of loop-aes. Is it still
> vulnerable to
Fruhwirth Clemens wrote:
> Nothing about kernel crypto is backdoored. If Ruusu thinks different, he
> should show me source code. Till then, treat it as FUD.
I have been submitting fix for this weakness to mainline mount (part of
util-linux package) since 2001, about 2 or 3 times a year. Refusing
Hello,
i dont understand the current argument so would prefere not to enter it.
But it triggered my curiosity about current loop-aes security.
3 years ago i published a paper describing how an attacker would be able
to modify the content of the encrypted device without being detected.
Hello,
i dont understand the current argument so would prefere not to enter it.
But it triggered my curiosity about current loop-aes security.
3 years ago i published a paper describing how an attacker would be able
to modify the content of the encrypted device without being detected.
Fruhwirth Clemens wrote:
Nothing about kernel crypto is backdoored. If Ruusu thinks different, he
should show me source code. Till then, treat it as FUD.
I have been submitting fix for this weakness to mainline mount (part of
util-linux package) since 2001, about 2 or 3 times a year. Refusing
jerome etienne wrote:
3 years ago i published a paper describing how an attacker would be able
to modify the content of the encrypted device without being detected.
http://off.net/~jme/loopdev_vul.html
i was just curious about the current state of loop-aes. Is it still
vulnerable to this
On Tue, Jan 18, 2005 at 05:35:48PM +0200, Jari Ruusu wrote:
Fruhwirth Clemens wrote:
Nothing about kernel crypto is backdoored. If Ruusu thinks different, he
should show me source code. Till then, treat it as FUD.
I have been submitting fix for this weakness to mainline mount (part of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Andries et all,
As a loop-aes *user* and ex-cryptoloop user, I can tell you one thing - it
works, and is stable over multiple kernels, and backwards compatibility is
maintained as it evolves.
As for cryptoloop, I'm sorry, I cannot say the same. The
http://clemens.endorphin.org/LinuxHDEncSettings
Did you ever take a look at that page?!
I did. I´d say the best are the photos. The rest isn
´t much of a help.
Ever since I grabbed me SuSE Linux 8.2 and managed to
compile some standard kernel according to the
loop-aes.readme it´s proven
On Tue, 18 Jan 2005, Venkat Manakkal wrote:
As for cryptoloop, I'm sorry, I cannot say the same. The password hashing
system being changed in the past year, poor stability and machine lockups are
what I have noticed, besides there is nothing like the readme here:
cryptoloop is also unusably
On Jan 18, 2005, at 19:18, Dan Hollis wrote:
On Tue, 18 Jan 2005, Venkat Manakkal wrote:
As for cryptoloop, I'm sorry, I cannot say the same. The password
hashing
system being changed in the past year, poor stability and machine
lockups are
what I have noticed, besides there is nothing like the
Hi Fruhwirth,
I don't want to take 'emotional' sides in this debate, but an
observation:
Re: "Enlightenment is a gift everyone has to fight for on it's own." If
I can contrast, Jari's code gets some good use/discussion because if a
question is raised, it gets answered *in detail* the same day
On Mon, 2005-01-17 at 22:26 +0100, markus reichelt wrote:
> Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> > This is FUD. To get serious in-depth information about the problems
> > associated with dm-crypt and loop-aes read,
> >
> > http://clemens.endorphin.org/LinuxHDEncSettings
>
> excuse me,
On Mon, Jan 17, 2005 at 05:08:04PM +0200, Jari Ruusu wrote:
> Unlikely to go to mainline kernel. Mainline folks are just too much in
> love with their backdoored device crypto implementations [1]. If you want
"Backdoored" is a bit strong, I think; that tends to imply deliberate
placing of a
On Mon, Jan 17, 2005 at 10:04:49PM +0100, Fruhwirth Clemens wrote:
> You will find the same information on my site. Therefore, I do NOT decline
> this vulnerability. I decline it's security implications. It's on the same
I'm making no comment either way, I simply wanted to make sure everyone on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> This is FUD. To get serious in-depth information about the problems
> associated with dm-crypt and loop-aes read,
>
> http://clemens.endorphin.org/LinuxHDEncSettings
excuse me, but that's just too
On Mon, 2005-01-17 at 19:29 +, Paul Walker wrote:
> On Mon, Jan 17, 2005 at 08:14:58PM +0100, Fruhwirth Clemens wrote:
>
> > > Unlikely to go to mainline kernel. Mainline folks are just too much in
> > > love
> > > with their backdoored device crypto implementations [1].
>
> Just to add
On Mon, 17 Jan 2005 15:11:18 +, Jari Ruusu wrote:
> Mainline folks are just too much in love with their backdoored device
> crypto implementations [1]. If you want strong device crypto in mainline
> kernel, maybe you should take a look at FreeBSD gbde.
what about dm-crypt? I lost track,
On Mon, Jan 17, 2005 at 08:14:58PM +0100, Fruhwirth Clemens wrote:
> > Unlikely to go to mainline kernel. Mainline folks are just too much in love
> > with their backdoored device crypto implementations [1].
Just to add back in Jari's link, so the folks added know what you're talking
about:
>
On Mon, 2005-01-17 at 17:08 +0200, Jari Ruusu wrote:
> Bill Davidsen wrote:
> > Is this eventually going in the mainline kernel? I'd like to use it, but
> > if I'm going to have to maintain my own crypto kernels indefinitely this
> > probably isn't the one for me.
>
> Unlikely to go to mainline
Bill Davidsen wrote:
> Is this eventually going in the mainline kernel? I'd like to use it, but
> if I'm going to have to maintain my own crypto kernels indefinitely this
> probably isn't the one for me.
Unlikely to go to mainline kernel. Mainline folks are just too much in love
with their
Bill Davidsen wrote:
Is this eventually going in the mainline kernel? I'd like to use it, but
if I'm going to have to maintain my own crypto kernels indefinitely this
probably isn't the one for me.
Unlikely to go to mainline kernel. Mainline folks are just too much in love
with their
On Mon, 2005-01-17 at 17:08 +0200, Jari Ruusu wrote:
Bill Davidsen wrote:
Is this eventually going in the mainline kernel? I'd like to use it, but
if I'm going to have to maintain my own crypto kernels indefinitely this
probably isn't the one for me.
Unlikely to go to mainline kernel.
On Mon, Jan 17, 2005 at 08:14:58PM +0100, Fruhwirth Clemens wrote:
Unlikely to go to mainline kernel. Mainline folks are just too much in love
with their backdoored device crypto implementations [1].
Just to add back in Jari's link, so the folks added know what you're talking
about:
[1]
On Mon, 17 Jan 2005 15:11:18 +, Jari Ruusu wrote:
Mainline folks are just too much in love with their backdoored device
crypto implementations [1]. If you want strong device crypto in mainline
kernel, maybe you should take a look at FreeBSD gbde.
what about dm-crypt? I lost track, whether
On Mon, 2005-01-17 at 19:29 +, Paul Walker wrote:
On Mon, Jan 17, 2005 at 08:14:58PM +0100, Fruhwirth Clemens wrote:
Unlikely to go to mainline kernel. Mainline folks are just too much in
love
with their backdoored device crypto implementations [1].
Just to add back in Jari's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
This is FUD. To get serious in-depth information about the problems
associated with dm-crypt and loop-aes read,
http://clemens.endorphin.org/LinuxHDEncSettings
excuse me, but that's just too academic
On Mon, Jan 17, 2005 at 10:04:49PM +0100, Fruhwirth Clemens wrote:
You will find the same information on my site. Therefore, I do NOT decline
this vulnerability. I decline it's security implications. It's on the same
I'm making no comment either way, I simply wanted to make sure everyone on
On Mon, Jan 17, 2005 at 05:08:04PM +0200, Jari Ruusu wrote:
Unlikely to go to mainline kernel. Mainline folks are just too much in
love with their backdoored device crypto implementations [1]. If you want
Backdoored is a bit strong, I think; that tends to imply deliberate
placing of a gateway
On Mon, 2005-01-17 at 22:26 +0100, markus reichelt wrote:
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
This is FUD. To get serious in-depth information about the problems
associated with dm-crypt and loop-aes read,
http://clemens.endorphin.org/LinuxHDEncSettings
excuse me, but that's
Hi Fruhwirth,
I don't want to take 'emotional' sides in this debate, but an
observation:
Re: Enlightenment is a gift everyone has to fight for on it's own. If
I can contrast, Jari's code gets some good use/discussion because if a
question is raised, it gets answered *in detail* the same day
Hi Bill,
On Sun, Jan 16, 2005 at 11:26:38PM -0500, Bill Davidsen wrote:
> Is this eventually going in the mainline kernel? I'd like to use it, but
> if I'm going to have to maintain my own crypto kernels indefinitely this
> probably isn't the one for me.
On a side note, I would say that this
Jari Ruusu wrote:
loop-AES changes since previous release:
- Fixed externally compiled module version multi-key-v3 ioctl
incompatibility with boxes running 64 bit kernel and 32 bit userland.
Kernel patch versions were not affected (2.4 and 2.6 kernels).
- Fixed bug that made v3 on-disk format
loop-AES changes since previous release:
- Fixed externally compiled module version multi-key-v3 ioctl
incompatibility with boxes running 64 bit kernel and 32 bit userland.
Kernel patch versions were not affected (2.4 and 2.6 kernels).
- Fixed bug that made v3 on-disk format always use file
loop-AES changes since previous release:
- Fixed externally compiled module version multi-key-v3 ioctl
incompatibility with boxes running 64 bit kernel and 32 bit userland.
Kernel patch versions were not affected (2.4 and 2.6 kernels).
- Fixed bug that made v3 on-disk format always use file
Jari Ruusu wrote:
loop-AES changes since previous release:
- Fixed externally compiled module version multi-key-v3 ioctl
incompatibility with boxes running 64 bit kernel and 32 bit userland.
Kernel patch versions were not affected (2.4 and 2.6 kernels).
- Fixed bug that made v3 on-disk format
Hi Bill,
On Sun, Jan 16, 2005 at 11:26:38PM -0500, Bill Davidsen wrote:
Is this eventually going in the mainline kernel? I'd like to use it, but
if I'm going to have to maintain my own crypto kernels indefinitely this
probably isn't the one for me.
On a side note, I would say that this
56 matches
Mail list logo
