Herbert, Eric, I noticed some interesting behavior from the crypto manager when dealing with a fallback cipher situation. I'm allocating a fallback (AEAD) cipher to handle some corner cases my HW cannot handle, but I noticed that the fallback itself is being tested when I allocate it (or so it seems) and if the fallback itself fails on some testvector, it is not replaced by an alternative while such an alternative should be available. So I have to fail my entire init because the fallback could not be allocated. i.e. while requesting a fallback for rfc7539(chacha20, poly1305), it attempts rfc7539(safexcel-chacha20,poly1305-simd), which fails, but it could still fall back to e.g. rfc7539(chacha20-simd, poly1305-simd), which should work. Actually, I really do not want the fallback to hit another algorithm of my own driver. Is there some way to prevent that from happening? (without actually referencing hard cra_driver_name's ...) Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Verimatrix www.insidesecure.com
