unable to find few definitions with Openssl1.0.1e version
HI, I am trying to compile aes ciphers alone to kernel of FREEBSD 8.1 version. I am not able to find the definition of below symbols. Anyone faced this issue? can u guide me to find the definition of these macros? ASN1_BOOLEAN_it ASN1_OBJECT_it BIGNUM_it CBIGNUM_it LONG_it ZLONG_it Thanks Krishna Mohan.
Re: [openssl.org #3117] [PATCH] A fast vectorized implementation of binary elliptic curves on x86-64 processors
Dear Manuel, Exciting news! While your paper still unpublished, could you please advice, it there anything even nearly similar possible for curves over primary fields? (e.g. curves secp* ) Best regards, Andrey On 28 August 2013 09:06, Manuel Bluhm via RT r...@openssl.org wrote: Hello all, This patch is a contribution to OpenSSL. It offers an efficient and constant-time implementation of the elliptic curve point multiplication, for the following standard NIST/SECG binary elliptic curves: sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, and sect571r1. The patch implements several improvements at the algorithmic and the coding levels (using SSE/AVX and PCLMULQDQ instructions). Depending on the curve and architecture, this patch offers a speedup of between 4x to 10x for ECDH and ECDSA, compared to the current implementation of OpenSSL 1.0.1e. Additionally, it adds side channel protection to avoid (cache) timing attacks using a number of mechanisms. The code is written in C and uses compiler intrinsics, for simplicity and portability. The following results were obtained with gcc 4.8.1. For detailed explanations of the rationale and algorithms of this code refer to [1]. ECDH performance -- The performance was measured by using openssl speed utility as follows: $ openssl speed ecdh The results for a Core i7-4770 CPU @ 3.40GHz (Haswell) in ECDH op/s: Curve || OpenSSL 1.0.1e || This patch || Speedup || ||||-||--|| |||| || || (nistk163) ||6586.9 || 67029.6|| 10.18 || (nistk233) ||5121.9 || 39441.3|| 7.70 || (nistk283) ||2825.7 || 27718.5|| 9.81 || (nistk409) ||1745.8 || 11634.2|| 6.66 || (nistk571) || 763.2 || 5930.9|| 7.77 || (nistb163) ||6382.5 || 60729.6|| 9.52 || (nistb233) ||4881.9 || 35230.4|| 7.22 || (nistb283) ||2651.6 || 24456.4|| 9.22 || (nistb409) ||1640.3 || 10228.6|| 6.24 || (nistb571) || 693.8 || 5172.1|| 7.45 || |||| || || ||||-||--|| The results for a Core i5-3210M @ 2.50 GHz (Ivy Bridge) in ECDH op/s: Curve || OpenSSL 1.0.1e || This patch || Speedup || ||||-||--|| |||| || || (nistk163) ||3271.5 || 28087.3|| 8.59 || (nistk233) ||2504.9 || 15106.0|| 6.03 || (nistk283) ||1317.0 || 9030.5|| 6.86 || (nistk409) || 772.1 || 3880.8|| 5.03 || (nistk571) || 327.3 || 1821.1|| 5.56 || (nistb163) ||3067.9 || 24357.1|| 7.94 || (nistb233) ||2424.9 || 3147.3|| 5.42 || (nistb283) ||1227.0 || 7765.1|| 6.33 || (nistb409) || 709.7 || 3319.9|| 4.68 || (nistb571) || 296.2 || 1563.9|| 5.28 || |||| || || ||||-||--|| ECDSA performance -- The performance was measured by using openssl speed utility as follows: $ openssl speed ecdsa The results for a Core i7-4770 CPU @ 3.40GHz (Haswell): Curve || OpenSSL 1.0.1e ||This patch || Speedup || ---||-||---||-|| || sign/s verify/s || sign/s verify/s || sign/s verify/s || ||-||---||-|| (nistk163) || 6,465.3 3,159.5 || 36,872.6 26,508.4 || 5.708.39 || (nistk233) || 3,259.2 2,419.8 || 22,998.4 15,557.1 || 7.066.43 || (nistk283) || 2,204.7 1,355.7 || 16,884.9 11,003.2 || 7.668.12 || (nistk409) || 977.0 839.1 || 8,150.0 4,845.0 || 8.345.77 || (nistk571) || 466.4 368.3 || 4,424.1 2,533.6 || 9.496.88 || (nistb163) || 6,487.3 3,043.9 || 35,110.0 24,904.8 || 5.418.18 || (nistb233) || 3,279.2 2,348.0 || 21,468.8 14,095.6 || 6.556.00 || (nistb283) || 2,196.4 1,283.5 || 15,602.7 9,888.5 || 7.107.70 || (nistb409) || 976.3 786.9 || 7,423.1 4,361.9 || 7.605.54 || (nistb571) || 466.6 341.0 || 3,977.0 2,251.6 || 8.526.60 || || || || || ---||-||---||-|| The results for a Core i5-3210M CPU @ 2.50 GHz (Ivy Bridge): Curve
RE: [openssl.org #3120] Minimum size of DH
From: owner-openssl-...@openssl.org On Behalf Of Kurt Roeckx via RT Sent: Saturday, 31 August, 2013 12:54 It seems that s_server by default use 512 bit for the DHE if it's not specified, and s_client just accepts that. Is there a way to set a minimum size? I think think 512 really is too short and shouldn't be accepted by any client. I think we should have a minimum of 1024. OpenSSL deliberately continues to support (mostly older) features like SSL2 and export suites that are known weak or vulnerable (at least sometimes) for interoperability. It might be reasonable to have an *optional* minimum, similar to the way we can optionally limit verify depth. OTOH at least for now sess-sess_cert-peer_dh_tmp is exposed and the app can just decide to abort the session. Same as it can for RSA or DSA too short, or MD5 certs, or if you're more ambitious things like RSA that appears to be a Debian broken-random weak key. I think a best-practice default of 1024 for s_server would be better (it uses p-256 for ecdh_tmp which is good), but at least it is test code and has an option for better. Java (or rather JSSE) server uses 768 and can't be fixed :-( __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: UTF8 decoding, unneeded byte masking
From: David Jacobson [mailto:dmjacob...@sbcglobal.net] Sent: Tuesday, 27 August, 2013 23:28 On 8/27/13 1:33 AM, Dave Thompson wrote: From: owner-openssl-...@openssl.org On Behalf Of Yuan Kang Sent: Tuesday, 27 August, 2013 00:54 I don't think that it is true that (signed char)(*p) = 0 is always true, snip Mr Weimer didn't say it IS always true, he said a compiler IS ALLOWED TO ASSUME it is. As I adjusted, the compiler does have to document that it does this. I don't know who would issue such rules, or who would enforce them. The C standard is issued basically by ISO and national bodies like ANSI. (If you want more details I can give them, but most people don't care.) No authority enforces it, but there are reports of people using it in private contracts. Mostly implementors who want to support portable C programming, and programmers who want to write such, obey voluntarily. Whether a given compiler does it depends on the writers of that compiler, and quite likely on the target architecture, and quite possibly on the optimizations implemented by the compiler and used. As I added, gcc (at least the versions I have) documents that it doesn't do so. I really doubt that. Look in info at C Implementations Integers Implementation. Here is (from memory) a code snippet I tested on gcc snip: addition wraparound of 'tested-positive' (signed) int's with -O2 or higher thinks negative is positive The fact that the value of an operation with signed arithmetic that overflows (the + operator) is undefined, and the result of and operation where at least one operand is undefined (the operator), is Almost. In the standard, overflow of signed* arithmetic is Undefined Behavior (UB), a term defined in subclause 3.4.3: 1 undefined behavior behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements 2 NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). 3 EXAMPLE An example of undefined behavior is the behavior on integer overflow. This means there doesn't have to be any value to ; one realistic possibility is that + traps (which gcc can with -ftrapv). The standard allows anything at all, and the canonical example on comp.lang.c is that UB makes demons fly out your nose but this is rarely implemented G. * 'signed' here is limited to signed integers. The standard says unsigned integer computation wraps-around instead of overflowing, so when 3.4.3p3 says 'integer overflow' it only means signed. Judging from c.l.c, many people think of unsigned integers as overflowing and then wrapping-around to 'fix' the overflow; that kind of 'overflow' isn't UB. Floating-point is mathematically signed, but not labelled signed in C because there is no unsigned floating-point to distinguish; FP overflow may be UB but if the implementation implements IEC 60559 aka IEEE 754 -- which most CPUs and many compilers today do -- then FP overflow is well-defined. undefined. That allows the compiler to reason using ordinary mathematical operations rather than computer operations. [and deduce that nonneg+nonneg must be nonneg, unless -fwrapv] That's what gcc does in this UB case, and it's a reasonable choice, but not the only possible or allowed one. But the issue upthread was *conversion*, not arithmetic. That is covered by a different subclause in the standard, and is not labelled overflow; there is no convenient standard term, so I used out-of-range. The result of out-of-range narrowing to signed integer is Implementation Defined (ID), which is much more constrained than UB: there must be a value, and that value must be documented by the implementation -- which gcc does, as above. But the value need not be the same across implementations, so portable code can't rely on it. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
