Rodney,
> AES-256 is listed in a NIST recommendation. It's not
marketing,
> it's following NIST guidance.
I'm taking about TLS/AES-256, not taking about AES-256. In
TLS WG,
they tried to adapt only AES-128 and ignored AES-256. First
of all,
they said "AES-256 is too much". I pushed AES-256
to TLS because it
was nice for backup cipher for AES-128 and it was only a
chance to
adapt 256-bit cipher to TLS.
They didn't select AES-256 as by NIST recommendation. They
didn't
select AES-192 also. They selected AES-256 as "backup
for 128bit
cipher".
That is ture story.
At that time, I didn't think that many people use AES-256
because
actually, AES-128 was enough.
Today, in fact, many people use AES-256. I learn that
people tend to
use stronger cipher which is prepared for them because they
want to
feel safer. That is a sort of psycological attitude, not
technical
attitude.
> Not to say that's not debatable but it's not just
"marketing" or key
> material size obsession.
I'm sorry that I confused you by my English capability.
I meant a term "marketing" that I said is as
"to know what people want
to get". I have thought that we should provide a
service for people
by what people want to do, not by engineer's ego. And I
have thought
that we should think something practical. To implement
Camellia-256
is practical thing more than to implement a set of
Camellia-128/256. A
set of Camellia-128/256 may be acceptable but a few people
will use
Camellia-128 because there are other 128-bit ciphers and
it's too late
to list it up. So, I list only Camellia-256 and I think it
is OK for
everyone.
Also, only Camellia-256 is nothing special because only
TWOFISH-256 is
listed in OpenPGP cipher.
Regards,
---
Hironobu SUZUKI <hironobu at h2np dot net><hironobu
at fsij dot org>
Hironobu SUZUKI Office, Inc. / FSIJ / WCLSCAN / OpenPKSD
Tokyo, Japan.
http://h2np.net
|
