On Thu, Nov 23, 2017 at 10:35 AM, Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote: > On Thu, Nov 23, 2017 at 10:32 AM, Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote: >> On Wed, Nov 22, 2017 at 6:08 PM, Stephan Mueller <smueller@xxxxxxxxxx> wrote: >>> Am Mittwoch, 22. November 2017, 11:44:51 CET schrieb Dmitry Vyukov: >>> >>> Hi Dmitry, >>> >>>> >>>> Thanks! I think we can incorporate this into syzkaller. >>>> >>>> One question: what's the relation between alg names and type ("aead", >>>> "hash", "rng", "skcipher")? >>> >>> If you refer to AF_ALG, then the following applies: >>> >>> AF_ALG type of aead -> kernel crypto API: crypto_aead_*, aead_request_* >>> >>> AF_ALG type of skcipher -> kernel crypto API: crypto_skcipher_*, >>> skcipher_request_* >>> >>> AF_ALG type of hash -> kernel crypto API: crypto_ahash_*, ahash_request_* >>> >>> AF_ALG type of rng -> kernel crypto API: crypto_rng_* >>> >>> >>>> I remember I already looked at it before >>>> and could not figure it out. Are all algorithms and templates >>>> partitioned between types? Or they are orthogonal? >>> >>> If you refer to the cipher names, there are two types: templates and cipher >>> implementations. See [1] for details. [2] gives you some ideas of the >>> interrelationships between the templates and the ciphers. >>> >>> The relationship between the names and the AF_ALG names mentioned above is >>> defined with the .cra_flags in the cipher specification of each cipher >>> implementation. See [3] for details. >>> >>> Note, I started some fuzzing work in my libkcapi test application. See [4] for >>> the implementation. >>> >>> [1] http://www.chronox.de/crypto-API/crypto/architecture.html#crypto-api-cipher-references-and-priority >>> >>> [2] http://www.chronox.de/crypto-API/crypto/architecture.html#internal-structure-of-kernel-crypto-api >>> >>> [3] http://www.chronox.de/crypto-API/crypto/architecture.html#cipher-allocation-type-and-masks >>> >>> [4] https://github.com/smuellerDD/libkcapi/blob/master/test/kcapi-main.c line >>> 522 >> >> >> I've read the links and starring at the code, but still can't get it. >> The question is about textual type names in sockaddr. >> .cra_flags does not specify textual names. >> [3] again talks about int flags rather than textual names. >> >> I see they are used here: >> http://www.chronox.de/crypto-API/crypto/userspace-if.html#aead-cipher-api >> >> but it merely says: >> >> .salg_type = "aead", /* this selects the symmetric cipher */ >> .salg_name = "gcm(aes)" /* this is the cipher name */ >> >> and does not explain why it is must be "aead" for "gcm(aes)", nor why >> would "skcipher" fail for "gcm(aes)" (would it?). >> >> These integer flags in sockaddr_alg.feat/mask seem to be better always >> be 0 (because they can only fail an otherwise passing bind, right?). >> But the textual type seems to matter, because bind first looks at type >> and then everything else happens as callbacks on type. >> >> I've found these guys: >> >> tatic const struct crypto_type crypto_skcipher_type2 = { >> .extsize = crypto_skcipher_extsize, >> .init_tfm = crypto_skcipher_init_tfm, >> .free = crypto_skcipher_free_instance, >> #ifdef CONFIG_PROC_FS >> .show = crypto_skcipher_show, >> #endif >> .report = crypto_skcipher_report, >> .maskclear = ~CRYPTO_ALG_TYPE_MASK, >> .maskset = CRYPTO_ALG_TYPE_BLKCIPHER_MASK, >> .type = CRYPTO_ALG_TYPE_SKCIPHER, >> .tfmsize = offsetof(struct crypto_skcipher, base), >> }; >> >> But it still does not make sense to me. >> CRYPTO_ALG_TYPE_SKCIPHER const is not mentioned in any actual algorithms. >> and CRYPTO_ALG_TYPE_BLKCIPHER_MASK is 0xc, which selects >> CRYPTO_ALG_TYPE_BLKCIPHER, CRYPTO_ALG_TYPE_KPP and >> CRYPTO_ALG_TYPE_RNG. And it looks like a random subset of >> constants.... > > > Also, there seems to be only 4 types ("aead", "hash", "rng", > "skcipher"), but more algorithm types. For example, how do I get > access to ACOMPRESS/SCOMPRESS? Looking at /proc/crypto confuses me even more: $ cat /proc/crypto | grep type | sort | uniq type : ablkcipher type : aead type : ahash type : akcipher type : blkcipher type : cipher type : compression type : givcipher type : rng type : shash Now, there are 10 types. They partially intersect with the other textual types (e.g. "aead"). But, say "skcipher" is not present in /proc/crypto at all.