Re: [openssl-dev] sizeof (HMAC_CTX) changes with update, breaks binary compatibility
On Thu, 11 Jun 2015 21:09:59 -0400
Dan McDonald dan...@omniti.com wrote:
On Jun 11, 2015, at 9:07 PM, Dan McDonald dan...@omniti.com wrote:
typedef struct hmac_ctx_st {
const EVP_MD *md;
EVP_MD_CTX md_ctx;
EVP_MD_CTX i_ctx;
EVP_MD_CTX o_ctx;
unsigned int key_length;
unsigned char key[HMAC_MAX_MD_CBLOCK];
+ int key_init;
} HMAC_CTX;
A cheesy, but binary compatible, fix might be:
typedef struct hmac_ctx_st {
const EVP_MD *md;
EVP_MD_CTX md_ctx;
EVP_MD_CTX i_ctx;
EVP_MD_CTX o_ctx;
unsigned int key_init:1; /* Ewww, cheesy use of bitfields... */
unsigned int key_length:31; /* but the sizeof (HMAC_CTX) doesn't
change! */ unsigned char key[HMAC_MAX_MD_CBLOCK];
} HMAC_CTX;
Why is separate key_init needid? Could we not use md!=NULL or
key_length!=0 checks to see if the context is initialized?
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] sizeof (HMAC_CTX) changes with update, breaks binary compatibility
On Fri, 12 Jun 2015 10:38:02 +0100
Matt Caswell m...@openssl.org wrote:
On 12/06/15 09:49, Timo Teras wrote:
On Fri, 12 Jun 2015 11:27:42 +0300
Timo Teras timo.te...@iki.fi wrote:
On Thu, 11 Jun 2015 21:09:59 -0400
Dan McDonald dan...@omniti.com wrote:
On Jun 11, 2015, at 9:07 PM, Dan McDonald dan...@omniti.com
wrote:
typedef struct hmac_ctx_st {
const EVP_MD *md;
EVP_MD_CTX md_ctx;
EVP_MD_CTX i_ctx;
EVP_MD_CTX o_ctx;
unsigned int key_length;
unsigned char key[HMAC_MAX_MD_CBLOCK];
+ int key_init;
} HMAC_CTX;
A cheesy, but binary compatible, fix might be:
typedef struct hmac_ctx_st {
const EVP_MD *md;
EVP_MD_CTX md_ctx;
EVP_MD_CTX i_ctx;
EVP_MD_CTX o_ctx;
unsigned int key_init:1; /* Ewww, cheesy use of bitfields...
*/ unsigned int key_length:31; /* but the sizeof (HMAC_CTX)
doesn't change! */ unsigned char key[HMAC_MAX_MD_CBLOCK];
} HMAC_CTX;
Why is separate key_init needid? Could we not use md!=NULL or
key_length!=0 checks to see if the context is initialized?
Seems it'd be along with the line to just use key_length instead.
Something along the lines of:
Your patch does introduce a change in behaviour if key != NULL but len
== 0. Previously this would set ctx-key to all 0s, and key_init to 1,
and would then continue to use that all zero key. A subsequent
invocation of HMAC_Init_ex with key == NULL would reuse that all zero
key. Your patch would allow the first invocation, but error out on the
second.
Should it be a valid use case to allow an all zero key in this way?
This raises another concern. If md is changed, but key is not, things
go wrong anyway. I think we should just disallow chaning md without
key.
The problem is that if md is changed, we need to rehash using the new
md (in case they key = HMAC_MAX_MD_CBLOCK). This was not allowed
earlier. So let's just require specifying key if md changes.
We can in fact remove using key_length altogether then. I think
key_length should be assigned to EVP_MD_block_size(md) always. Because
they key is technically zero-padded anyway to this length.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] The evolution of the 'master' branch
On Tue, 3 Feb 2015 17:02:31 -0500 Rich Salz rs...@openssl.org wrote: As we've already said, we are moving to making most OpenSSL data structures opaque. We deliberately used a non-specific term. :) As of Matt's commit of the other day, this is starting to happen now. We know this will inconvenience people as some applications no longer build. We want to work with maintainers to help them migrate, as we head down this path. We have a wiki page to discuss this effort. It will eventually include tips on migration, application and code updates, and anything else the community finds useful. Please visit: http://wiki.openssl.org/index.php/1.1_API_Changes Not sure if my questions are already answered. But I'll go ahead and ask them... Which structures this includes? I'm thinking application level extensibility. If I have a custom cipher implementation, and it requires shipping EVP_CIPHER (which is basically virtual ops table). Is that planned to be opaque too? Or it gets a set of accessors? How would off-tree engine modules be implemented? Or is their integration possibilities limited? Or would there be the public headers for applications? And than the private headers for version bound extensions that need to access the internals? Thanks, Timo ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl.org #3505] rewrite c_rehash in C
On Tue, 26 Aug 2014 12:50:49 -0400 Salz, Rich rs...@akamai.com wrote: Don't rush. It'll be a while until (or if) we switch over. Neat job tho. Perhaps it should be merged into the openssl command? (see https://github.com/akamai/openssl/tree/rsalz-monolith) I wrote the code about 8 months ago - and did not bother to file a ticket until I saw the other ticket about shell c_rehash. I just wanted to polish the code to the point that it would be acceptable. And exactly this feedback is what I sought for. Yes, making it an openssl subcommand would make sense (assuming it supports c_rehash symlink too). I'll give some additional thought for this approach. Thanks, Timo __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3505] rewrite c_rehash in C
On Tue, 26 Aug 2014 17:19:24 + Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Tue, Aug 26, 2014 at 10:12:06AM -0400, Salz, Rich wrote: Find a C version (which I have written) of the utility at: http://git.alpinelinux.org/cgit/aports/plain/main/openssl/c_rehash.c That's pretty cool. We'd need to modify it to not use the XXXat functions or fnmatch, but definitely something we should consider for a future release. Does this version fix the atomicity problems of the original? The Perl version deletes all the symlinks and then rebuilds them, leaving a time window during which verification fails. The algorithm should be improved to never delete links which are subsequently recreated. I almost answered it's fixed. But it's not. IIRC, the version had it fixed, but it did not handle hash collisions nicely. This certainly is possibly to do, but needs some extra care when there's collisions and the entries need renaming instead of deletion. The time window is certainly a lot less in C-version, but it still exists. I'll look into fixing this too. Thanks. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2291] [PATCH 3/3] engine/padlock: implement sha1/sha224/sha256 acceleration
Seems this patch was 'taken' recently. I have few bugs fixed in the
Padlock patch series. And versions against multiple major versions.
The latest version of this specific patch is at:
http://git.alpinelinux.org/cgit/aports/plain/main/openssl/0003-engines-e_padlock-implement-sha1-sha224-sha256-accel.patch
- Timo
On Wed, 9 Jun 2010 15:51:00 +0200 (CEST)
Timo Teräs via RT r...@openssl.org wrote:
Limited support for VIA C7 that works only when
EVP_MD_CTX_FLAG_ONESHOT is used appropriately (as done by EVP_Digest,
and my previous HMAC patch).
Full support for VIA Nano including partial transformation.
Benchmarks from VIA Nano 1.6GHz, done with including the previous
HMAC and apps/speed patches done. From single run, error margin of
about 100-200k.
No padlock
type 16 bytes 64 bytes256 bytes 1024 bytes 8192
bytes sha1 20057.60k51514.05k99721.39k 130167.81k
142811.14k sha2567757.72k16907.18k28937.05k
35181.23k37568.51k hmac(sha1)8582.53k27644.69k
70402.30k 114602.67k 140167.85k
With the patch
sha1 37713.77k 114562.71k 259637.33k 379907.41k
438818.13k sha256 34262.86k 103233.75k 232476.07k
338386.60k 389860.01k hmac(sha1)8424.70k31475.11k
104036.10k 245559.30k 406667.26k ---
engines/e_padlock.c | 596
+++ 1 files changed,
553 insertions(+), 43 deletions(-)
diff --git a/engines/e_padlock.c b/engines/e_padlock.c
index 381a746..2f8c72a 100644
--- a/engines/e_padlock.c
+++ b/engines/e_padlock.c
@@ -3,6 +3,9 @@
* Written by Michal Ludvig mic...@logix.cz
*http://www.logix.cz/michal
*
+ * SHA support by Timo Teras timo.te...@iki.fi. Portions based on
+ * code originally written by Michal Ludvig.
+ *
* Big thanks to Andy Polyakov for a help with optimization,
* assembler fixes, port to MS Windows and a lot of other
* valuable work on this engine!
@@ -74,12 +77,23 @@
#ifndef OPENSSL_NO_AES
#include openssl/aes.h
#endif
+#ifndef OPENSSL_NO_SHA
+#include openssl/sha.h
+#endif
#include openssl/rand.h
#include openssl/err.h
#ifndef OPENSSL_NO_HW
#ifndef OPENSSL_NO_HW_PADLOCK
+/* PadLock RNG is disabled by default */
+#define PADLOCK_NO_RNG 1
+
+/* No ASM routines for SHA in MSC yet */
+#ifdef _MSC_VER
+#define OPENSSL_NO_SHA
+#endif
+
/* Attempt to have a single source for both 0.9.7 and 0.9.8 :-) */
#if (OPENSSL_VERSION_NUMBER = 0x00908000L)
# ifndef OPENSSL_NO_DYNAMIC_ENGINE
@@ -140,58 +154,40 @@ static int padlock_available(void);
static int padlock_init(ENGINE *e);
/* RNG Stuff */
+#ifndef PADLOCK_NO_RNG
static RAND_METHOD padlock_rand;
-
-/* Cipher Stuff */
-#ifndef OPENSSL_NO_AES
-static int padlock_ciphers(ENGINE *e, const EVP_CIPHER **cipher,
const int **nids, int nid); #endif
/* Engine names */
static const char *padlock_id = padlock;
static char padlock_name[100];
-/* Available features */
-static int padlock_use_ace = 0; /* Advanced Cryptography
Engine */ -static int padlock_use_rng = 0;/* Random Number
Generator */ -#ifndef OPENSSL_NO_AES
-static int padlock_aes_align_required = 1;
-#endif
+static int padlock_bind_helper(ENGINE *e);
-/* = Engine management functions = */
-
-/* Prepare the ENGINE structure for registration */
-static int
-padlock_bind_helper(ENGINE *e)
-{
- /* Check available features */
- padlock_available();
-
-#if 1/* disable RNG for now, see commentary in vicinity of
RNG code */
- padlock_use_rng=0;
-#endif
-
- /* Generate a nice engine name with available features */
- BIO_snprintf(padlock_name, sizeof(padlock_name),
- VIA PadLock (%s, %s),
- padlock_use_rng ? RNG : no-RNG,
- padlock_use_ace ? ACE : no-ACE);
+ /* Available features */
+enum padlock_flags {
+ PADLOCK_RNG = 0x01,
+ PADLOCK_ACE = 0x02,
+ PADLOCK_ACE2 = 0x04,
+ PADLOCK_PHE = 0x08,
+ PADLOCK_PMM = 0x10,
+ PADLOCK_NANO = 0x20,
+};
+enum padlock_flags padlock_flags;
- /* Register everything or return with an error */
- if (!ENGINE_set_id(e, padlock_id) ||
- !ENGINE_set_name(e, padlock_name) ||
+#define PADLOCK_HAVE_RNG (padlock_flags PADLOCK_RNG)
+#define PADLOCK_HAVE_ACE (padlock_flags
(PADLOCK_ACE|PADLOCK_ACE2)) +#define PADLOCK_HAVE_ACE1 (padlock_flags
PADLOCK_ACE) +#define PADLOCK_HAVE_ACE2 (padlock_flags
PADLOCK_ACE2) +#define PADLOCK_HAVE_PHE (padlock_flags PADLOCK_PHE)
+#define PADLOCK_HAVE_PMM (padlock_flags PADLOCK_PMM)
+#define PADLOCK_HAVE_NANO (padlock_flags PADLOCK_NANO)
- !ENGINE_set_init_function(e, padlock_init) ||
#ifndef OPENSSL_NO_AES
- (padlock_use_ace !ENGINE_set_ciphers (e,
padlock_ciphers)) || +static int padlock_aes_align_required = 1;
#endif
- (padlock_use_rng !ENGINE_set_RAND (e
