On Thu, Aug 31, 2017 at 4:21 PM, Stephan Mueller <smueller@xxxxxxxxxx> wrote: > Am Donnerstag, 31. August 2017, 18:17:09 CEST schrieb Eugene Syromyatnikov: > > Hi Eugene, > >> On Thu, Aug 31, 2017 at 6:07 PM, Stephan Mueller <smueller@xxxxxxxxxx> > wrote: >> > Am Donnerstag, 31. August 2017, 17:58:36 CEST schrieb Eugene >> > Syromyatnikov: >> > >> > Hi Eugene, >> > >> >> +field is a null-terminated string no longer than >> >> +.B CRYPTO_MAX_ALG_NAME >> >> +(128 bytes as of this writing) which specifies hash name >> > >> > Is it necessary to specify that size? Note, up to 4.11 it was 64 bytes. >> > Also, it must be a valid cipher name as mentioned. Thus, I do not think >> > the size is relevant here considering the requirement to use a proper >> > name. >> >> Right, it's probably more important for syscall decoding, but not for >> the documentation. However, my understanding is that cipher template >> can be specified (like "rfc4106(gcm(aes))"), and I'm not sure how deep >> this nesting can be and whether it is possible to reach algorithm name >> limit this way (by employing the usage of driver name instead of >> common name, for example—as I understood, it is also possible). It >> probably makes more sense to just mention this limit in the ERRORS >> section instead. > > CRYPTO_MAX_ALG_NAME is given a size that all allowed cipher names can be > represented. > > Somehow in the 4.12 release cycle, somebody found a very obscure yet valid > name for a symmetric cipher that exceeded the 64 byte limit causing the bump > to 128 bytes. > > Though, that obscure name is no SHASH. All SHASH keyed digest cipher names are > below 64 bytes. I see. Thanks for the clarification! -- Eugene Syromyatnikov mailto:evgsyr@xxxxxxxxx xmpp:esyr@jabber.{ru|org} -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
