-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Feb 28, 2008, at 11:02 AM, David Crick wrote:
Ian wrote:
Hmmm... you raise an interesting point. I had thought that this
was going to be a new document, and as it is not referred to in
the existing core RFC, then ECC/Suite B was going to be a MAY by
definition.
Within that new (MAY) document, there would be several choices
for MUST, SHOULD, MAY, etc.
Or so I thought ... but I'm not fully aware of how these things
interact.
and further:
I don't see how we can simplify past dropping 192.
OK, if you are happy to carry on this discussion ... what are the
reasons for including the 128-bit profile?
assuming the may -> whatever chain above holds, what about:
MAY implement ECC
o MUST implement AES256-SHA384-384ECC
o SHOULD implement AES128-SHA256-256ECC
o MAY implement AES256-SHA512-521ECC
[and/or any other combinations, but these might be "unbalanced"]
I think you have the polarity wrong.
AES256-SHA512-521ECC is desirable because it's the most secure.
AES128-SHA256-256ECC is desirable because it's fast, and it's what is
most likely to be in constrained environments.
AES256-SHA384-384ECC (which I think should actually be AES192-
SHA384-384ECC), is slow and not as secure. It's neither fish nor fowl.
However, for completeness, eliminating it is likely not wise. As much
as I sneer at NIST's fondness for 192-bit security (especially when it
runs at the same speed as 256-bit security), it's foolish to eliminate
it from the spec. That's the sort of thing that might bite us in the
ass years from now. The probability that I'll get a cogent,
enlightening explanation of why 192-bit security is a Good Thing is
directly proportional to the probability of our excluding it.
Jon
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII
wj8DBQFHx8uQsTedWZOD3gYRAjcgAKCHpO1SjUt+hb8JPV7asxSyJ2uLNgCglqr5
ngJIWmCOG4fzItYg6AnMylQ=
=Kun2
-----END PGP SIGNATURE-----