On Fri, Apr 15, 2005 at 11:44:06AM +0200, Andreas Steinmetz wrote:
> Matt Mackall wrote:
> > Zero only the mlocked regions. This should take essentially no time at
> > all. Swsusp knows which these are because they have to be mlocked
> > after resume as well. If it's not mlocked, it's liable to be
Pavel Machek wrote:
> Andreas, do you think you could write nice, long, FAQ entries so that
> we don't have to go through this discussion over and over?
I can do so over the weekend. Am I right that you mean the FAQ section
of Documentation/power/swsusp.txt?
BTW: would it make sense to reset the
Hi!
> > Andreas, do you think you could write nice, long, FAQ entries so that
> > we don't have to go through this discussion over and over?
>
> I can do so over the weekend. Am I right that you mean the FAQ section
> of Documentation/power/swsusp.txt?
Yes.
> BTW: would it make sense to reset
Matt Mackall wrote:
> A much more likely vector is stealing the laptop while it's suspended.
> And the encrypted swsusp patch has -zero- security here: it writes the
> key in the header in the clear. It's rather odd that everyone's hung
> up on the "box rooted after resume" attack and completely
Matt Mackall wrote:
> Zero only the mlocked regions. This should take essentially no time at
> all. Swsusp knows which these are because they have to be mlocked
> after resume as well. If it's not mlocked, it's liable to be swapped
> out anyway.
Nitpicking:
What happens if the disk decides to
Matt Mackall wrote:
Zero only the mlocked regions. This should take essentially no time at
all. Swsusp knows which these are because they have to be mlocked
after resume as well. If it's not mlocked, it's liable to be swapped
out anyway.
Nitpicking:
What happens if the disk decides to
Matt Mackall wrote:
A much more likely vector is stealing the laptop while it's suspended.
And the encrypted swsusp patch has -zero- security here: it writes the
key in the header in the clear. It's rather odd that everyone's hung
up on the box rooted after resume attack and completely
Pavel Machek wrote:
Andreas, do you think you could write nice, long, FAQ entries so that
we don't have to go through this discussion over and over?
I can do so over the weekend. Am I right that you mean the FAQ section
of Documentation/power/swsusp.txt?
BTW: would it make sense to reset the
Hi!
Andreas, do you think you could write nice, long, FAQ entries so that
we don't have to go through this discussion over and over?
I can do so over the weekend. Am I right that you mean the FAQ section
of Documentation/power/swsusp.txt?
Yes.
BTW: would it make sense to reset the
On Fri, Apr 15, 2005 at 11:44:06AM +0200, Andreas Steinmetz wrote:
Matt Mackall wrote:
Zero only the mlocked regions. This should take essentially no time at
all. Swsusp knows which these are because they have to be mlocked
after resume as well. If it's not mlocked, it's liable to be
On Thu, Apr 14, 2005 at 03:11:53PM -0700, Andy Isaacson wrote:
> On Thu, Apr 14, 2005 at 12:53:52PM -0700, Matt Mackall wrote:
> > On Thu, Apr 14, 2005 at 09:27:22PM +0200, Stefan Seyfried wrote:
> > > Matt Mackall wrote:
> > > > Any sensible solution here is going to require remembering
On Thu, Apr 14, 2005 at 10:18:12PM +0200, Pavel Machek wrote:
> Hi!
>
> > > So we would need to zero out the suspend image in swap to prevent the
> > > retrieval of this data from the running machine (imagine a
> > > remote-root-hole).
> > >
> > > Zeroing out the suspend image means "write lots
On Thu, Apr 14, 2005 at 12:53:52PM -0700, Matt Mackall wrote:
> On Thu, Apr 14, 2005 at 09:27:22PM +0200, Stefan Seyfried wrote:
> > Matt Mackall wrote:
> > > Any sensible solution here is going to require remembering passwords.
> > > And arguably anywhere the user needs encrypted suspend, they'll
Hi!
> > So we would need to zero out the suspend image in swap to prevent the
> > retrieval of this data from the running machine (imagine a
> > remote-root-hole).
> >
> > Zeroing out the suspend image means "write lots of megabytes to the
> > disk" which takes a lot of time.
>
> Zero only the
Hi!
> > Arguably, using dm-crypt is more secure, but it is also more
> > complicated from the Joe User POV. IMHO we should not force users to
> > set up dm-crypt, remember passwords etc., to get some basic
> > security.
>
> Any sensible solution here is going to require remembering passwords.
On Thu, Apr 14, 2005 at 09:27:22PM +0200, Stefan Seyfried wrote:
> Matt Mackall wrote:
>
> > Any sensible solution here is going to require remembering passwords.
> > And arguably anywhere the user needs encrypted suspend, they'll want
> > encrypted swap as well.
>
> But after entering the
Matt Mackall wrote:
> Any sensible solution here is going to require remembering passwords.
> And arguably anywhere the user needs encrypted suspend, they'll want
> encrypted swap as well.
But after entering the password and resuming, the encrypted swap is
accessible again and my ssh-key may be
On Thu, Apr 14, 2005 at 11:04:39AM +0200, Rafael J. Wysocki wrote:
> Hi,
>
> On Thursday, 14 of April 2005 10:08, Herbert Xu wrote:
> > On Thu, Apr 14, 2005 at 08:51:25AM +0200, Pavel Machek wrote:
> > >
> > > > This solution is all wrong.
> > > >
> > > > If you want security of the suspend
Andy Isaacson <[EMAIL PROTECTED]> wrote:
> * the key is automatically regenerated every 2 hours (or whatever); as
>pages encrypted under the old key age out, it can be freed eventually
Changing the key would not help, since if you can get the swap pages on
a running system, you can also get
On Ät 14-04-05 18:08:37, Herbert Xu wrote:
> On Thu, Apr 14, 2005 at 08:51:25AM +0200, Pavel Machek wrote:
> >
> > > This solution is all wrong.
> > >
> > > If you want security of the suspend image while "suspended", encrypt
> > > with dm-crypt. If you want security of the swap image after
Hi,
On Thursday, 14 of April 2005 10:08, Herbert Xu wrote:
> On Thu, Apr 14, 2005 at 08:51:25AM +0200, Pavel Machek wrote:
> >
> > > This solution is all wrong.
> > >
> > > If you want security of the suspend image while "suspended", encrypt
> > > with dm-crypt. If you want security of the swap
>
> > * the key is automatically regenerated every 2 hours (or whatever); as
> >pages encrypted under the old key age out, it can be freed eventually
>
> This'll require changes to dmcrypt but it's doable.
but it's not useful since linux actually generally keeps the pages also
in swap
On Thu, Apr 14, 2005 at 01:31:19AM -0700, Andy Isaacson wrote:
>
> Does dmcrypt have a simple operation mode like OpenBSD's encrypted swap?
> I want to be able to 'sysctl -w kernel.swap_crypt=1' and get
It's not that easy however the distros can make it so that it's as
simple as running one
On Thu, Apr 14, 2005 at 09:39:04AM +1000, Herbert Xu wrote:
> > Andreas is right. They are encrypted in swap, but they should not be
> > there at all. And they are encrypted by key that is still available
> > after resume. Bad.
>
> The dmcrypt swap can only be unlocked by the user with a
On Ät 14-04-05 03:13:41, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > The dmcrypt swap can only be unlocked by the user with a passphrase,
> > which is analogous to how you unlock your ssh private key stored
> > on the disk using a passphrase.
>
> We talk about the
On Thu, Apr 14, 2005 at 08:51:25AM +0200, Pavel Machek wrote:
>
> > This solution is all wrong.
> >
> > If you want security of the suspend image while "suspended", encrypt
> > with dm-crypt. If you want security of the swap image after resume,
> > zero out the portion of swap used. If you want
Hi!
> > > > > The ssh keys are *encrypted* in the swap when dmcrypt is used.
> > > > > When the swap runs over dmcrypt all writes including those from
> > > > > swsusp are encrypted.
> > > >
> > > > Andreas is right. They are encrypted in swap, but they should not be
> > > > there at all. And
Hi!
The ssh keys are *encrypted* in the swap when dmcrypt is used.
When the swap runs over dmcrypt all writes including those from
swsusp are encrypted.
Andreas is right. They are encrypted in swap, but they should not be
there at all. And they are encrypted by key
On Thu, Apr 14, 2005 at 08:51:25AM +0200, Pavel Machek wrote:
This solution is all wrong.
If you want security of the suspend image while suspended, encrypt
with dm-crypt. If you want security of the swap image after resume,
zero out the portion of swap used. If you want both, do both.
On t 14-04-05 03:13:41, Bernd Eckenfels wrote:
In article [EMAIL PROTECTED] you wrote:
The dmcrypt swap can only be unlocked by the user with a passphrase,
which is analogous to how you unlock your ssh private key stored
on the disk using a passphrase.
We talk about the unlocked system
On Thu, Apr 14, 2005 at 09:39:04AM +1000, Herbert Xu wrote:
Andreas is right. They are encrypted in swap, but they should not be
there at all. And they are encrypted by key that is still available
after resume. Bad.
The dmcrypt swap can only be unlocked by the user with a passphrase,
On Thu, Apr 14, 2005 at 01:31:19AM -0700, Andy Isaacson wrote:
Does dmcrypt have a simple operation mode like OpenBSD's encrypted swap?
I want to be able to 'sysctl -w kernel.swap_crypt=1' and get
It's not that easy however the distros can make it so that it's as
simple as running one command
* the key is automatically regenerated every 2 hours (or whatever); as
pages encrypted under the old key age out, it can be freed eventually
This'll require changes to dmcrypt but it's doable.
but it's not useful since linux actually generally keeps the pages also
in swap even when
Hi,
On Thursday, 14 of April 2005 10:08, Herbert Xu wrote:
On Thu, Apr 14, 2005 at 08:51:25AM +0200, Pavel Machek wrote:
This solution is all wrong.
If you want security of the suspend image while suspended, encrypt
with dm-crypt. If you want security of the swap image after
On t 14-04-05 18:08:37, Herbert Xu wrote:
On Thu, Apr 14, 2005 at 08:51:25AM +0200, Pavel Machek wrote:
This solution is all wrong.
If you want security of the suspend image while suspended, encrypt
with dm-crypt. If you want security of the swap image after resume,
zero out the
Andy Isaacson [EMAIL PROTECTED] wrote:
* the key is automatically regenerated every 2 hours (or whatever); as
pages encrypted under the old key age out, it can be freed eventually
Changing the key would not help, since if you can get the swap pages on
a running system, you can also get the
On Thu, Apr 14, 2005 at 11:04:39AM +0200, Rafael J. Wysocki wrote:
Hi,
On Thursday, 14 of April 2005 10:08, Herbert Xu wrote:
On Thu, Apr 14, 2005 at 08:51:25AM +0200, Pavel Machek wrote:
This solution is all wrong.
If you want security of the suspend image while suspended,
Matt Mackall wrote:
Any sensible solution here is going to require remembering passwords.
And arguably anywhere the user needs encrypted suspend, they'll want
encrypted swap as well.
But after entering the password and resuming, the encrypted swap is
accessible again and my ssh-key may be
On Thu, Apr 14, 2005 at 09:27:22PM +0200, Stefan Seyfried wrote:
Matt Mackall wrote:
Any sensible solution here is going to require remembering passwords.
And arguably anywhere the user needs encrypted suspend, they'll want
encrypted swap as well.
But after entering the password and
Hi!
Arguably, using dm-crypt is more secure, but it is also more
complicated from the Joe User POV. IMHO we should not force users to
set up dm-crypt, remember passwords etc., to get some basic
security.
Any sensible solution here is going to require remembering passwords.
Andreas has
Hi!
So we would need to zero out the suspend image in swap to prevent the
retrieval of this data from the running machine (imagine a
remote-root-hole).
Zeroing out the suspend image means write lots of megabytes to the
disk which takes a lot of time.
Zero only the mlocked regions.
On Thu, Apr 14, 2005 at 12:53:52PM -0700, Matt Mackall wrote:
On Thu, Apr 14, 2005 at 09:27:22PM +0200, Stefan Seyfried wrote:
Matt Mackall wrote:
Any sensible solution here is going to require remembering passwords.
And arguably anywhere the user needs encrypted suspend, they'll want
On Thu, Apr 14, 2005 at 10:18:12PM +0200, Pavel Machek wrote:
Hi!
So we would need to zero out the suspend image in swap to prevent the
retrieval of this data from the running machine (imagine a
remote-root-hole).
Zeroing out the suspend image means write lots of megabytes to the
On Thu, Apr 14, 2005 at 03:11:53PM -0700, Andy Isaacson wrote:
On Thu, Apr 14, 2005 at 12:53:52PM -0700, Matt Mackall wrote:
On Thu, Apr 14, 2005 at 09:27:22PM +0200, Stefan Seyfried wrote:
Matt Mackall wrote:
Any sensible solution here is going to require remembering passwords.
And
In article <[EMAIL PROTECTED]> you wrote:
> The dmcrypt swap can only be unlocked by the user with a passphrase,
> which is analogous to how you unlock your ssh private key stored
> on the disk using a passphrase.
We talk about the unlocked system getting hacked. However I am not why the
hacker
In article <[EMAIL PROTECTED]> you wrote:
> The ssh keys are *encrypted* in the swap when dmcrypt is used.
> When the swap runs over dmcrypt all writes including those from
> swsusp are encrypted.
The problem is that after an resume the running system has access to the
swap, because the key is
On Thu, Apr 14, 2005 at 01:46:02AM +0200, Pavel Machek wrote:
> On ??t 14-04-05 09:39:04, Herbert Xu wrote:
> > On Thu, Apr 14, 2005 at 01:24:31AM +0200, Pavel Machek wrote:
> > >
> > > > The ssh keys are *encrypted* in the swap when dmcrypt is used.
> > > > When the swap runs over dmcrypt all
On Ät 14-04-05 09:39:04, Herbert Xu wrote:
> On Thu, Apr 14, 2005 at 01:24:31AM +0200, Pavel Machek wrote:
> >
> > > The ssh keys are *encrypted* in the swap when dmcrypt is used.
> > > When the swap runs over dmcrypt all writes including those from
> > > swsusp are encrypted.
> >
> > Andreas is
On Thu, Apr 14, 2005 at 01:24:31AM +0200, Pavel Machek wrote:
>
> > The ssh keys are *encrypted* in the swap when dmcrypt is used.
> > When the swap runs over dmcrypt all writes including those from
> > swsusp are encrypted.
>
> Andreas is right. They are encrypted in swap, but they should not be
On Ät 14-04-05 09:10:44, Herbert Xu wrote:
> On Thu, Apr 14, 2005 at 12:29:36AM +0200, Andreas Steinmetz wrote:
> >
> > > Why is that? In the case of swap over dmcrypt, swsusp never reads/writes
> > > the disk directly. All operations are done through dmcrypt.
> > >
> > > The user has to enter a
On Thu, Apr 14, 2005 at 12:29:36AM +0200, Andreas Steinmetz wrote:
>
> > Why is that? In the case of swap over dmcrypt, swsusp never reads/writes
> > the disk directly. All operations are done through dmcrypt.
> >
> > The user has to enter a password before the system can be resumed.
>
> Think
Herbert Xu wrote:
> On Wed, Apr 13, 2005 at 02:59:28PM +0200, Andreas Steinmetz wrote:
>
>>Herbert Xu wrote:
>>
>>>What's wrong with using swap over dmcrypt + initramfs? People have
>>>already used that to do encrypted swsusp.
>>
>>Nothing. The problem is the fact that after resume there is then
On Wed, Apr 13, 2005 at 02:59:28PM +0200, Andreas Steinmetz wrote:
> Herbert Xu wrote:
> > What's wrong with using swap over dmcrypt + initramfs? People have
> > already used that to do encrypted swsusp.
>
> Nothing. The problem is the fact that after resume there is then
> unencrypted(*) data on
Pavel Machek wrote:
> Applied (it is *not* going to make it into 2.6.12, and not sure about
> 2.6.13, but it is in my local tree now. You had Kconfig and docs
> changes, too, can you retransmit them?
> Pavel
No changes to config and
Hi!
> Here comes the next incarnation, this time against 2.6.12rc2.
> Unfortunately only compile tested as 2.6.12rc2 happily oopses away
> (vanilla from kernel.org, oops already sent to lkml).
>
> Please let me know if you want any further changes.
Applied (it is *not* going to make it into
Herbert Xu wrote:
> What's wrong with using swap over dmcrypt + initramfs? People have
> already used that to do encrypted swsusp.
Nothing. The problem is the fact that after resume there is then
unencrypted(*) data on disk that should never have been there, e.g.
dm-crypt keys, ssh keys, ...
This
Andreas Steinmetz <[EMAIL PROTECTED]> wrote:
>
> Here comes the next incarnation, this time against 2.6.12rc2.
> Unfortunately only compile tested as 2.6.12rc2 happily oopses away
> (vanilla from kernel.org, oops already sent to lkml).
>
> Please let me know if you want any further changes.
Andreas Steinmetz [EMAIL PROTECTED] wrote:
Here comes the next incarnation, this time against 2.6.12rc2.
Unfortunately only compile tested as 2.6.12rc2 happily oopses away
(vanilla from kernel.org, oops already sent to lkml).
Please let me know if you want any further changes.
What's
Herbert Xu wrote:
What's wrong with using swap over dmcrypt + initramfs? People have
already used that to do encrypted swsusp.
Nothing. The problem is the fact that after resume there is then
unencrypted(*) data on disk that should never have been there, e.g.
dm-crypt keys, ssh keys, ...
This
Hi!
Here comes the next incarnation, this time against 2.6.12rc2.
Unfortunately only compile tested as 2.6.12rc2 happily oopses away
(vanilla from kernel.org, oops already sent to lkml).
Please let me know if you want any further changes.
Applied (it is *not* going to make it into 2.6.12,
Pavel Machek wrote:
Applied (it is *not* going to make it into 2.6.12, and not sure about
2.6.13, but it is in my local tree now. You had Kconfig and docs
changes, too, can you retransmit them?
Pavel
No changes to config and docs,
On Wed, Apr 13, 2005 at 02:59:28PM +0200, Andreas Steinmetz wrote:
Herbert Xu wrote:
What's wrong with using swap over dmcrypt + initramfs? People have
already used that to do encrypted swsusp.
Nothing. The problem is the fact that after resume there is then
unencrypted(*) data on disk
Herbert Xu wrote:
On Wed, Apr 13, 2005 at 02:59:28PM +0200, Andreas Steinmetz wrote:
Herbert Xu wrote:
What's wrong with using swap over dmcrypt + initramfs? People have
already used that to do encrypted swsusp.
Nothing. The problem is the fact that after resume there is then
unencrypted(*)
On Thu, Apr 14, 2005 at 12:29:36AM +0200, Andreas Steinmetz wrote:
Why is that? In the case of swap over dmcrypt, swsusp never reads/writes
the disk directly. All operations are done through dmcrypt.
The user has to enter a password before the system can be resumed.
Think of it the
On t 14-04-05 09:10:44, Herbert Xu wrote:
On Thu, Apr 14, 2005 at 12:29:36AM +0200, Andreas Steinmetz wrote:
Why is that? In the case of swap over dmcrypt, swsusp never reads/writes
the disk directly. All operations are done through dmcrypt.
The user has to enter a password before
On Thu, Apr 14, 2005 at 01:24:31AM +0200, Pavel Machek wrote:
The ssh keys are *encrypted* in the swap when dmcrypt is used.
When the swap runs over dmcrypt all writes including those from
swsusp are encrypted.
Andreas is right. They are encrypted in swap, but they should not be
there
On t 14-04-05 09:39:04, Herbert Xu wrote:
On Thu, Apr 14, 2005 at 01:24:31AM +0200, Pavel Machek wrote:
The ssh keys are *encrypted* in the swap when dmcrypt is used.
When the swap runs over dmcrypt all writes including those from
swsusp are encrypted.
Andreas is right. They are
On Thu, Apr 14, 2005 at 01:46:02AM +0200, Pavel Machek wrote:
On ??t 14-04-05 09:39:04, Herbert Xu wrote:
On Thu, Apr 14, 2005 at 01:24:31AM +0200, Pavel Machek wrote:
The ssh keys are *encrypted* in the swap when dmcrypt is used.
When the swap runs over dmcrypt all writes including
In article [EMAIL PROTECTED] you wrote:
The ssh keys are *encrypted* in the swap when dmcrypt is used.
When the swap runs over dmcrypt all writes including those from
swsusp are encrypted.
The problem is that after an resume the running system has access to the
swap, because the key is
In article [EMAIL PROTECTED] you wrote:
The dmcrypt swap can only be unlocked by the user with a passphrase,
which is analogous to how you unlock your ssh private key stored
on the disk using a passphrase.
We talk about the unlocked system getting hacked. However I am not why the
hacker would
Here comes the next incarnation, this time against 2.6.12rc2.
Unfortunately only compile tested as 2.6.12rc2 happily oopses away
(vanilla from kernel.org, oops already sent to lkml).
Please let me know if you want any further changes.
--
Andreas Steinmetz SPAMmers use
Rafael J. Wysocki wrote:
> Hi,
>
> On Monday, 11 of April 2005 18:11, Andreas Steinmetz wrote:
>
>>Pavel Machek wrote:
>>
>>>Was it really neccessary to include "union u"? I don't like its name,
>>
>>Here comes the patch with this reverted. I'm now using casts when
>>'abusing' the space for
Rafael J. Wysocki wrote:
> Hi,
>
> On Monday, 11 of April 2005 23:08, Pavel Machek wrote:
>
>>Hi!
>>
>
> ]--snip--[
>
@@ -130,6 +150,52 @@
static unsigned short swapfile_used[MAX_SWAPFILES];
static unsigned short root_swap;
+#ifdef CONFIG_SWSUSP_ENCRYPT
+static
Rafael J. Wysocki wrote:
Hi,
On Monday, 11 of April 2005 23:08, Pavel Machek wrote:
Hi!
]--snip--[
@@ -130,6 +150,52 @@
static unsigned short swapfile_used[MAX_SWAPFILES];
static unsigned short root_swap;
+#ifdef CONFIG_SWSUSP_ENCRYPT
+static struct crypto_tfm *crypto_init(int
Rafael J. Wysocki wrote:
Hi,
On Monday, 11 of April 2005 18:11, Andreas Steinmetz wrote:
Pavel Machek wrote:
Was it really neccessary to include union u? I don't like its name,
Here comes the patch with this reverted. I'm now using casts when
'abusing' the space for encryption. Furthermore
Here comes the next incarnation, this time against 2.6.12rc2.
Unfortunately only compile tested as 2.6.12rc2 happily oopses away
(vanilla from kernel.org, oops already sent to lkml).
Please let me know if you want any further changes.
--
Andreas Steinmetz SPAMmers use
Hi,
On Monday, 11 of April 2005 23:08, Pavel Machek wrote:
> Hi!
>
]--snip--[
> > > @@ -130,6 +150,52 @@
> > > static unsigned short swapfile_used[MAX_SWAPFILES];
> > > static unsigned short root_swap;
> > >
> > > +#ifdef CONFIG_SWSUSP_ENCRYPT
> > > +static struct crypto_tfm *crypto_init(int
Hi!
> I had no time to review your patch earlier, sorry. I'm inlining it so that I
> can
> comment it:
> > @@ -72,6 +75,16 @@
> >
> > #include "power.h"
> >
> > +#ifdef CONFIG_SWSUSP_ENCRYPT
> > +#include
> > +#include
> > +#include
> > +#endif
> > +
> > +#define CIPHER "aes"
> >
Hi,
On Monday, 11 of April 2005 18:11, Andreas Steinmetz wrote:
> Pavel Machek wrote:
> > Was it really neccessary to include "union u"? I don't like its name,
>
> Here comes the patch with this reverted. I'm now using casts when
> 'abusing' the space for encryption. Furthermore the iv set up in
Hi!
> > I'd like to retain ability to read suspend image in any order (so that
> > code can be reused for swap encryption, etc).
>
> This is not possible with cipher block chaining as used right now. One
> would have to use a non-random iv set needs to set for every page. And
> this leads to
Pavel Machek wrote:
> I'd like to retain ability to read suspend image in any order (so that
> code can be reused for swap encryption, etc).
> Pavel
This is not possible with cipher block chaining as used right now. One
would have to
Pavel Machek wrote:
> Was it really neccessary to include "union u"? I don't like its name,
Here comes the patch with this reverted. I'm now using casts when
'abusing' the space for encryption. Furthermore the iv set up in the tfm
is used instead of the local copy.
--
Andreas Steinmetz
Pavel Machek wrote:
> Hi!
>
>
>>The following patch adds the core functionality for the encrypted
>>suspend image.
>
>
> +#ifdef CONFIG_SWSUSP_ENCRYPT
> +static struct crypto_tfm *crypto_init(int mode)
> +{
> + struct crypto_tfm *tfm;
> + int len;
> +
> + tfm =
[EMAIL PROTECTED] wrote:
>>>The following patch adds the core functionality for the encrypted
>>>suspend image.
>>
>>[Please inline patches, it makes it easier to comment on them.]
Aiyeeh - good ole Mozilla tends to reformat things when inlining...
>>You seem to reuse same key/iv for all the
> > > > The following patch adds the core functionality for the encrypted
> > > > suspend image.
> > > [Please inline patches, it makes it easier to comment on them.]
> > > You seem to reuse same key/iv for all the blocks. I'm no crypto
> > > expert, but I think that is seriously wrong... You
Hi!
> The following patch adds the core functionality for the encrypted
> suspend image.
+#ifdef CONFIG_SWSUSP_ENCRYPT
+static struct crypto_tfm *crypto_init(int mode)
+{
+ struct crypto_tfm *tfm;
+ int len;
+
+ tfm = crypto_alloc_tfm(CIPHER, CRYPTO_TFM_MODE_CBC);
+
Hi!
> > > The following patch adds the core functionality for the encrypted
> > > suspend image.
> > [Please inline patches, it makes it easier to comment on them.]
> > You seem to reuse same key/iv for all the blocks. I'm no crypto
> > expert, but I think that is seriously wrong... You probably
> > The following patch adds the core functionality for the encrypted
> > suspend image.
> [Please inline patches, it makes it easier to comment on them.]
> You seem to reuse same key/iv for all the blocks. I'm no crypto
> expert, but I think that is seriously wrong... You probably should use
>
Hi!
> The following patch adds the core functionality for the encrypted
> suspend image.
[Please inline patches, it makes it easier to comment on them.]
You seem to reuse same key/iv for all the blocks. I'm no crypto
expert, but I think that is seriously wrong... You probably should use
block
Hi!
The following patch adds the core functionality for the encrypted
suspend image.
[Please inline patches, it makes it easier to comment on them.]
You seem to reuse same key/iv for all the blocks. I'm no crypto
expert, but I think that is seriously wrong... You probably should use
block
The following patch adds the core functionality for the encrypted
suspend image.
[Please inline patches, it makes it easier to comment on them.]
You seem to reuse same key/iv for all the blocks. I'm no crypto
expert, but I think that is seriously wrong... You probably should use
block
Hi!
The following patch adds the core functionality for the encrypted
suspend image.
[Please inline patches, it makes it easier to comment on them.]
You seem to reuse same key/iv for all the blocks. I'm no crypto
expert, but I think that is seriously wrong... You probably should use
Hi!
The following patch adds the core functionality for the encrypted
suspend image.
+#ifdef CONFIG_SWSUSP_ENCRYPT
+static struct crypto_tfm *crypto_init(int mode)
+{
+ struct crypto_tfm *tfm;
+ int len;
+
+ tfm = crypto_alloc_tfm(CIPHER, CRYPTO_TFM_MODE_CBC);
+
The following patch adds the core functionality for the encrypted
suspend image.
[Please inline patches, it makes it easier to comment on them.]
You seem to reuse same key/iv for all the blocks. I'm no crypto
expert, but I think that is seriously wrong... You probably should use
[EMAIL PROTECTED] wrote:
The following patch adds the core functionality for the encrypted
suspend image.
[Please inline patches, it makes it easier to comment on them.]
Aiyeeh - good ole Mozilla tends to reformat things when inlining...
You seem to reuse same key/iv for all the blocks. I'm no
Pavel Machek wrote:
Hi!
The following patch adds the core functionality for the encrypted
suspend image.
+#ifdef CONFIG_SWSUSP_ENCRYPT
+static struct crypto_tfm *crypto_init(int mode)
+{
+ struct crypto_tfm *tfm;
+ int len;
+
+ tfm = crypto_alloc_tfm(CIPHER,
Pavel Machek wrote:
Was it really neccessary to include union u? I don't like its name,
Here comes the patch with this reverted. I'm now using casts when
'abusing' the space for encryption. Furthermore the iv set up in the tfm
is used instead of the local copy.
--
Andreas Steinmetz
Pavel Machek wrote:
I'd like to retain ability to read suspend image in any order (so that
code can be reused for swap encryption, etc).
Pavel
This is not possible with cipher block chaining as used right now. One
would have to use
Hi!
I'd like to retain ability to read suspend image in any order (so that
code can be reused for swap encryption, etc).
This is not possible with cipher block chaining as used right now. One
would have to use a non-random iv set needs to set for every page. And
this leads to exactly the
Hi,
On Monday, 11 of April 2005 18:11, Andreas Steinmetz wrote:
Pavel Machek wrote:
Was it really neccessary to include union u? I don't like its name,
Here comes the patch with this reverted. I'm now using casts when
'abusing' the space for encryption. Furthermore the iv set up in the tfm
1 - 100 of 104 matches
Mail list logo
