On 11 July 2014 11:56, Andy Polyakov <ap...@openssl.org> wrote:
>>> Bottom line [still] is that enc is not the place to perform XTS,
>>> *unless* it's treated specially. In other words question should not be
>>> about setting IV, but about *if* XTS should be supported by enc, and if
>>> so, how exactly.
>>
>> It seems to me this is why jamming modes like XTS into standard EVP as
>> if they were like other modes is a less than great idea.
>
> But providing own interface for every specific mode is also hardly fun.
> I mean there ought to be balance. Now we have EVP that implies different
> semantic in different modes. In other words application might have to
> perform extra calls depending on mode (and in this particular case
> problem is that enc doesn't do those calls). What would be alternative?
> Distinct interface for every class of modes?

Yes.

> Can we define what makes up
> such class? What do we expect from interface? Also note that either way,
> the fact that it needs to be treated in enc in special way doesn't
> change. It's not like I'm rejecting alternatives to EVP, but discussion
> have to be more constructive.

Right, agree that there has to be support for it, whatever happens.
The problem with the current situation is that because the same
interface is used (sometimes in strange ways) for incompatible modes,
s/w can _think_ it is capable of doing, e.g., XTS, when in fact it is
not.

It doesn't seem helpful to give that appearance by re-using the API
when it isn't actually true.

That said, there's certainly something to be said for having a common
API for the common parts.

Perhaps the thing to do is to make it so when you create an XTS_EVP,
that has the extra stuff needed to support XTS, but you can also
extract from it an EVP (or whatever the common interface is) that can
be used for the common subset.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to