Am Donnerstag, 23. November 2017, 12:27:30 CET schrieb Dmitry Vyukov:
Hi Dmitry,
> Hi Stephan,
>
> Thanks for the explanation! I am starting to digesting it.
>
> You say that:
> > static const struct crypto_type crypto_skcipher_type2 = {
> >
> > .type = CRYPTO_ALG_TYPE_SKCIPHER,
>
> will select implementations of types SKCIPHER or ABLKCIPHER.
> But there are no such implementations. I see only implementation of
> types CIPHER and BLKCIPHER:
>
> .cra_flags = CRYPTO_ALG_TYPE_CIPHER,
> crypto/seed.c
>
> .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
> crypto/salsa20_generic.c
The blkcipher (symmetric synchronous cipher) is made asynchronous (ABLKCIPHER)
via cryptd() implemented in crypto/cryptd.c. When using the skcipher API
without any specific flags, it will allocate cryptd(salsa20_generic) in your
case above transparently and mark it as an ABLKCIPHER.
CIPHER is a block cipher without block chaining which is only capable of
encrypting one block. You can only use it with the crypto_cipher* API.
As this API is not exported via AF_ALG, you cannot access those ciphers from
user space directly (albeit they are accessible indirectly via templates
implementing block chaining algos)
>
> SKCIPHER=0x5. Does it mean that it selects implementations that has
> ((cra_flags&CRYPTO_ALG_TYPE_MASK)&SKCIPHER) != 0? I.e. CIPHER and
> BLKCIPHER would match that.
>
> But then I am again confused, because CRYPTO_ALG_TYPE_AEAD is 0x3 so
> it would match CRYPTO_ALG_TYPE_COMPRESS and CRYPTO_ALG_TYPE_CIPHER
> again. Does not make sense to me...
COMPRESS / PCOMPRESS implementations are accessible via the crypto_compress_*
APIs. There is (currently) no AF_ALG interface for this API.
>
>
> And to confirm, we can't reach compress from userspace because only
> these 4 types are exposed "aead", "hash", "rng", "skcipher". Is it
> correct?
Precisely. Look into algif_*.c which kernel crypto API calls are exported to
user space.
> --
> To unsubscribe from this list: send the line "unsubscribe keyrings" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Ciao
Stephan
