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.
Syts
-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
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, 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 pr
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 machine
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 nothin
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 r
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 p
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 o
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 th
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.
http://off.
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 (al
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 gatew
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
t
-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 academ
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 bac
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, whethe
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 ke
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 backdoo
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 a
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 bac
28 matches
Mail list logo
