On Thu, May 28, 2020 at 10:33:25AM +0200, Ard Biesheuvel wrote:
>
> The reason we return output IVs for CBC is because our generic
> implementation of CTS can wrap any CBC implementation, and relies on
> this output IV rather than grabbing it from the ciphertext directly
> (which may be tricky and
On Fri, 29 May 2020 at 10:05, Herbert Xu wrote:
>
> On Thu, May 28, 2020 at 10:33:25AM +0200, Ard Biesheuvel wrote:
> >
> > The reason we return output IVs for CBC is because our generic
> > implementation of CTS can wrap any CBC implementation, and relies on
> > this output IV rather than grabbin
On 2020/4/16 14:01, Herbert Xu wrote:
On Thu, Apr 02, 2020 at 08:34:57PM +0800, Tianjia Zhang wrote:
Hello all,
This new module implement the OSCCA certificate and SM2 public key
algorithm. It was published by State Encryption Management Bureau, China.
List of specifications for OSCCA certif
On Fri, May 29, 2020 at 10:20:27AM +0200, Ard Biesheuvel wrote:
>
> But many implementation do not return an output IV at all. The only
> mode that requires it (for the selftests to pass) is CBC.
Most modes can be chained, e.g., CBC, PCBC, OFB, CFB and CTR.
As it stands algif_skcipher requres all
On Fri, May 29, 2020 at 07:04:48PM +0800, Tianjia Zhang wrote:
>
> On 2020/4/16 14:01, Herbert Xu wrote:
> > On Thu, Apr 02, 2020 at 08:34:57PM +0800, Tianjia Zhang wrote:
> > > Hello all,
> > >
> > > This new module implement the OSCCA certificate and SM2 public key
> > > algorithm. It was publi
On Fri, 29 May 2020 at 13:51, Herbert Xu wrote:
>
> On Fri, May 29, 2020 at 10:20:27AM +0200, Ard Biesheuvel wrote:
> >
> > But many implementation do not return an output IV at all. The only
> > mode that requires it (for the selftests to pass) is CBC.
>
> Most modes can be chained, e.g., CBC, PC
On Fri, May 29, 2020 at 02:00:14PM +0200, Ard Biesheuvel wrote:
>
> Even if this is the case, it requires that an skcipher implementation
> stores an output IV in the buffer that skcipher request's IV field
> points to. Currently, we only check whether this is the case for CBC
> implementations, an
If a read(2) of less than a full block size is attempted we will
end up doing a zero-length operation. This patch makes that return
-EINVAL instead, which is what we did originally.
Fixes: e870456d8e7c ("crypto: algif_skcipher - overhaul memory...")
Signed-off-by: Herbert Xu
diff --git a/crypto
On Fri, 29 May 2020 at 14:02, Herbert Xu wrote:
>
> On Fri, May 29, 2020 at 02:00:14PM +0200, Ard Biesheuvel wrote:
> >
> > Even if this is the case, it requires that an skcipher implementation
> > stores an output IV in the buffer that skcipher request's IV field
> > points to. Currently, we only
AEAD does not support partial requests so we must not wake up
while ctx->more is set. While we're fixing this also change
algif_skcipher to only wake up when at least a block is available
as otherwise we'd just fail straight away with -EINVAL.
Fixes: 2d97591ef43d ("crypto: af_alg - consolidation
On Fri, May 29, 2020 at 03:10:43PM +0200, Ard Biesheuvel wrote:
>
> OK, so the undocumented assumption is that algif_skcipher requests are
> delineated by ALG_SET_IV commands, and that anything that gets sent to
> the socket in between should be treated as a single request, right? I
Correct.
> th
On Fri, 29 May 2020 at 15:19, Herbert Xu wrote:
>
> On Fri, May 29, 2020 at 03:10:43PM +0200, Ard Biesheuvel wrote:
> >
> > OK, so the undocumented assumption is that algif_skcipher requests are
> > delineated by ALG_SET_IV commands, and that anything that gets sent to
> > the socket in between sh
On Fri, May 29, 2020 at 03:41:08PM +0200, Ard Biesheuvel wrote:
>
> So what about the final request? At which point do you decide to
> return the final chunk of data that you have been holding back in
> order to ensure that you can perform the final processing correctly if
> it is not being followe
AEAD does not support partial requests so we must not wake up
while ctx->more is set. In order to distinguish between the
case of no data sent yet and a zero-length request, a new init
flag has been added to ctx.
SKCIPHER has also been modified to ensure that at least a block
of data is avail
On Mon, May 25, 2020 at 10:28:46PM +0200, Arnd Bergmann wrote:
> On Mon, May 25, 2020 at 10:07 PM Olivier Sobrie
> wrote:
> >
> > Silex insight BA431 is an IP designed to generate random numbers that
> > can be integrated in various FPGA.
> > This driver adds support for it through the hwrng inter
On Mon, 25 May 2020 21:56:04 +0200, Olivier Sobrie wrote:
> Silex Insight is a microelectronic company whose headquarter is located
> in Belgium.
> Web site of the company: https://www.silexinsight.com/
>
> Signed-off-by: Olivier Sobrie
> ---
> Documentation/devicetree/bindings/vendor-prefixes.y
On Mon, 25 May 2020 21:56:05 +0200, Olivier Sobrie wrote:
> This patch documents the device tree bindings of the BA431 hardware
> random number generator.
>
> This IP is for instance present in the Viper OEM boards sold by Silex
> Insight.
>
> Signed-off-by: Olivier Sobrie
> ---
> .../bindings/
On Fri, May 29, 2020 at 11:12:31AM -0600, Rob Herring wrote:
> On Mon, May 25, 2020 at 10:28:46PM +0200, Arnd Bergmann wrote:
> > On Mon, May 25, 2020 at 10:07 PM Olivier Sobrie
> > wrote:
> > >
> > > Silex insight BA431 is an IP designed to generate random numbers that
> > > can be integrated in
18 matches
Mail list logo
