Hi Milan,
On 27 May 2016 at 14:31, Milan Broz wrote:
> On 05/25/2016 08:12 AM, Baolin Wang wrote:
>> Now some cipher hardware engines prefer to handle bulk block rather than one
>> sector (512 bytes) created by dm-crypt, cause these cipher engines can handle
>> the intermediate values (IV) by the
Am Donnerstag, 26. Mai 2016, 22:14:29 schrieb Theodore Ts'o:
Hi Theodore,
> On Thu, May 26, 2016 at 08:49:39PM +0200, Stephan Mueller wrote:
> > Using the kernel crypto API one can relieve the CPU of the crypto work, if
> > a hardware or assembler implementation is available. This may be of
> > p
On 05/27/2016 09:04 AM, Baolin Wang wrote:
> Hi Milan,
>
> On 27 May 2016 at 14:31, Milan Broz wrote:
>> On 05/25/2016 08:12 AM, Baolin Wang wrote:
>>> Now some cipher hardware engines prefer to handle bulk block rather than one
>>> sector (512 bytes) created by dm-crypt, cause these cipher engin
On 27 May 2016 at 15:53, Milan Broz wrote:
> On 05/27/2016 09:04 AM, Baolin Wang wrote:
>> Hi Milan,
>>
>> On 27 May 2016 at 14:31, Milan Broz wrote:
>>> On 05/25/2016 08:12 AM, Baolin Wang wrote:
Now some cipher hardware engines prefer to handle bulk block rather than
one
sector
On Wed, May 25, 2016 at 03:05:28PM +0200, Marcus Meissner wrote:
> On Wed, May 25, 2016 at 01:39:46PM +0200, Stephan Mueller wrote:
> > Am Mittwoch, 25. Mai 2016, 13:36:10 schrieb Marcus Meissner:
> >
> > Hi Marcus,
> >
> > > Hi,
> > >
> > > On Wed, May 25, 2016 at 09:10:31AM +0200, Stephan Muel
Am Freitag, 27. Mai 2016, 11:19:32 schrieb Marcus Meissner:
Hi Marcus,
>
> And it actually is:
>
> [ 180.942532] hmac: blocksize check failed, ds=4, cra_blocksize=1, ss=4
> [ 180.942541] alg: hash: Failed to load transform for hmac(crc32): -2
> [ 180.989191] tcrypt: one or more tests failed!
Use helper for all modifications to talitos_ptr in preparation to
the implementation of AEAD for SEC1
to_talitos_ptr_extent_clear() has been removed in favor of
to_talitos_ptr_ext_set() to set any value and
to_talitos_ptr_ext_or() to or the extent field with a value
name has been shorten to help k
This set of patches provides the implementation of AEAD for
talitos SEC1.
Christophe Leroy (6):
crypto: talitos - using helpers for all talitos_ptr operations
crypto: talitos - making mapping helpers more generic
crypto: talitos - Implement AEAD for SEC1 using HMAC_SNOOP_NO_AFEU
crypto: ta
This patchs enhances the IPSEC_ESP related functions for them to
also supports the same operations with descriptor type
HMAC_SNOOP_NO_AFEU.
The differences between the two descriptor types are:
* pointeurs 2 and 3 are swaped (Confidentiality key and
Primary EU Context IN)
* HMAC_SNOOP_NO_AFEU
This will allow IPSEC on SEC1
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 180 +++
1 file changed, 180 insertions(+)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index b554f56..d3951e3 100644
--- a/drivers/crypto
In preparation of IPSEC for SEC1, first step is to make the mapping
helpers more generic so that they can also be used by AEAD functions.
First, the functions are moved before IPSEC functions in talitos.c
talitos_sg_unmap() and unmap_sg_talitos_ptr() are merged as they
are quite similar, the seco
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index c17e6c9..fcdf83b 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -,14 +,6 @@ next:
SEC1 doesn't have IPSEC_ESP descriptor type but it is able to perform
IPSEC using HMAC_SNOOP_NO_AFEU, which is also existing on SEC2
In order to be able to define descriptors templates for SEC1 without
breaking SEC2+, we have to give lower priority to HMAC_SNOOP_NO_AFEU
so that SEC2+ selects IPSEC_
Read the requested number of data from the fifo
Signed-off-by: Yendapally Reddy Dhananjaya Reddy
Reviewed-by: Eric Anholt
---
drivers/char/hw_random/bcm2835-rng.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hw_random/bcm2835-rng.c
b/drivers/ch
This supports the random number generator available in NSP SoC.
Masks the rng interrupt for NSP.
Signed-off-by: Yendapally Reddy Dhananjaya Reddy
Acked-by: Eric Anholt
---
drivers/char/hw_random/Kconfig | 2 +-
drivers/char/hw_random/bcm2835-rng.c | 34 ++
This patchset contains the hw random number generator support for the
Broadcom's NSP SoC. The block is similar to the block available in
bcm2835 with different default interrupt mask value. Due to lack of
documentation, I cannot confirm the interrupt mask register details
in bcm2835. In an effort t
Add support for the random number generator to the Northstar Plus
SoC device tree.
Signed-off-by: Yendapally Reddy Dhananjaya Reddy
---
arch/arm/boot/dts/bcm-nsp.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index de
Document the bindings used by Northstar Plus(NSP) SoC random number
generator.
Signed-off-by: Yendapally Reddy Dhananjaya Reddy
Acked-by: Eric Anholt
---
Documentation/devicetree/bindings/rng/brcm,bcm2835.txt | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentatio
Now some cipher hardware engines prefer to handle bulk block rather than one
sector (512 bytes) created by dm-crypt, cause these cipher engines can handle
the intermediate values (IV) by themselves in one bulk block. This means we
can increase the size of the request by merging request rather than
In now dm-crypt code, it is ineffective to map one segment (always one
sector) of one bio with just only one scatterlist at one time for hardware
crypto engine. Especially for some encryption mode (like ecb or xts mode)
cooperating with the crypto engine, they just need one initial IV or null
IV in
In dm-crypt, it need to map one bio to scatterlist for improving the
hardware engine encryption efficiency. Thus this patch introduces the
blk_bio_map_sg() function to map one bio with scatterlists.
For avoiding the duplicated code in __blk_bios_map_sg() function, add
one parameter to distinguish
This patchset will check if the cipher can support bulk mode, then dm-crypt
will handle different ways to send requests to crypto layer according to
cipher mode. For bulk mode, we can use sg table to map the whole bio and
send all scatterlists of one bio to crypto engine to encrypt or decrypt,
whic
Bring some consistency by:
1. Replacing fixed-space indentation of structure members with just
tabs.
2. Remove indentation in declaration of local variable between type and
name. Driver was mixing usage of such indentation and lack of it.
When removing indentation, reorder variables in
On Wednesday 25 May 2016 03:36 PM, Arnd Bergmann wrote:
On Wednesday, May 25, 2016 7:35:17 AM CEST Sudip Mukherjee wrote:
On Tuesday 24 May 2016 02:05 AM, Arnd Bergmann wrote:
On Monday, May 23, 2016 6:14:08 PM CEST Sudip Mukherjee wrote:
We have been getting build warning about:
drivers/char/
On 26/05/16 10:34, Maxime Coquelin wrote:
This patch fixes the following warning:
drivers/char/hw_random/stm32-rng.c: In function 'stm32_rng_read':
drivers/char/hw_random/stm32-rng.c:82:19: warning: 'sr' may be used
uninitialized in this function
Reported-
A theoretical paper on getting provably excellent randomness from two
relatively weak input sources.
https://www.sciencenews.org/article/new-technique-produces-real-randomness
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kerne
Am Freitag, 27. Mai 2016, 13:38:05 schrieb Sandy Harris:
Hi Sandy,
> A theoretical paper on getting provably excellent randomness from two
> relatively weak input sources.
> https://www.sciencenews.org/article/new-technique-produces-real-randomness
This document describes extractors. Those extra
On Fri, May 27, 2016 at 2:30 PM, Stephan Mueller wrote:
> This document describes extractors. Those extractors are intended to combine
> *independent* sources with weak entropy.
>
> None of our sources we have in add_*_randomness are independent.
No, but it would be easy to get two independent s
> If we implement something which happens to result in a 2 minute stall
> in boot times, the danger is that a clueless engineer at Sony, or LGE,
> or Motorola, or BMW, or Toyota, etc, will "fix" the problem without
> telling anyone about what they did, and we might not notice right away
> that the
Heya,
> On 27 May 2016, at 01:49, Stephan Mueller wrote:
> Then, the use of the DRBG offers users to choose between a Hash/HMAC and CTR
> implementation to suit their needs. The DRBG code is agnostic of the
> underlying cipher. So, you could even use Blowfish instead of AES or whirlpool
> instead
30 matches
Mail list logo
