Hello,
On 6.7.2014 15:26, Stephen Henson via RT wrote:
On Fri Jul 04 20:33:35 2014, pspa...@redhat.com wrote:
[I'm re-sending this e-mail again because I haven't received any reply
and it
didn't appeared neither on http://rt.openssl.org/NoAuth/Buglist.html
nor on
-devel list.]
Attached patch set adds support for key wrapping mode described in RFC
5649.
This mode allows you to wrap keys of any length in range [1, 2^31]
bytes and
does integrity check after unwrapping. It is an extension of original
key
wrapping algorithm described in RFC 3394 (this is already implemented
as
CRYPTO_128_wrap and works only with 64-bit blocks).
This patch set also adds test for RFC 3394 and RFC 5649 functionality.
I tried to fully describe purpose and implementation directly in the
code
comments.
This patch set is re-implementation from scratch and obsoletes patch
attached
to ticket 2204 from year 2010.
I'm new to OpenSSL, thank you for your patience with me.
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?
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
There are also some constructs which I think might cause problems on some
platforms for example .foo = "bar" structure initialisation but that's only in
the test code but that wont matter if the same functionality is added to
Okay, I'm assuming that current test code will be thrown away so I'm not going
to spend more time on it.
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.
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.
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 was looking for some #define from build system but I'm not able to find
anything useful. It seems to me that B_ENDIAN or L_ENDIAN are not *always*
defined.
Thank you for your time!
--
Petr Spacek @ Red Hat
commit 63ae6c9335c2a86cf1cad904baefc610e25d335b
Author: Petr Spacek <pspa...@redhat.com>
Date: Mon Jul 7 09:41:47 2014 +0200
crypto/modes/wrap128.c: fix compilation warnings
diff --git a/crypto/modes/wrap128.c b/crypto/modes/wrap128.c
index 7a0fd2f..705d68f 100644
--- a/crypto/modes/wrap128.c
+++ b/crypto/modes/wrap128.c
@@ -192,7 +192,7 @@ size_t CRYPTO_128_unwrap(void *key, const unsigned char *iv,
unsigned char *out, const unsigned char *in, size_t inlen,
block128_f block)
{
- int ret;
+ size_t ret;
unsigned char got_iv[8];
ret = _CRYPTO_128_unwrap_raw(key, got_iv, out, in, inlen, block);
@@ -288,7 +288,7 @@ int CRYPTO_128_unwrap_withpad(void *key, const unsigned char *icv,
/* RFC 5649 section 3: Alternative Initial Value */
unsigned char aiv[8];
unsigned char zeros[8] = {0x0};
- int ret;
+ size_t ret;
/* Section 4.2: Cipher text length has to be (n+1) 64-bit blocks. */
if ((inlen & 0x7) != 0 || inlen < 16 || inlen >= CRYPTO128_WRAP_MAX)
