And testing cost for one more crypto algorithm when the algorithmic permutations are already too high! Gandhar Gokhale Networking Components Group LSI
On Mon, Mar 10, 2014 at 10:28 PM, <[email protected]> wrote: > > On Mar 10, 2014, at 12:45 PM, Paul Wouters <[email protected]> wrote: > >> On Mon, 10 Mar 2014, [email protected] wrote: >> >>> That's a good argument for a user choosing to use AES-128 rather than >>> AES-256. But it doesn't really address why "SHOULD implement" isn't >>> justified -- the implementation cost is trivial and if it isn't used it has >>> no performance impact. >> >> It's not the implementation cost that matters. It is the GUI confusion. >> For example one vendor uses "aes" as aes128, and another vendor uses >> "aes" for aes256 (or aes_ctr or aes_cbc or aes_gcm). Each option we >> expose needlessly to the enduser is one more potential interop issue. > > True. But if you assume sufficiently foolish GUI designs, just about > anything can be hard to use. And I don't think that good crypto design > should be put at the mercy of people who can't design a decent UI. We know > that it's possible to get this right. > > paul > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
