2010/8/11 Linus Walleij <linus.walleij@xxxxxxxxxxxxxx>: Hello, > Hi Miloslav, > c.f how the ALSA mixer presents a lot of things to userspace without > using any enums at all in /dev/snd/controlC0 for card 0. For example > in include/linux/soundcard.h you find the different control knobs > enumerated with strings so as to avoid explicit enums. This is a double edged sword. Although it provides freedom at the userspace, it would also allow crypto algorithms that were not considered by the original design to be used with unpredictable results. Moreover typos are found at run-time rather than compile-time. For this and similar reasons interfaces of crypto libraries and PKCS #11 define explicitly the allowed algorithms. This design followed this principle. > 2. To avoid security hazards the API would benefit from being programmed > with at least some secure programming concepts in mid. Input argument > checking separate from algorithm separate from output argument checking, > and erasing of information from stacks and buffers. More or less What do you consider as a threat here? Is it for the kernel returing unerased buffers and stack to userspace? > 3. A general interface for stream ciphers would be nice. The only differences > are that they do not operate on blocks, but bits, and that they > always require > an IV. Arguably this can be added later if the aspect if just considered when > devising the interface. The recent discussion in this thread > regarding netlink > points in a direction where streams are a natural part of the concept I > believe. This interface works (or should) with any kind of cipher. It is designed to be wrappable to a pkcs #11 module, to be used easily as backend by existing crypto applications and libraries. regards, Nikos -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
