[openssl-dev] [openssl.org #4456] Fedora 1, i386: error: field `next_timeout` has incomplete type
On Tue May 31 16:49:23 2016, rsalz wrote: > Re-Ping Jeff to take a look and see if things are fixed now. Ping Jeff. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4456 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4479] OS X 10.8 (x86_64): Compile errors when using "no-asm -ansi"
Status as per ticket 4480. Closing this ticket. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4479 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4480] Ubuntu 14 (x86_64): Compile errors and warnings when using "no-asm -ansi"
I applied the original roll up patch. I wasn't keen on adding all the __STRICT_ANSI__ ifdefs from the later patch. That seems excessive to me for little benefit - we are generally trying to reduce the ifdef code as much as possible. I also didn't add the __WORDSIZE bit. I believe that symbol is an internal compiler symbol and shouldn't be used. Closing this ticket. Thanks for the patch. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4480 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4434] Gentoo 13, x86_64: 4 failed self tests
On Wed Jun 01 22:20:38 2016, matt wrote: > Hi Jeff > > Please could you try the attached patch? Any update on this? Thanks Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4434 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4329] OpenSSL 1.1.0 pre3: internal error in tls_post_process_client_key_exchange during reneg
On Tue May 24 13:53:07 2016, steve wrote: > On Sun Feb 21 13:55:35 2016, rainer.j...@kippdata.de wrote: > > Running the Apache test suite for Apache 2.4 with OpenSSL 1.1.0 > > adjustments, I get > > > > Can you please check to see if this issue is still present in the latest > OpenSSL 1.1.0? Hi Rainer Can this ticket be closed now? Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4329 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Making assembly language optimizations working onCortex-M3
> That's usually true, but the topic of this thread is about how to get OpenSSL > working well on Cortex-M microcontrollers. In those situations, we cannot > really afford the dynamic detection or the many different implementations of > the same algorithm to exist in the final image. Other trade-offs to consider are the work involved and the ongoing maintenance, and to make sure that no other platforms become "pessimized." You know guys know this, but want to make it explicit to the list. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Notes on stitched AESNI-GCM implementation details
In the course of reviewing the code for the stitched AESNI-GCM code, a group of people found it difficult to understand some aspects of how the code works. After spending some time studying the code, I wrote these notes: https://boringssl.googlesource.com/boringssl/+/2477adcf6236c3040a291ad1bfd53f525e1af96d%5E%21/ Feel free to incorporate these notes into OpenSSL if you find them useful. Cheers, Brian -- https://briansmith.org/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Removing gcm128_context->H for non-1-bit builds
On Wed, Jun 8, 2016 at 12:40 AM, Andy Polyakov wrote: >> I noticed that the `H` member of `gcm128_context` seems to be >> unnecessary for builds that aren't using the 1-bit GCM math. > > Not true. It is actually used in s390x assembly module. And I mean both > H and Htable. I see. I admit I didn't look at the s390x code, mostly because I can't fit one in my small apartment. >> Could somebody adjust who understand the assembly code (probably Andy) >> modify it to use symbolic names for the offsets that are used to >> access Xi, H, Htable? If so, then I can write the patch to >> conditionally exclude `H` on platforms that don't need it after >> `CRYPTO_gcm128_init` finishes executing. > But going the > line of taking into consideration all corner cases is a stretch and > should be weighed against 16 out of ~380[!] bytes waste. I'd say it's > not worth it. I see it both as an *optimization* and also a way to ensure *correctness*. In particular, if the code doesn't expect H to be there in configurations that don't use H, then some tricks that people might use (in particular, a trick I am using) becomes safer. In particular, notice that in the gcm128_context structure, there are three kinds of state (again, only talking about non-s390x, non-1-bit platforms): 1. State that is only used in the _init function: H. 2. State that needs to be preserved in between authenticated-and-encrypted messages. This is `Htable`, `EK0`, `gmult`, `ghash`, `block`, etc. 3. State that needs to be preserved only between the time you start an authenticated-and-encrypted message and the time you end it. This includes `len`, `EKi`, `mres`, `ares`, etc. currently. In theory this could also include `gmult`, `ghash` and `block`, if the code were refactored to recomputed them for each message and/or if things like the OPENSSL_STATIC_ARMCAP-type optimization allowed one to omit them from the structure completely in some configurations where there is no way they could vary at runtime. Also, Htable is 256 bytes on its own (on the platforms I care about), but actually in some platforms/configurations not all of Htable is used. In my code, after I call the _init function, I extract out all the numbers in category #2 and store them in my per-connection context structure on. Then, when I need to encrypt/decrypt a message, I construct a full gcm128_context *on the stack*, zero it out, and then fill in the values from category #2. Then I encrypt/decrypt the message, and then throw away the gcm128_context. > One can argue that "the most popular embedded three-letter > platform" deserves this 4% space optimization [by being so popular], but > then question would be if OpenSSL can actually execute in such > constrained environment where 4% per GCM context (i.e. something that > itself is percentage of something else) makes a difference. Aren't we > likely to be talking about ripping out single component and using in the > said environment? But then question is why this specific case would have > to complicate maintenance for OpenSSL as whole? In other words, there are *lots* of bytes in gcm128_context that could be thrown away in between messages, if one really needed to save memory. And then the size of `H` does matter quite a bit more as a percentage of the size of this inter-message state. And, also, whether or not `H` belongs in category #1 or category #2 is important for correctness. Thus, my suggestion in this thread is an attempt to clarify the code to make it more obvious that it is in category #2 (besides 1-bit-mult and s390x platforms). Note, in contrast, Poly1305 only requires 32 bytes of state to be preserved between messages. My goal is to bring the GCM inter-message state storage requirements closer to this 32 bytes. > However, I can tell that assembly module > for "the most popular embedded three-letter platform" does *not* depend > on relative position of Xi, H and Htable. One can *probably* discuss > that it would be appropriate to *facilitate* omission of H in context > *other than* OpenSSL by avoiding H during most of the setup procedure. > See attached patch for example. But do note that I'm not saying that it > works or suggesting to include it right away, I only want to show what > *might* be matter of discussion. Nice. Thanks for the patch. That is actually very similar to what I've done in my experiments. But, I was also trying to get it to work on x86 and x86-64, where the relative position does matter. The x86/x86-64 code is where I got confused about the math in the assembler modules. >> Also, I wonder how important it is to keep the 1-bit math code? > > Look at it as insurance. The moment they come and say table-driven > approach is no-go, we have 1-bit code to switch to. Understood. Thanks a ton! Cheers, Brian -- https://briansmith.org/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Removing gcm128_context->H for non-1-bit builds
> One can *probably* discuss
> that it would be appropriate to *facilitate* omission of H in context
> *other than* OpenSSL by avoiding H during most of the setup procedure.
> See attached patch for example. But do note that I'm not saying that it
> works or suggesting to include it right away, I only want to show what
> *might* be matter of discussion.
Missed the patch...
diff --git a/crypto/modes/gcm128.c b/crypto/modes/gcm128.c
index df9f654..e26651d 100644
--- a/crypto/modes/gcm128.c
+++ b/crypto/modes/gcm128.c
@@ -721,24 +721,24 @@ void CRYPTO_gcm128_init(GCM128_CONTEXT *ctx, void *key, block128_f block)
ctx->block = block;
ctx->key = key;
-(*block) (ctx->H.c, ctx->H.c, key);
+(*block) (ctx->Xi.c, ctx->Xi.c, key);
if (is_endian.little) {
/* H is stored in host byte order */
#ifdef BSWAP8
-ctx->H.u[0] = BSWAP8(ctx->H.u[0]);
-ctx->H.u[1] = BSWAP8(ctx->H.u[1]);
+ctx->Xi.u[0] = BSWAP8(ctx->Xi.u[0]);
+ctx->Xi.u[1] = BSWAP8(ctx->Xi.u[1]);
#else
-u8 *p = ctx->H.c;
+u8 *p = ctx->Xi.c;
u64 hi, lo;
hi = (u64)GETU32(p) << 32 | GETU32(p + 4);
lo = (u64)GETU32(p + 8) << 32 | GETU32(p + 12);
-ctx->H.u[0] = hi;
-ctx->H.u[1] = lo;
+ctx->Xi.u[0] = hi;
+ctx->Xi.u[1] = lo;
#endif
}
#if TABLE_BITS==8
-gcm_init_8bit(ctx->Htable, ctx->H.u);
+gcm_init_8bit(ctx->Htable, ctx->Xi.u);
#elif TABLE_BITS==4
# ifdefined(GHASH)
# define CTX__GHASH(f) (ctx->ghash = (f))
@@ -750,18 +750,18 @@ void CRYPTO_gcm128_init(GCM128_CONTEXT *ctx, void *key, block128_f block)
if (OPENSSL_ia32cap_P[0] & (1 << 24) && /* check FXSR bit */
OPENSSL_ia32cap_P[1] & (1 << 1)) { /* check PCLMULQDQ bit */
if (((OPENSSL_ia32cap_P[1] >> 22) & 0x41) == 0x41) { /* AVX+MOVBE */
-gcm_init_avx(ctx->Htable, ctx->H.u);
+gcm_init_avx(ctx->Htable, ctx->Xi.u);
ctx->gmult = gcm_gmult_avx;
CTX__GHASH(gcm_ghash_avx);
} else {
-gcm_init_clmul(ctx->Htable, ctx->H.u);
+gcm_init_clmul(ctx->Htable, ctx->Xi.u);
ctx->gmult = gcm_gmult_clmul;
CTX__GHASH(gcm_ghash_clmul);
}
return;
}
# endif
-gcm_init_4bit(ctx->Htable, ctx->H.u);
+gcm_init_4bit(ctx->Htable, ctx->Xi.u);
# if defined(GHASH_ASM_X86) /* x86 only */
# if defined(OPENSSL_IA32_SSE2)
if (OPENSSL_ia32cap_P[0] & (1 << 25)) { /* check SSE bit */
@@ -781,48 +781,52 @@ void CRYPTO_gcm128_init(GCM128_CONTEXT *ctx, void *key, block128_f block)
# elif defined(GHASH_ASM_ARM)
# ifdef PMULL_CAPABLE
if (PMULL_CAPABLE) {
-gcm_init_v8(ctx->Htable, ctx->H.u);
+gcm_init_v8(ctx->Htable, ctx->Xi.u);
ctx->gmult = gcm_gmult_v8;
CTX__GHASH(gcm_ghash_v8);
} else
# endif
# ifdef NEON_CAPABLE
if (NEON_CAPABLE) {
-gcm_init_neon(ctx->Htable, ctx->H.u);
+gcm_init_neon(ctx->Htable, ctx->Xi.u);
ctx->gmult = gcm_gmult_neon;
CTX__GHASH(gcm_ghash_neon);
} else
# endif
{
-gcm_init_4bit(ctx->Htable, ctx->H.u);
+gcm_init_4bit(ctx->Htable, ctx->Xi.u);
ctx->gmult = gcm_gmult_4bit;
CTX__GHASH(gcm_ghash_4bit);
}
# elif defined(GHASH_ASM_SPARC)
if (OPENSSL_sparcv9cap_P[0] & SPARCV9_VIS3) {
-gcm_init_vis3(ctx->Htable, ctx->H.u);
+gcm_init_vis3(ctx->Htable, ctx->Xi.u);
ctx->gmult = gcm_gmult_vis3;
CTX__GHASH(gcm_ghash_vis3);
} else {
-gcm_init_4bit(ctx->Htable, ctx->H.u);
+gcm_init_4bit(ctx->Htable, ctx->Xi.u);
ctx->gmult = gcm_gmult_4bit;
CTX__GHASH(gcm_ghash_4bit);
}
# elif defined(GHASH_ASM_PPC)
if (OPENSSL_ppccap_P & PPC_CRYPTO207) {
-gcm_init_p8(ctx->Htable, ctx->H.u);
+gcm_init_p8(ctx->Htable, ctx->Xi.u);
ctx->gmult = gcm_gmult_p8;
CTX__GHASH(gcm_ghash_p8);
} else {
-gcm_init_4bit(ctx->Htable, ctx->H.u);
+gcm_init_4bit(ctx->Htable, ctx->Xi.u);
ctx->gmult = gcm_gmult_4bit;
CTX__GHASH(gcm_ghash_4bit);
}
# else
-gcm_init_4bit(ctx->Htable, ctx->H.u);
+gcm_init_4bit(ctx->Htable, ctx->Xi.u);
# endif
# undef CTX__GHASH
#endif
+ctx->H.u[0] = ctx->Xi.u[0];
+ctx->H.u[1] = ctx->Xi.u[1];
+ctx->Xi.u[0] = 0;
+ctx->Xi.u[1] = 0;
}
void CRYPTO_gcm128_setiv(GCM128_CONTEXT *ctx, const unsigned char *iv,
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Removing gcm128_context->H for non-1-bit builds
> I noticed that the `H` member of `gcm128_context` seems to be > unnecessary for builds that aren't using the 1-bit GCM math. Since > this member is large (128-bits) and some applications may have lots of > GCM contexts relative to the amount of memory they have, I think it > would be great to only put the `H` member into the structure when the > 1-bit math is used. Not true. It is actually used in s390x assembly module. And I mean both H and Htable. This is because hardware-assisted single multiplication is not faster than pure software. In practical terms it means that Htable is used when you need to perform single multiplication, and H is used when you process multiple input blocks in one go. > I tried to write a patch to do this myself, but I got stuck, because > the assembly language code does pointer math assuming that the `H` > member (which it doesn't use, AFAICT) is there. And, I can't quite > understand the assembly language code well enough to adjust all the > offsets to make the code work with `H` removed. > > Could somebody adjust who understand the assembly code (probably Andy) > modify it to use symbolic names for the offsets that are used to > access Xi, H, Htable? If so, then I can write the patch to > conditionally exclude `H` on platforms that don't need it after > `CRYPTO_gcm128_init` finishes executing. In cases other than s390x it's likely to be optimization thing. I mean as you tend to use all the registers you are likely to find it beneficial to discard Xi and use Htable to address both. But going the line of taking into consideration all corner cases is a stretch and should be weighed against 16 out of ~380[!] bytes waste. I'd say it's not worth it. One can argue that "the most popular embedded three-letter platform" deserves this 4% space optimization [by being so popular], but then question would be if OpenSSL can actually execute in such constrained environment where 4% per GCM context (i.e. something that itself is percentage of something else) makes a difference. Aren't we likely to be talking about ripping out single component and using in the said environment? But then question is why this specific case would have to complicate maintenance for OpenSSL as whole? In other words I'd vote for saying no to omitting H. However, I can tell that assembly module for "the most popular embedded three-letter platform" does *not* depend on relative position of Xi, H and Htable. One can *probably* discuss that it would be appropriate to *facilitate* omission of H in context *other than* OpenSSL by avoiding H during most of the setup procedure. See attached patch for example. But do note that I'm not saying that it works or suggesting to include it right away, I only want to show what *might* be matter of discussion. > Also, I wonder how important it is to keep the 1-bit math code? Look at it as insurance. The moment they come and say table-driven approach is no-go, we have 1-bit code to switch to. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4496] [PATCH] ssl_cert: use the recommended minimum hash from RFC 5480 for EC
On 08/06/16 11:25, Hubert Kario wrote: > On Tuesday 07 June 2016 19:22:00 Matt Caswell via RT wrote: >> On Sat Apr 02 14:05:50 2016, sebast...@breakpoint.cc wrote: >>> A TLS1.2 connetion with openssl server and gnutls-cli using a >>> SECP384R1 >>> key ends up with SHA256 as the hash algorithm for signing the key >>> exchange. >>> This is because gnutls sends the hash algorithms from weak to strong >>> and by default client's preference is used. >>> >>> gnutls complains about this situation: >>> |<1>| The hash size used in signature (32) is less than the expected >>> (48) > > it complains, but does it abort connection? FYI, there is a (long!) discussion on this issue here: https://github.com/openssl/openssl/pull/1046 Matt signature.asc Description: OpenPGP digital signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4496] [PATCH] ssl_cert: use the recommended minimum hash from RFC 5480 for EC
On Tuesday 07 June 2016 19:22:00 Matt Caswell via RT wrote: > On Sat Apr 02 14:05:50 2016, sebast...@breakpoint.cc wrote: > > A TLS1.2 connetion with openssl server and gnutls-cli using a > > SECP384R1 > > key ends up with SHA256 as the hash algorithm for signing the key > > exchange. > > This is because gnutls sends the hash algorithms from weak to strong > > and by default client's preference is used. > > > > gnutls complains about this situation: > > |<1>| The hash size used in signature (32) is less than the expected > > (48) it complains, but does it abort connection? -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Why is `volatile` used in MOD_EXP_CTIME_COPY_FROM_PREBUF?
>>> See >>> https://github.com/openssl/openssl/commit/d6482a82bc2228327aa4ba98aeeecd9979542a31#diff-3aca3afd18ad75a8f6a09a9860bc6ef5R631 >>> >>> + volatile BN_ULONG *table = (volatile BN_ULONG *)buf; >>> >>> Why is `volatile` used here? Is it to work around the effective type >>> (strict aliasing) violations or for some other reason? >> >> Isn't it obvious? Volatile is there to discourage compiler from >> reordering loads from the the table. I mean concern is that if reordered >> in specific manner loads might give away the information we are trying >> to conceal. > > Sorry, maybe these things are obvious to many people but they're not > so obvious to me. I saw that after I posted this email, you added a > comment that says something similar to what you wrote above. But, just > to be absolutely clear: the concern is that the compiler might notice, > "hey, this code is scanning this input array in a weird way. I can > redo the math (in a way that will result in non-constant-time-access > to the buffers containing secrets) so that this is much faster." So, > maybe, it is not so much the order of the accesses that matter, but > rather that the compiler might choose to do different math that > arrives at the same results, but with different timing? Well, it's all about timing *variation* depending on attacker's activity. But it's not really about making timing independent on attacker's activity, but making it independent on secret material. I mean it *may* depend on attacker's activity, but this whichever dependency may not depend on secret material. And it may not depend on it during operation either. I mean it's not enough to make overall time independent, but even each intermediate step. 'volatile' formally obliges compiler to actually perform all the references (none can be omitted, that would be catastrophic scenario) and even preserve their order (concern is that compiler would regroup in manner that would allow attacker to trace the execution which in turn might give away information). -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
