On 7.7.2014 16:16, Stephen Henson via RT wrote:
> On Mon Jul 07 10:31:21 2014, [email protected] wrote:
>> In the previous e-mail you were talking about integration into EVP. Do
>> I
>> understand correctly that I should fix those "low-level" patches and
>> you will
>> integrate them to EVP?
>>
>
> Yes I'll handle that side. It's not too hard but tricky if you're unfamiliar
> with EVP.
>
>>> There are a few problems with the patches as supplied. There are
>> several
>>> warnings when use the --strict-warnings option to see what they are.
>> I'm attaching patch to fix them, I hope I didn't miss anything.
>>
>> I have pushed the same patch to:
>>
> https://github.com/spacekpe/openssl/commit/63ae6c9335c2a86cf1cad904baefc610e25d335b
>>
>
> OK thanks I'll review that.
>
>>
>>> evp_test.c .I'm not sure how portable uiint32_t is either.
>> AFAIK it is part of C99. 'grep' told me that it was used in bio/bio.h
>> so I
>> took inspiration from there.
>>
>> I can re-write it as necessary but I would like to know which way do
>> you prefer?
>>
>> Unfortunately, I wasn't able to find universal uint32 equivalent used
>> across
>> code base.
>>
>
> The part in bio.h is surrounded by #ifndef OPENSSL_NO_SCTP and no-sctp (which
> sets that define) is the default so that part by default isn't compiled.
>
> If you require a type that is unsigned and guaranteed to be at least 32 bits
> then unsigned int will work but that might not be necessary, I'll check how
> you
> are using it.
Thanks. I need exactly 32 bits to encode/decode IV+data length. (RFC 5649
combines IV and data length in one 32 bit field.)
>>> I think we should avoid having a htonl dependency in the code if
>> possible. It's
>>> not hard to avoid that.
>> Sure, I can avoid that, I simply took inspiration from
>> crypto/bio/b_sock.c.
>>
>
> Well OpenSSL is sometimes compiled and used in places without socket support
> and I wouldn't like to have a socket dependency in the cipher code.
Understood. I will be rework patches as necessary.
>> What is the preferred way for this case?
>>
>> I have seen construction like
>> const union { long one; char little; } is_endian = {1};
>> if (is_endian.little)
>> ...
>>
>> couple times in the code. Is this the preferred way?
>>
>
> I'm not sure there is a preferred way as such. In a few places combinations of
> shifts and bitwise operations are used between an unsigned int and a four byte
> array.
>
> I'll have a look to see what seems appropriate in this case.
I will be really glad if you could recommend me approach appropriate for this
case.
Thank you for your time!
--
Petr Spacek @ Red Hat
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
