On Fri, Apr 17, 2015 at 02:54:58PM +0200, Stephan Mueller wrote:
> The creation of a shadow copy is intended to only hold a short term
> lock. But the drawback is that parallel users have a very similar DRBG
> state which only differs by a high-resolution time stamp.
>
> As the locking is changed
On Fri, Apr 17, 2015 at 02:55:28PM +0200, Stephan Mueller wrote:
>
> @@ -1349,7 +1348,9 @@ static int drbg_generate_long(struct drbg_state *drbg,
> unsigned int chunk = 0;
> slice = ((buflen - len) / drbg_max_request_bytes(drbg));
> chunk = slice ? drbg_max
On Fri, Apr 17, 2015 at 02:54:08PM +0200, Stephan Mueller wrote:
> The buffer uses for temporary data must be cleared entirely. In AES192
> the used buffer is drbg_statelen(drbg) + drbg_blocklen(drbg) as
> documented in the comment above drbg_ctr_df.
>
> This patch ensures that the temp buffer is
On Tue, Apr 14, 2015 at 11:51:29AM -0500, Colin King wrote:
> From: Colin Ian King
>
> backlog is not initialised so in the case where
> cpg->eng_st != ENGINE_IDLE it is never initialised and
> hence which could lead to an illegal memory dereference
> in the statement:
>
> backlog->complete(ba
Am Samstag, 18. April 2015, 18:55:23 schrieb Herbert Xu:
Hi Herbert,
>
> Incidentally the whole reset concept seems redundant as you could
> always free and allocate a new RNG instead. So I'm planning on
> replacing it with a seed/reseed function instead. IOW it will
> keep the existing state
Am Samstag, 18. April 2015, 18:49:43 schrieb Herbert Xu:
Hi Herbert,
> On Fri, Apr 17, 2015 at 02:54:58PM +0200, Stephan Mueller wrote:
> > The creation of a shadow copy is intended to only hold a short term
> > lock. But the drawback is that parallel users have a very similar DRBG
> > state whic
As the DRBG does not operate on shadow copies of the DRBG instance
any more, the cipher handles only need to be allocated once during
initalization time and deallocated during uninstantiate time.
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 12
1 file changed, 4 insertions(+),
The drbg_generate returns 0 in success case. That means that
drbg_generate_long will always only generate drbg_max_request_bytes at
most. Longer requests will be truncated to drbg_max_request_bytes.
Reported-by: Herbert Xu
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 2 +-
1 file changed,
Hi,
the current implementation of the DRBG generates a shadow copy of its
DRBG state for each incoming request. The idea is that only a short
term lock is needed to spawn the shadow copy. The drawback is that
if multiple parallel requests come in, the generated DRBG shadow
states only differ by a
The creation of a shadow copy is intended to only hold a short term
lock. But the drawback is that parallel users have a very similar DRBG
state which only differs by a high-resolution time stamp.
The DRBG will now hold a long term lock. Therefore, the lock is changed
to a mutex which implies that
Am Samstag, 18. April 2015, 16:42:20 schrieb Stephan Mueller:
Hi Stephan,
> The drbg_generate returns 0 in success case. That means that
> drbg_generate_long will always only generate drbg_max_request_bytes at
> most. Longer requests will be truncated to drbg_max_request_bytes.
>
> Reported-by:
The drbg_generate returns 0 in success case. That means that
drbg_generate_long will always only generate drbg_max_request_bytes at
most. Longer requests will be truncated to drbg_max_request_bytes.
Reported-by: Herbert Xu
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 14 +++---
1
As the DRBG does not operate on shadow copies of the DRBG instance
any more, the cipher handles only need to be allocated once during
initalization time and deallocated during uninstantiate time.
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 12
1 file changed, 4 insertions(+),
The creation of a shadow copy is intended to only hold a short term
lock. But the drawback is that parallel users have a very similar DRBG
state which only differs by a high-resolution time stamp.
The DRBG will now hold a long term lock. Therefore, the lock is changed
to a mutex which implies that
Hi,
the current implementation of the DRBG generates a shadow copy of its
DRBG state for each incoming request. The idea is that only a short
term lock is needed to spawn the shadow copy. The drawback is that
if multiple parallel requests come in, the generated DRBG shadow
states only differ by a
On Sat, Apr 18, 2015 at 01:35:40PM +0200, Stephan Mueller wrote:
>
> When you do that, may I ask you to also update the crypto_alloc_rng. This
> function has one major drawback at the moment: we are wasting precious
> entropy. The testmgr must allocate the RNG for performing its testing using
>
On Sat, Apr 18, 2015 at 07:35:11PM +0200, Stephan Mueller wrote:
> Hi,
>
> the current implementation of the DRBG generates a shadow copy of its
> DRBG state for each incoming request. The idea is that only a short
> term lock is needed to spawn the shadow copy. The drawback is that
> if multiple
On Fri, Apr 17, 2015 at 04:31:47PM +0200, Christophe Leroy wrote:
> The purpose of this set of patchs is to add to talitos crypto driver
> the support for the SEC1 version of the security engine, which is
> found in mpc885 and mpc8272 processors.
>
> v3 is a complete rework of the patchset. Since
18 matches
Mail list logo
