Hi,
> This patch is a contribution to OpenSSL.
> It demonstrates an efficient implementation of AES-XTS, using Intel's
> AES-NI and AVX architecture.
> The performance improvement provided here is achieved via: a slightly
> improved reduction technique,
For reference. Criteria for instruction cho
Hi,
> Would you consider adding support for RFC6698 Domain Authentication of
> Named Entities (DANE) Transport Layer Association within OpenSSL to
> facilitate the wide spread adoption of this technology.
There is initial support committed to 1.0.2 branch. This goes against
usual practice of de
> Looks like this goes with bug #2963 ("Windows build bug (perl/nasm
> race) on OpenSSL 1.0.0c").
>
> Other .pl files were fixed, but this one was somehow missed.
Always check repository or snapshots. This was reported and fixed a
while ago.
Hi, and thanks for report!
> I got a strange bug report claiming that "openssl md5" was dumping core on
> old parisc hardware. Sure enough, it was generating the correct result
> but then crashing:
>
> $ openssl md5 /dev/null
> MD5(/dev/null)= d41d8cd98f00b204e9800998ecf8427e
> Segmentatio
> For FreeBSD 10 we have changed /usr/lib/libc.so to be a text linker
> script and no longer a symlink. This breaks the config check on i386 for
> what binary format to use when building with ASM support. The current
> config check expects /usr/lib/libc.so to symlink to a /usr/lib/libc.so.X
> file
>> It's perplexing that it went unnoticed for this long. Is it possible
>> that problem was compensated for in specific linker patch-level or
>> something?
>
> It could be. I'm building on an old HP/UX 11.11 machine with a fairly old
> toolchain, to ensure the resulting bits will work on a wide
> In reference to
> https://android.googlesource.com/platform/ndk/+/ics-mr0/docs/STANDALONE-TOOLCHAIN.html.
>
> It appears there are some flags that should be present when targeting
> Neon on Android:
>
> CFLAGS='-march=armv7-a -mfloat-abi=softfp -mfpu=neon'
What is the concern exactly? That
>>> For FreeBSD 10 we have changed /usr/lib/libc.so to be a text linker
>>> script and no longer a symlink. This breaks the config check on i386 for
>>> what binary format to use when building with ASM support. The current
>>> config check expects /usr/lib/libc.so to symlink to a /usr/lib/libc.so.X
>>> ...
>> OpenSSL doesn't have any floating point, at least not on
>> performance-critical paths,
> I believe the PRNG interface uses floating point operations
> (specifically, for the estimate of entropy).
Yes, but this doesn't answer the question, what is the concern? That
failure to compile Op
Hi,
> This is RSAZ version 2, patching over the new OpenSSL version 1.0.1.
The 512-bit exponentiation, one useful for RSA1024 sign, is integrated
in "dissected" form. Latter means that unlike original suggestion to
implement whole exponentiation as one jumbo assembly subroutine taken
approach
Hi,
> This patch offers an efficient and side-channel protected implementation of
> 1024-bit Modular Exponentiation, which is useful for RSA2048.
>
> The implementation is based on the "redundant representation" method, that
> Helps accelerating modular exponentiation, when using SIMD archite
Hi,
> This patch is a contribution to OpenSSL.
>
> It offers an efficient and constant-time implementation of 1024-bit
> and 2048-bit Modular Exponentiation. When the patch is applied to the
> OpenSSL library, it accelerates RSA1024 (verify), RSA2048 (verify and
> sign), DSA1024 (verify and sign)
Mike Inman via RT wrote:
> crypto/bn/asm/x86_64-gf2m.pl was not finishing code generation before the
> assembler started, resulting in errors that looked like:
>
> set ASM=ml64 /c /Cp /Cx /Zi
> perl crypto\bn\asm\x86_64-gf2m.pl tmp32\x86_64-gf2m.asm
> ml64 /c /Cp /Cx /Zi /Fotmp32\x86_6
> I did a quick test, and found that 'make test' succeeds for -O0, -O1,
> -Os, and -Oz, but fails for -O2 and -O3. This is using Apple's cc
> which is based on clang-3.3 (it describes itself as "clang-500.1.58
> based on LLVM 3.3svn") and openssl-1.0.1e.
>
> It fails in the "NIST test vectors" sta
> it looks that the RSAZ assembly broke build on OSX.
>
> clang:
> /opt/local/bin/perl5 asm/rsaz-x86_64.pl macosx > rsaz-x86_64.s
> clang -c -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include
> -DDSO_DLFCN -DHAVE_DLFCN_H -g -arch x86_64 -O3 -DL_ENDIAN -Wall
> -DOPENSSL_IA32_SSE2 -DOPENSSL_
> More reliable than playing games with signal handling in libraries.
While signal-free initialization of OPENSSL_armcap_P is indeed
desirable, suggested code doesn't actually solve all the problems. Yes,
it would reliably detect NEON capability. But the thing about tick
counter is that it's le
Hi,
> 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,
Hi,
> the below patch adds support for the new 64 bit version of Cygwin,
> running on x86_64. Only a few minor Configure and Makefile patches are
> required to get it run.
>
> The patch is against git from today. I hope it's ok to apply this to the
> upstream sources.
Could you double-check
h
> a | 1 is always true, regardless of OPENSSL_armcap_P, and
> mrc cp15 will fail on <= v6.
>
> --- a/crypto/armcap.c
> +++ b/crypto/armcap.c
> @@ -23,7 +23,7 @@ unsigned int _armv7_tick(void);
>
> unsigned int OPENSSL_rdtsc(void)
> {
> - if (OPENSSL_armcap_P|ARMV7_TICK)
> + if (OP
> I am trying to build 1.0.2 on Solaris 10 with T4 support, the compilation of
> both openssl-1.0.2-stable-SNAP-20130918 and openssl-SNAP-20130918 fail with
> the following error:
>
>
> cc: Warning: -xarch=v8plus is deprecated, use -m32 -xarch=sparc instead
> /usr/bin/perl asm/dest4-sparcv9.pl
> File: openssl/crypto/aes/asm/bsaes-x86_64.pl
> Function: bsaes_xts_[en|de]crypt
> Commit: fa104be35e24f3fea895d55bb7042d6f4b2963e9
>
> Pointer to IV is pulled to $arg6 (line 2109):
> mov0xa8(%rsp),$arg6# pull ivp
>
> However, for x64 $arg6 is defined as r11d (line 1155):
> my ($
Hi,
>>> the below patch adds support for the new 64 bit version of Cygwin,
>>> running on x86_64. Only a few minor Configure and Makefile patches are
>>> required to get it run.
>>>
>>> The patch is against git from today. I hope it's ok to apply this to the
>>> upstream sources.
>> Could you do
> I have an old i686 machine with a Cyrix M II CPU running Fedora 19. The
> latest version of openssl (openssl-1.0.1e-28.fc19.i686) doesn't work
> properly with it due to OPENSSL_ia32_cpuid() misdetecting the RDRAND
> instruction (see https://bugzilla.redhat.com/show_bug.cgi?id=1022346 ).
> All pre
> I'm compiling OpenSSL 1.0.1e on OI 151a8 x86_64, using Illumos-GCC 4.4.4 but
> failed:
> # ./config
> # gmakemaking all in crypto...gmake[1]: Entering directory
> `/usr/share/src/openssl-1.0.1e/crypto'( echo "#ifndef MK1MF_BUILD"; \
> echo ' /* auto-generated by crypto/Makefile for cry
>> Here is an updated version of the patch.
>>
>> Addressing a) "pointer to the function" (to select ADCX/ADOX) and b)
>> multiple points addition
>>
>> There is (only) ~1% performance deterioration in due to the pointer being
>> passed now, instead of (originally) being static. You can choose whic
> I encountered a number of unusual (but mostly minor) errors in building
> 1.0.1e on Tru64 V4.0G, configuration tru64-alpha-cc. I've addressed the
> majority of these in the 20131106 snapshot, and the changes are in the
> attached patch. Here is a walk-through:
>
> crypto/Makefile,
> crypto/bn/Ma
>>> * Tru64 cc(1) can't preprocess stdin; it needs a file
>> You can't make such broad statement, as it was verified to work on
>> 5.x.
>
> Well, it doesn't work for 5.1:
>
> $ uname -a
> OSF1 darkstar V5.1 732 alpha
> $ echo __osf__ | cc -E -
> cc: Error: No source or object file
>> Do you have any comment from Intel on the concerns regarding the scattering
>> technique (http://cryptojedi.org/peter/data/chesrump-20130822.pdf)?
>
> As discussed off-list in this case the discrepancy is because so called
> memory disambiguation logic attempting to move loads ahead of stores,
>>> Is there an e-mail thread discussing that somewhere?
>> No. I was struggling with it from the beginning and it simply was a
>> compromise kludge.
>
> I'm just curious as to what the behavior was. (Was the preprocessor
> returning non-zero even though it had correctly processed the file?)
If '
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=2df9ec01d563f9cc2deab07e8c3391059d476592
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=5b63a392411822ef4252463cfb914a2ddeee06c6
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=d1cf23ac86c05b22b8780e2c03b67230564d2
Hi,
> xmm6 and xmm7 registers are not correctly restored on bn_scatter5 return.
> The diff was generated using git HEAD.
>
> I am using openssl-1.0.1e that contains the bug. On openssl git logs it
> appears the bug is present since the first commit when bn_scatter5 was
> implemented.
Good ca
Feels like Oracle convention all of a sudden...
> I think we need to clarify why this should be done.
The lesson is to always report underlying reasons. Because as we see
here, it might turn out misleading.
> ... The SPARC "random"
> instruction was never implemented and never will be implemen
> Compiled OpenSSL with GCC -O3 optimization on ARM64 might cause
> AES256-SHA256 testing fails:
> -
> [ 3022s] Testing AES256-SHA256
> [ 3024s] Available compression methods:
> [ 3024s] NO
> This bug is still present in lastest release.
>
> Type: bug
> Version: openssl-1.0.1f
> Operating system: linux x86_64 ( +all )
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=758954e0d8232d370ed72b7f86640e40443e1778
thanks for report.
> When I’m trying to run
>
> openssl s_client -connect courtapps.utcourts.gov:443
>
> I constantly get an error:
>
> CONNECTED(0003)
> depth=3 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary
> Certification Authority
> verify error:num=19:self signed certificate in certificate cha
Hi,
> yesterday I needed to build OpenSSL on my own for the first time using
> an Embarcadero C++ Builder XE 4, which is a successor of Borland
> Builder 4 and 5. I tried the versions 0.9.8y and 1.0.1f just to see
> which of both works best. In the end I was able to build both of them
> by just fo
Hi,
> there is a syntax problem in file ms/do_win64a.bat
> "NUL:" must be "NUL"
>
> possible patch:
> --- temp/orig/openssl-1.0.1e/ms/do_win64a.bat2013-02-11
> 16:26:04.0 +0100
> +++ temp/current/openssl-1.0.1e/ms/do_win64a.bat2014-01-31
> 09:13:20.861517000 +0100
> @@ -1,6 +1,6
>>> there is a syntax problem in file ms/do_win64a.bat
>>> "NUL:" must be "NUL"
>>>
>>> possible patch:
>>> --- temp/orig/openssl-1.0.1e/ms/do_win64a.bat2013-02-11
>>> 16:26:04.0 +0100
>>> +++ temp/current/openssl-1.0.1e/ms/do_win64a.bat2014-01-31
>>> 09:13:20.861517000 +0100
>>> @@
> We have encountered a Segmentation Fault while trying to send a SSL
> packet via Oracle VM agent.
>
> The Segmentation Fault occurred when EVP_MD_CTX_copy() failed in tls1_mac().
> tls1_mac() doesn't check the return code of EVP_MD_CTX_copy() and keep
> going, which results in Segmentation Fau
Hi,
> We've been testing OpenSSL 1.0.2 AES-CBC, and we encountered a seg fault
> when the input length is less than a block size.
>
> Looking at e_aes.c, aes_cbc_cipher() doesn't have the length check seen
> in aes_ecb_cipher().
> I patched aes_cbc_cipher() as follows, and that seems to fix the
> Platform: UnixWare 7.1.4 MP4
> OpenSSL 1.0.2 beta1
>
> It looks like the latest assembler changes to sha and aes break
> on USL assemblers.
>
> --
> making all in crypto/sha...
> cc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include
> -DOPENSSL_THREADS -Kthread -DDSO_DLF
> | > --
> | > making all in crypto/aes...
> | > cc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include
> -DOPENSSL_THREADS -Kthread -DDSO_DLFCN -DHAVE_DLFCN_H -D__i386__ -O -DFILIO_H
> -Kalloca -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT
> -DOPENSSL_BN_ASM_GF2m -DSHA1_AS
> | Now to track down the next error.
> | I took a couple @'s out of Makefile to get more info
> | ..
> | making all in crypto/cmac...
> | if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then \
> | (cd ..; make libcrypto.so.1.0.0); \
> | fi
> | [ -z "" ] || cc -Kpic -DOP
>>> --- Xopenssl-1.0.1f/crypto/aes/aes-586.s2014-02-24 23:09:12.771751012
>>> -0800
>>> +++ openssl-1.0.2-beta1/crypto/aes/aes-586.s2014-02-24
>>> 22:07:47.869751012 -0800
>>> @@ -994,8 +1000,7 @@
>>> call.L004pic_point
>>> .L004pic_point:
>>> popl%ebp
>>> - leal
> 260 new warnings for OpenSSL 1.0.2 Beta 1 on Solaris 10 Sparc.
>
> /usr/ccs/bin/as: SunOS 5.10 118683-08 Patch 07/05/2012
>
> uname -A: SunOS apache 5.10 Generic_142900-07 sun4u sparc SUNW,Sun-Fire-V240
>
> gcc (GCC) 4.8.2
>
> Problem maybe related to http://cvs.openssl.org/chngview?cn=22016
> Change
> http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=b3ef742cbbc1c8bf0e33dca60f08c65031647b07
> broke "make install" on Solaris. Error message:
>
> /bin/sh: !: not found
>
> The new syntax
>
> - if [ "$(PLATFORM)" != "Cygwin" ]; then \
> + if ! expr "$(PLATFORM)" : "Cygwin" >
>> We've been testing OpenSSL 1.0.2 AES-CBC, and we encountered a seg fault
>> when the input length is less than a block size.
>>
>> Looking at e_aes.c, aes_cbc_cipher() doesn't have the length check seen
>> in aes_ecb_cipher().
>> I patched aes_cbc_cipher() as follows, and that seems to fix the
> The GOST HMAC code using NID_id_GostR3411_94 will segfault if you use
> HMAC_Update with zero length input data.
This is not complete truth. It crashes with zero length only if data
pointer is NULL (or more accurately less that 32) as well. It's not a
justification, it's purely for protocol.
ht
> Got those kind of messages when compiling openssl 1.0.1:
> cbc128.c:175:6: warning: dereferencing type-punned pointer will break
> strict-aliasing rules [-Wstrict-aliasing]
> *(size_t *)(tmp.c+n) ^ *(size_t *)(ivec+n);
> ^
> gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include
> -DOPE
> I am currently building using OpenSSL 0.9.8w
> The compile flags etc all come from Intel drop
> I would like to move to 1.0.1e (which I know is not the latest) but I have
> other SW which uses 1.0.1e
> If I look at the delta from 0.9.8w to what Intel provides with their
> changes there are mayb
> after moving from OpenSSL-1.0.1e to OpenSSL-1.0.2-5ff68e8 our nginx
> instances started crashing (very rarely, but still...) with backtraces
> pointing to either "sha1_block_data_order_avx" or
> "sha1_block_data_order_ssse3", depending on machine. This is happening
> when nginx is acting as a cli
> The following error occurs using the 20140613 snapshot on the 1.0.2
> trunk. The host is a 64-bit CentOS system. This problem does
> not occur on 32-bit CentOS.
>
>
> gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include
> -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H
Hi,
> The recently released preview of MSVC14 has changed the ABI for the C
> Runtime library. The intent is to avoid having to change it again in
> the future, so that DLLs linked against the current version will be
> able to safely use later versions.
>
> In e_os.h there is the following code w
> Discovered this problem while trying to fix
> https://github.com/joyent/node/issues/7704.
>
> Attached is a fix for it.
Trouble is that modified code might avoid crash, but it doesn't produce
correct result either. [No, not even Adam's suggestion]. Actually
bn_mul_mont is abused in bn_exp.c, be
> I'd still pull Adam's changes, at least for consistency reasons. Other
> assembly files seems to be using signed comparison for the same kinds of
> operations.
>
> What do you think about it?
I think it's appropriate to harmonize branches with interface. But it
takes deal of concentration and u
> I'm totally willing to cooperate on this, and may have enough skills to do
> it.
>
> Do you think it could be possible for us to collaborate on this topic?
Sure! I'd appreciate it. Start by preparing patch harmonizing branches
with interface. Still I can't promise swift review and reply, so ple
>> As for what to do. As far as I recall the "tangible" reason for redefine was
>> that [by 1300 time] definition depended on compiler command line options (or
>> wasn't a call to function). If definition does not depend on command line
>> *now*,
>> *and* always resort to function call, then it wo
> I'm on the OpenSSL_1_0_2-stable branch, commit d85a772, and compilation
> fails for darwin64-x86_64-cc with the error reported at the bottom. The
> commit that introduced the compilation issue is
> 70fddbe32a7b3400a6ad0a9265f2c0ed72988d27.
>
> If instructed, I can try to help by running more tes
Hi,
> As of 04-07-2014, the latest version of crypto/sha/asm/sha512-x86_64.pl
> (commit 29be3f6411) in the master branch shows the following at line 2309:
>
> $code.=<<___ if ($SZ==4 && $shext);
>
>
> Seeing that the variable $shext doesn't exist, but $shaext does, this
> might be a typo.
> Ple
>I am porting Openssl 1.0.1g in Embedded which is developed with OpenWRT -
> MIPS64 CPU.
> I found SHA is not working and it will always dead when calling
> sha1_block_data_order defined in sha1-mips.pl. If I ./configure with no-asm
> then everything is fine.
> My questions is does sha1-
> Running `make test` with Clang sanitizers results in some issues with
> unaligned pointers surrounding some uses of buffers cast to a size_t*.
> The sanitizers used were `-fsanitize=undefined -fsanitize=address`.
Those are conscious choices based on the fact that some CPUs, x86_64
included, are
>>> Running `make test` with Clang sanitizers results in some issues with
>>> unaligned pointers surrounding some uses of buffers cast to a size_t*.
>>> The sanitizers used were `-fsanitize=undefined -fsanitize=address`.
>> Those are conscious choices based on the fact that some CPUs, x86_64
>> inc
>> ... So that above results
>> don't tell anything about benefits of STRICT_ALIGNMENT being undefined.
>> And it's usually around 10%. And indeed, I just measured 12.5% on my
>> computer. [You have to configure with no-asm, and rig apps/speed.c to
>> use misaligned buffers].
>
> If I then turn on
Basically this discussion applies even to tickets #3422 and #3423. This
means that I'm not going to comment on those tickets, but do whatever we
agree on doing here and close them simultaneously.
> I think the main question is if this speed difference is a good
> excuse to use undefined behavior o
>>> As for warning. I personally would argue that we are looking at
>>> platform-specific i.e. implementation-defined behaviour, not undefined.
>>> Once again, this applies to all three tickets. One is effectively
>>> identical to this one, second is about variable shift in CAST. As
>>> mentioned t
For protocol sake, I've taken the case to look into it.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
As for warning. I personally would argue that we are looking at
platform-specific i.e. implementation-defined behaviour, not undefined.
Once again, this applies to all three tickets. One is effectively
identical to this one, second is about variable shift in CAST. As
mentio
>> ... if you compile with
>> -fsanitize, you should also add -DPEDANTIC.
>>
>> http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=021e5043e524b1cb28a929ef902548a987c16e65
>>
>> As mentioned this applies to tickets #3422-4.
> Looks good to me. Self tests were fine with -DPEDANTIC.
>
> And
> We will try and look at this again at a later time.
I'd argue that it would be more appropriate to handle this by giving it
a spot at http://www.openssl.org/contrib/. Well, at the same time we
should be open to modifications that can *facilitate* ports to exotic
platforms. I mean it doesn't have
>> openssl enc command with -aes-xxx-xts doesnt work if an IV is specified
>
> When you say it "doesn't work", what do you mean? Do you get an error? If so
> what is it?
If only it was the actual problem. The thing is that *if* one wants to
make enc work with XTS, it has to be treated specially,
Hi,
> I would like to submit a patch for md5 calculation on aarch64 architectures.
Thanks for submission, but because of time constraints it will be looked
into later.
__
OpenSSL Project http://w
Hi,
> 1.0.2 beta2 has a testsuite failure on sparc:
> Testing cipher CAMELLIA-192-OFB(encrypt)
> Key
> 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
> 0010 62 f8 ea d2 52 2c 6b 7b
> IV
> 52 ef 01 da 52 60 2f e0 97 5f 78 ac 84 bf 8a 50
> Plaintext
> 30 c8 1Makefile:149: recipe for
Kurt Roeckx via RT wrote:
> On Sun, Aug 17, 2014 at 04:26:53PM +0200, Andy Polyakov via RT wrote:
>> Hi,
>>
>>> 1.0.2 beta2 has a testsuite failure on sparc:
>>> Testing cipher CAMELLIA-192-OFB(encrypt)
>>> Key
>>> 8e 73 b0 f7 da 0e 64 52 c8
Hi,
> I would like to submit a patch for md5 calculation on aarch64 architectures.
First of all we have to recognize that MD5 is effectively dead and
therefore implementing it in assembly is basically just a useful
exercise. This doesn't mean rejection, it only affects the priority. And
now to th
Hi,
> This reverts commit d1cf23ac86c05b22b8780e2c03b67230564d2d34.
>
> When gcc is given a .s file and told to preprocess it, it outputs nothing.
> Since gcc targets are more common/important than OSF, revert it and let
> the original submitter sort out the problem.
>
> URL: https://bugs.gentoo
> http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=d1cf23ac86c05b22b8780e2c03b67230564d2d34
With cross-reference to
http://rt.openssl.org/Ticket/Display.html?id= can you confirm that
preproc=/tmp/.$@.S assignment works?
_
>>> This reverts commit d1cf23ac86c05b22b8780e2c03b67230564d2d34.
>>>
>>> When gcc is given a .s file and told to preprocess it, it outputs nothing.
>>> Since gcc targets are more common/important than OSF, revert it and let
>>> the original submitter sort out the problem.
>>>
>>> URL: https://bugs
Hi,
>>> http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=d1cf23ac86c05b22b8780e2c03b67230564d2d34
>> With cross-reference to
>> http://rt.openssl.org/Ticket/Display.html?id= can you confirm that
>> preproc=/tmp/.$@.S assignment works?
>
> Thanks for following this up.
>
> The
>> I suggest to resort for adding -DOPENSSL_USE_IPV6=0 at config time. I
>> couldn't reproduce the problem on two different systems, so it's some
>> problem with yours.
>
> What system(s) are you testing on?
We have discussed it earlier, 5.1. And was under impression that you
target 5.1 too. You
> When compiling OpenSSL optimized on ARM using the Microsoft compiler,
Out of curiosity, which version? There is record of it generating bad
code specifically in bn_nist.c. At one occasion it was reported that it
generates bad code when optimization is switched off.
> the wrong code is being emi
>> When compiling OpenSSL optimized on ARM using the Microsoft compiler,
>> the wrong code is being emitted for BN_nist_mod_521 (in bn_nist.c).
>> The compiler seems to think that val and temp represent the same item
>> when they are clearly one index apart. I've coded a fix that simply
>> avoid us
Hi,
> This is the ppccap.c's patch for Mac OS X with PowerPC G3.
> OpenSSL with PowerPC G3 is working fine. But always clash without
> OPENSSL_ppccap=0.
If by crash you mean http://www.openssl.org/support/faq.html#PROG17,
i.e. you suffer from it when debugging, then answer is deal with it.
E.g.
> crypto/aes/asm/aesni-x86_64.pl: aesni_ecb_encrypt (unlike the other
> AES-NI functions) does not save and restore the Win64 ABI callee-save
> XMM registers.
Oh! The reason must be that originally the module used lower instruction
interleave factor and ECB didn't need to off-load any XMM register
> All internal exports: Zeroize XMM registers that may contain secret
> data before returning. (At 4x pxors per cycle, the overhead is
> negligible.)
>
> _ctr32: Zeroize $key0 and $ctr.
Question is why just aesni module? Why not everywhere? Why not demand
that compiler does it too? Why just regis
>> All internal exports: Zeroize XMM registers that may contain secret
>> data before returning. (At 4x pxors per cycle, the overhead is
>> negligible.)
>>
>> _ctr32: Zeroize $key0 and $ctr.
>
> Question is why just aesni module? Why not everywhere? Why not demand
> that compiler does it too? Why
>> If you can present
>> coherent argument and consensus is reached, then it would have to be
>> implemented universally, not only in aesni-x86_64 module.
>
> So, hopefully my cross-posted message convinced you.
No, not really. What I meant was that as long as you can't ask even
compiler to wipe
For public reference. The final version committed to repository with
following changes:
- nameing re-biased to ecp_nistz256, both filenames and functions;
- assembly optimized for processors other than Intel Core family;
- assembly modules adapted even for non-ELF platforms;
- some of higher level
The ABI fix is committed, unfortunately RT number is off by one in commit
message, 3553 instead of 3552.
__
OpenSSL Project http://www.openssl.org
Development Mailing List open
> Use aesenclast to do key expansion for AES-256 rather than aeskeygenassist.
>
> Shay Gueron gives the technique in his AES-NI whitepaper; I
> discovered, after implementing my own version (and looking for places
> to patch), that he and Vlad Krasnov had already implemented this
> technique in NS
> I am attempting to build Open SSL 1.0.1.i on Intel 64, Windows 7, using
> Visual Studio Professional 2012.
> I configured the build with
> perl Configure debug-VC-WIN64I no-asm no-hw
WIN64I denotes Itanium, while what you need on Windows 7 is WIN64A.
> ms\do_win64i compl
> Have attempted another build using Win 32 option
> perl Configure VC-WIN32 no-asm no-hw
>
> ms\do_ms completes without error or warnings.
>
> Running nmake -f ms\ntdll.mak compiles all C code but generates the
> following error on linking
> rc /fo"tmp32dll\libeay
> I used the commands
>
> ./Configure shared debug
I don't think this would be working build on
a 64-bit platform such as one in question. Or rather even if it does
work (make test passes, etc.) it wouldn't be supported and questions
should be dismissed. "Official" way t
> Followed your instructions regarding changing the target.
> But received different problems with the assembler.
> See below
>
> Y:\OpenSSL\openssl-1.0.1i>cmd /c "nasm -f win64 -v" 1>NUL 2>&1
>
> Y:\OpenSSL\openssl-1.0.1i>if 1 NEQ 0 goto ml64
>
> Y:\OpenSSL\openssl-1.0.1i>perl ms\uplink-x86_64
> Building openssl-fips-2.0.6 for linux-x86_64, using gcc 4.8.2 and I am
> seeing these same warnings on three files:
> cbc128.c
> ccm128.c
> gcm128.c
>
> This is first time I've built the FIPS module for this target. For other
> targets I've built (using much older gcc cross-compilers, admittedly
On 11/07/14 21:54, Kurt Roeckx via RT wrote:
> On Fri, Nov 07, 2014 at 11:47:23AM +0100, Kraft, Matthias via RT wrote:
>> Hi OpenSSL team,
>>
>> in an overly eager attempt to fix the compile errors of OpenSSL 0.9.8zc I
>> applied all commits that meanwhile arrived against OpenSSL_0_9_8-stable. I
Hi,
> I am attempting to build OpenSSL 1.0.2e on AIX and I'm seeing an issue with
> the "stvx" assembler instruction in the sha256p8-ppc.s module. I have built
> prior version OpenSSL packages on AIX without issue until now (prior was
> 1.0.1c), and I haven't varied the steps I typically use.
Hi,
>> OpenSSL 1.0.2e
>>
>> At line 156 of crypto/modes/ctr128.c
>>
>> const unsigned char *in,
>> unsigned char *out,
>> unsigned char ivec[16],
>> unsigned char ecount_buf[16]
>>
>>*(size_t *)(out + n) =
>>*(size_t *)(in + n) ^ *(size_t *)(ecount_buf + n);
>>
>> If the buffers are n
Hi,
> https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=301a6dcd4590fb2f69d08259577e215b4cc3caa3#patch5
> added a check to see if it should use the ADDX instructions based on the
> clang version. Unfortunately, on older versions of clang on OS X this check
> incorrectly returns true
> When building on x32 systems where the default type is 32bit, make sure
> we can transparently represent 64bit integers. Otherwise we end up with
> build errors like:
> /usr/bin/perl asm/ghash-x86_64.pl elf > ghash-x86_64.s
> Integer overflow in hexadecimal number at asm/../../perlasm/x86_64-xla
>>> OpenSSL 1.0.2e
>>>
>>> At line 156 of crypto/modes/ctr128.c
>>>
>>> const unsigned char *in,
>>> unsigned char *out,
>>> unsigned char ivec[16],
>>> unsigned char ecount_buf[16]
>>>
>>>*(size_t *)(out + n) =
>>>*(size_t *)(in + n) ^ *(size_t *)(ecount_buf + n);
>>>
>>> If the buffe
1 - 100 of 820 matches
Mail list logo
