Hi Phil,
First! Thanks for your time to review my patch!
於 一，2013-09-23 於 19:49 +0300，Phil Carmody 提到：
> On Sun, Sep 15, 2013 at 08:56:48AM +0800, Lee, Chun-Yi wrote:
> > Implement EMSA_PKCS1-v1_5-ENCODE [RFC3447 sec 9.2] in rsa.c. It's the
> > first step of signature generation operation (RSASS
Hi!
> > On Sun 2013-09-15 08:56:59, Lee, Chun-Yi wrote:
> > > This patch introduced SNAPSHOT_SIG_HASH config for user to select which
> > > hash algorithm will be used during signature generation of snapshot.
> >
> > This series is big enough already... and who is going to test it?
>
> The hash
When comparing MAC hashes, AEAD authentication tags, or other hash
values in the context of authentication or integrity checking, it
is important not to leak timing information to a potential attacker,
i.e. when communication happens over a network.
Bytewise memory comparisons (such as memcmp) are
於 四，2013-09-26 於 10:19 +0800，joeyli 提到：
> 於 三，2013-09-25 於 17:25 -0400，Alan Stern 提到：
> > On Wed, 25 Sep 2013, David Howells wrote:
> >
> > > I have pushed some keyrings patches that will likely affect this to:
> > >
> > >
> > > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git
Hi all,
I could'nt understand the mechanism of IV generation in geode-aes. Can
someone explain it in easy to understand manner?
Thanks a lot.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at ht
Hi,
On Friday 20 September 2013 04:41 AM, Russell King wrote:
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask(). Only arch and bus code should access this
member directly.
Convert all direc
When finishing the ahash request, the ahash_op_unaligned_done() will
call complete() on the request. Yet, this will not call the correct
complete callback. The correct complete callback was previously stored
in the requests' private data, as seen in ahash_op_unaligned(). This
patch restores the cor
Enable the DCP by default on both i.MX23 and i.MX28.
Signed-off-by: Marek Vasut
Cc: Herbert Xu
Cc: David S. Miller
Cc: Fabio Estevam
Cc: Shawn Guo
To: linux-crypto@vger.kernel.org
---
arch/arm/boot/dts/imx23.dtsi | 4 +++-
arch/arm/boot/dts/imx28.dtsi | 5 +++--
2 files changed, 6 insertions
Add support for the MXS DCP block. The driver currently supports
SHA-1/SHA-256 hashing and AES-128 CBC/ECB modes. The non-standard
CRC32 is not yet supported.
Signed-off-by: Marek Vasut
Cc: Herbert Xu
Cc: David S. Miller
---
drivers/crypto/Kconfig | 17 +
drivers/crypto/Makefile |1 +
Hi Marek,
On Thu, Sep 26, 2013 at 8:18 AM, Marek Vasut wrote:
> Add support for the MXS DCP block. The driver currently supports
> SHA-1/SHA-256 hashing and AES-128 CBC/ECB modes. The non-standard
> CRC32 is not yet supported.
>
> Signed-off-by: Marek Vasut
> Cc: Herbert Xu
> Cc: David S. Mille
Hi,
Marek Vasut writes:
> Enable the DCP by default on both i.MX23 and i.MX28.
>
> Signed-off-by: Marek Vasut
> Cc: Herbert Xu
> Cc: David S. Miller
> Cc: Fabio Estevam
> Cc: Shawn Guo
> To: linux-crypto@vger.kernel.org
> ---
> arch/arm/boot/dts/imx23.dtsi | 4 +++-
> arch/arm/boot/dts/imx2
Hi!
> For the symmetric key solution, I will try HMAC (Hash Message
> Authentication Code). It's already used in networking, hope the
> performance is not too bad to a big image.
Kernel already supports crc32 of the hibernation image, you may want
to take a look how that is done.
Maybe you want
Dear Fabio Estevam,
> Hi Marek,
>
> On Thu, Sep 26, 2013 at 8:18 AM, Marek Vasut wrote:
> > Add support for the MXS DCP block. The driver currently supports
> > SHA-1/SHA-256 hashing and AES-128 CBC/ECB modes. The non-standard
> > CRC32 is not yet supported.
> >
> > Signed-off-by: Marek Vasut
Dear Lothar Waßmann,
> Hi,
>
> Marek Vasut writes:
> > Enable the DCP by default on both i.MX23 and i.MX28.
> >
> > Signed-off-by: Marek Vasut
> > Cc: Herbert Xu
> > Cc: David S. Miller
> > Cc: Fabio Estevam
> > Cc: Shawn Guo
> > To: linux-crypto@vger.kernel.org
> > ---
> >
> > arch/arm/b
Hi Marek,
some small comments below.
Marek Vasut writes:
> diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c
> new file mode 100644
> index 000..c2b35c7
> --- /dev/null
> +++ b/drivers/crypto/mxs-dcp.c
[...]
> +/* AES 128 ECB and AES 128 CBC */
> +static struct crypto_alg dcp_a
On 26.9.2013 14:06, Pavel Machek wrote:
> Actually...
>
> Is not it as simple as storing hash of hibernation image into NVRAM
> and then verifying the hash matches the value in NVRAM on next
> startup? No encryption needed.
I think that part of the exercise is to minimize the number of writes to
On Thu, Sep 26, 2013 at 02:06:21PM +0200, Pavel Machek wrote:
> > For the symmetric key solution, I will try HMAC (Hash Message
> > Authentication Code). It's already used in networking, hope the
> > performance is not too bad to a big image.
>
> Kernel already supports crc32 of the hibernation i
On Thu, Sep 26, 2013 at 02:21:23PM +0200, Michal Marek wrote:
> > Is not it as simple as storing hash of hibernation image into NVRAM
> > and then verifying the hash matches the value in NVRAM on next
> > startup? No encryption needed.
>
> I think that part of the exercise is to minimize the num
Hi Marek,
> + To compile this driver as a module, choose M here: the module
> + will be called atmel-sha.
This is probably wrong?
--
Veli-Pekka Peltola
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
On Thu, Sep 26, 2013 at 8:18 AM, Marek Vasut wrote:
> +config CRYPTO_DEV_MXS_DCP
> + tristate "Support for Freescale MXS DCP"
> + depends on ARCH_MXS
> + select CRYPTO_SHA1
> + select CRYPTO_SHA256
> + select CRYPTO_CBC
> + select CRYPTO_ECB
> + select CR
於 四，2013-09-26 於 14:06 +0200，Pavel Machek 提到：
> Hi!
>
> > For the symmetric key solution, I will try HMAC (Hash Message
> > Authentication Code). It's already used in networking, hope the
> > performance is not too bad to a big image.
>
> Kernel already supports crc32 of the hibernation image, yo
於 四，2013-09-26 於 14:22 +0200，Vojtech Pavlik 提到：
> On Thu, Sep 26, 2013 at 02:06:21PM +0200, Pavel Machek wrote:
>
> > > For the symmetric key solution, I will try HMAC (Hash Message
> > > Authentication Code). It's already used in networking, hope the
> > > performance is not too bad to a big imag
Dear Veli-Pekka Peltola,
> Hi Marek,
>
> > + To compile this driver as a module, choose M here: the module
> > + will be called atmel-sha.
>
> This is probably wrong?
Certainly. Nice to have you back btw. ;-)
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the
Dear Lothar Waßmann,
> Hi Marek,
>
> some small comments below.
>
> Marek Vasut writes:
> > diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c
> > new file mode 100644
> > index 000..c2b35c7
> > --- /dev/null
> > +++ b/drivers/crypto/mxs-dcp.c
>
> [...]
>
> > +/* AES 128 ECB
Hi,
Marek Vasut writes:
> Dear Lothar Waßmann,
>
> > Hi Marek,
> >
> > some small comments below.
> >
> > Marek Vasut writes:
> > > diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c
> > > new file mode 100644
> > > index 000..c2b35c7
> > > --- /dev/null
> > > +++ b/drivers/cr
On Thu, 2013-09-26 at 08:24 +0200, Jiri Kosina wrote:
> On Wed, 25 Sep 2013, James Bottomley wrote:
>
> > > I don't get this. Why is it important that current kernel can't
> > > recreate the signature?
> >
> > The thread model is an attack on the saved information (i.e. the suspend
> > image) bet
On Thu, 26 Sep 2013, James Bottomley wrote:
> > could you please describe the exact scenario you think that the symmetric
> > keys aproach doesn't protect against, while the assymetric key aproach
> > does?
> >
> > The crucial points, which I believe make the symmetric key aproach work
> > (an
On Thu, Sep 26, 2013 at 04:48:00PM +0200, Jiri Kosina wrote:
> > The only two problems I see are
> >
> > 1. The key isn't generational (any compromise obtains it). This
> > can be fixed by using a set of keys generated on each boot and
> > passing in both K_{N-1} and K_N
>
Hi,
In geode-aes, there is not any IV generation mechanism. In fact IV is
delivered to geode-aes's
registered algorithms, from upper layers.For example in case of
"cbc-aes-geode" algorithm,
from cbc wrapper ("cbc.c") via walk->iv:
blkcipher_walk_init(&walk, dst, src, nbytes);
err = blkcipher_walk
Here is the latest iteration of the constant-time memory
equality-testing patch:
* This patch includes contributions and a signoff from Daniel Borkmann.
* Moved the optimization flag -Os (used to prevent early return
optimization) into the Makefile after seeing a report that #pragma gcc
is co
2013/9/19 Russell King - ARM Linux :
> This email is only being sent to the mailing lists in question, not to
> anyone personally. The list of individuals is far to great to do that.
> I'm hoping no mailing lists reject the patches based on the number of
> recipients.
Huh, I think it was enough t
Hi Russell,
Thank you for the patch.
On Thursday 19 September 2013 22:56:02 Russell King wrote:
> The code sequence:
> isp->raw_dmamask = DMA_BIT_MASK(32);
> isp->dev->dma_mask = &isp->raw_dmamask;
> isp->dev->coherent_dma_mask = DMA_BIT_MASK(32);
> bypasses the architectures ch
32 matches
Mail list logo
