An open source, portable, easy to use, readable and flexible TLS library, and reference implementation of the PSA Cryptography API. Releases are on a varying cadence, typically around 3 - 6 months between releases.
Home Page: https://www.trustedfirmware.org/projects/mbed-tls/
License: Other
We are hoping to use PolarSSL for our C++ MineCraft server (@mc-server), but MineCraft uses AES-CFB8 encryption for its client connections. It is possible to implement this indirectly already, but it'd be much better to have direct internal support for this combination in the library. Are there any plans to add this mode?
It looks like there is one parameter in the SSL context that is never freed. Using valgrind on Linux, ssl_client1 exits with 100 bytes first allocated to session_negotiate.
This is with the latest version from git. I compiled the library with DEBUG=1 and used standard valgrind as provided by Ubuntu 10.04.
$ valgrind --leak-check=full ./ssl_client1
==21144== Memcheck, a memory error detector
==21144== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==21144== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==21144== Command: ./ssl_client1
==21144==
. Seeding the random number generator... ok
. Loading the CA root certificate ... ok (0 skipped)
. Connecting to tcp/localhost/4433... ok
. Setting up the SSL/TLS structure... ok
. Performing the SSL/TLS handshake... ok
. Verifying peer X.509 certificate... ok
> Write to server: 18 bytes written
GET / HTTP/1.0
< Read from server: 148 bytes read
HTTP/1.0 200 OK
Content-Type: text/html
<h2>PolarSSL Test Server</h2>
<p>Successful connection using: TLS-DHE-RSA-WITH-AES-256-CBC-SHA256</p>
EOF
==21144==
==21144== HEAP SUMMARY:
==21144== in use at exit: 4,538 bytes in 19 blocks
==21144== total heap usage: 546 allocs, 527 frees, 81,271 bytes allocated
==21144==
==21144== 4,538 (100 direct, 4,438 indirect) bytes in 1 blocks are definitely lost in loss record 12 of 12
==21144== at 0x4024F20: malloc (vg_replace_malloc.c:236)
==21144== by 0x8050B33: ssl_handshake_init (ssl_tls.c:2873)
==21144== by 0x8049295: main (ssl_client1.c:150)
==21144==
==21144== LEAK SUMMARY:
==21144== definitely lost: 100 bytes in 1 blocks
==21144== indirectly lost: 4,438 bytes in 18 blocks
==21144== possibly lost: 0 bytes in 0 blocks
==21144== still reachable: 0 bytes in 0 blocks
==21144== suppressed: 0 bytes in 0 blocks
==21144==
==21144== For counts of detected and suppressed errors, rerun with: -v
==21144== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 14 from 9)
$
ssl_write_server_hello() always sends secure renegotiation extension, even when the client does not support it.
This makes my (old) openssl client upset, as it's compiled without extensions support. Perhaps the extension should only be sent when client hello contains SCSV or the extension? Or possibly close the connection for such insecure clients.
RFC 5746:
Note that sending a "renegotiation_info" extension in response to a
ClientHello containing only the SCSV is an explicit exception to the
prohibition in RFC 5246, Section 7.4.1.4, on the server sending
unsolicited extensions and is only allowed because the client is
signaling its willingness to receive the extension via the
TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV. TLS implementations MUST
continue to comply with Section 7.4.1.4 for all other extensions.
The sign&verify functions will not free up some mpi's if they fail.
I used the alpha 1.3.1 that was released a couple of months ago.
The mutex calls in x509_crt.c are #ifdef-ed against POLARSSL_THREADING_PTHREAD so they won't respect any alternate threading implementation. I think they should be depending on POLARSSL_THREADING_C.
When I run the benchmarks with 1.3.4, some of the EC benchmarks randomly fail. I tested it under WIN64 and LINUX64.
On Linux64 I rarely get any errors (but occasionally I get them) but on Win64 I always get at least one FAIL.
On WIN64 I use:
gcc (x86_64-win32-seh, Built by MinGW-W64 project) 4.8.2
On Linux64:
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Some results:
Run 1 (WIN64):
ECDSA-brainpoolP384 : FAILED
ECDSA-secp224k1 : FAILED
Run 2 (WIN64):
ECDSA-secp224k1 : FAILED
Run 3 (WIN64):
ECDSA-secp224k1 : FAILED
ECDHE-secp224k1 : FAILED
ECDH-secp224k1 : FAILED
Run 1 (Linux64):
ECDHE-secp224k1 : FAILED
Run 2 (Linux 64):
ECDHE-secp224k1 : FAILED
ECDH-secp224k1 : FAILED
Run 3 (Linux 64):
ECDSA-brainpoolP38 : FAILED
In systems that are very poor on entropy feed, the accumulated entropy is very valuable.(Even more valuable than the DRBG seed.) The entropy module could provide similar functions that the DRBG module(s) already provide: to save and load the entropy seed.
Not that I know if the server does things properly, but the following patch seems to make more sense and get things to work. BTW, couldn't this be handled by the asn.1 decoder?
diff --git a/library/ssl_cli.c b/library/ssl_cli.c
index 545906a..6228f63 100644
--- a/library/ssl_cli.c
+++ b/library/ssl_cli.c
@@ -951,7 +951,7 @@ static int ssl_parse_certificate_request( ssl_context *ssl )
return( POLARSSL_ERR_SSL_BAD_HS_CERTIFICATE_REQUEST );
}
- p = buf + 4;
+ p = buf + 5;
while( cert_type_len > 0 )
{
if( *p == SSL_CERT_TYPE_RSA_SIGN )
to pick up the appropriate openssl include path, should do the following:
diff --git a/programs/test/CMakeLists.txt b/programs/test/CMakeLists.txt
index c05b903..8437b18 100644
--- a/programs/test/CMakeLists.txt
+++ b/programs/test/CMakeLists.txt
@@ -30,6 +30,7 @@ install(TARGETS selftest benchmark ssl_test ssl_cert_test
if(OPENSSL_FOUND)
add_executable(o_p_test o_p_test.c)
install(TARGETS o_p_test
(On current polarssl-1.2 head).
Workaround:
Install package SUNWbinutils and then before building do:
export AR=gar
Otherwise:
$ make
....
AR libpolarssl.a
ar: creating libpolarssl.a
RL libpolarssl.a
ar: one of [drqtpmx] must be specified
make[1]: *** [libpolarssl.a] Error 1
make: *** [all] Error 2
X509 certificates use object IDs for many different purposes (including in their DN and issuer strings). Such Object IDs have a short form string (e.g. "SN"), and sometimes a longer descriptive string.
Currently the string representation of such object IDs are generated using a switch-case construct within the x509 code. As more and more certificate extensions and OID types are added, this becomes less and less maintainable. A separate module containing an object "database" would allow more flexibility, and cleaner code.
This is just a minor inefficiency: ENTROPY_MAX_GATHER is set to 128, but fread() will read more than that (the exact value depends on the underlying C library) because buffering is not disabled via setbuf().
SSL servers should provide as much information their certificate's chain as possible. PolarSSL could help applications by appending certificate authority certificates to a certificate automatically.
Along similar lines, if a server requests a client certificate, it can pass a list of known CAs to the client. PolarSSL should ensure that the returned client certificate has one of the given CAs as its parent.
Request for DTLS support as this would increase usability for my projects.
Hi,
I think that a mpi_mod_mpi is missing from ecdsa_signature as shown below.
Without that line addition, ECDSA verification in DTCP-IP doesn't work.
I'm no ECP expert, so let me know if you disagree with this change.
For reference, I compared the values of each MPI at every line of code with my own reference ECDSA implementation, and that is the only place that differs in PolarSSL.
Thanks.
if( ecp_is_zero( &R ) )
{
ret = POLARSSL_ERR_ECP_VERIFY_FAILED;
goto cleanup;
}
// Make sure R.X is mod n.
MPI_CHK( mpi_mod_mpi( &R.X, &R.X, &grp->N ) );
/*
* Step 6: check that xR == r
*/
if( mpi_cmp_mpi( &R.X, r ) != 0 )
Add new modules from 1.2 branch and 1.3 branch for new releases..
The module CTR_DRBG could be reworked to be able to use other block cyptos than only AES (like the HASH_DRBG module). This would make the module more future proof.
if we check out the current 1.2 branch code (1.2.7 as of today) from scratch and attempt to build, all the .data files that are automatically being generated to prepare for the test cases do not ever get created. i had another previously checked out branch that had the files generated already, and all the tests passed fine with those, but once i cleaned them up, they were never re-generated.
i have examined the methodology and don't see anything obvious, but am guessing the person who made the changes for test cases will know exactly what the issue is.
x509_write_cert_req() calls rsa_pkcs1_sign() without a random number generator. Then rsa_pkcs1_sign() calls rsa_rsassa_pss_sign() which rejects a call without a RNG with an error. Finally, the error is not checked in x509_write_cert_req(), leaving old buffer contents in the signature buffer.
This is a big edgy, but sometimes its useful to build openssl stripped down:
diff --git a/programs/test/o_p_test.c b/programs/test/o_p_test.c
index 0665098..3a6c693 100644
--- a/programs/test/o_p_test.c
+++ b/programs/test/o_p_test.c
@@ -32,7 +32,9 @@
#include <sys/stat.h>
#include <openssl/rsa.h>
+#ifndef OPENSSL_NO_ENGINE
#include <openssl/engine.h>
+#endif
#include <openssl/pem.h>
#include <openssl/bio.h>
Chrome version 29.0.1547.65.
Easy to test, just run programs/ssl/ssl_server and open https://localhost:4433/
$ ./ssl_server
. Loading the server cert. and key... ok
. Bind on https://localhost:4433/ ... ok
. Seeding the random number generator... ok
. Setting up the SSL data.... ok
. Waiting for a remote connection ... ok
. Performing the SSL/TLS handshake... failed
! ssl_handshake returned -80
Last error was: -80 - NET - Connection was reset by peer
Chrome is linked against GnuTLS. I presume it uses that library for SSL connections then, although using gnutls-cli works fine. You can try:
gnutls-cli -d 255 localhost --port 4433 --insecure
So either it configures GnuTLS in a different way than gnutls-cli, or it doesn't actually use GnuTLS to do the SSL connection.
This bug only affects the Linux version of Chrome. The Windows and Mac versions (same version 29) seem to work fine.
I hope you have an idea of what is going on here. I've been tcpdumping and low-level tracing polarssl all day and I am baffled.
Thanks.
If you never call ssl_set_rng() and then do something that needs the RNG, the program segfaults. For example, comment the line with ssl_set_rng in ssl/ssl_client1.c and run ssl_server and then ssl_client1. ssl_client1 will segfault during the handshake. There should be either a safe default or a graceful failure instead.
MULADDC_CORE can be improved for ARM.
I am using PolarSSL's rsa.c for 2048-bit key with STM32F103 processor.
It takes 1.78 second to sign in current implementation.
With this change, it takes 1.72 second.
Please see attached patch.
https://gist.github.com/4079268
Tomstdenis:
ARMv4 TDMI and ARMv5 up support much more efficient multiplication. You may want to look into that. From a practical standpoint new devices are V5 or higher anyways so supporting V4 and below is kinda archaic.
We could help you speed up your math lib. We have an ARM A9 to profile on as well.
PolarSSL already has code to use the Padlock engine for AES on VIA CPUs, but those CPUs also feature HW accelerated SHA1, SHA256, 2 HW RNGs and an HW accelerated Montgomery multiplier which can be used to accelerate RSA and DSA.
The OpenSSL folks have quite optimized code for all of this (except the RNG):
http://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=engines/asm/e_padlock-x86.pl
http://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=engines/asm/e_padlock-x86_64.pl
http://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/bn/asm/via-mont.pl
In the entropy module only the function entropy_func() is thread safe. The other public functions entropy_update_manual() and entropy_gather() are not thread safe. Maybe it was intended to be so, but I think either the whole module should be thread safe or the documentation should explicitly warn that those public functions are not thread safe.
It seems socat likes to send empty blocks which causes zlib to punt.
To reproduce, run this on a test-server:
socat OPENSSL-LISTEN:5555,verify=0,key=test.key,cert=test.crt STDOUT
Connect to this with a polarssl client. Sending from polar to socat works fine. Just hitting enter on the socat end will make the connection fail on the PolarSSL side with a compression error.
I tracked that down to ssl_decompress_buf() being called with an empty block.
The zlib will return an error in that case.
Putting
if( !len_pre ) return ( 0 );
near the top of ssl_compress_buf() and ssl_decompress_buf() fixes that.
Versions:
Possible performance issue only.
Both ssl_compress_buf() and ssl_decompress_buf() call malloc/free on each run.
We might want to keep a central buffer in ssl_context and allocate that once at init.
Increased the size of ssl_context by a major factor.
It passes on my x86-64 dev box and on mipsel, so I'm guessing this is an endianness issue, but I haven't tested further. I have bisected it back to d589a0d.
Here's the test suite output:
$ make check
Running checks (Success if all tests PASSED)
make[1]: *** [check] Error 1
make: *** [check] Error 2
Thank you for adding PKCS #1 v2.1 to the library. I see that the salt length is effectively tied to the hash length with slen=hlen. Can you make the salt length a parameter when calling the sign and verify functions?
Verify automatically uses the salt that is in the signature itself.
For sign, a change is needed. I don't like adding a salt-len variable that is only used if the RSASSA-PSS is enable in the code.. I'm still looking for a nice and not so ugly solution to propagate the salt-len into that part of the code.
Suggestions are welcome.
Postponed to a next release.
This is not an issue, but I just wanted to say thanks for moving to GitHub! I have used this library for some time while developing RtmpDump, and its a big help to have both "under the same roof".
Keep up the good work!
I just compiled polarssl-1.3.2 with Linux gcc compiler flag -Wlogical-op.
It said
polarssl-1.3.2/library/x509_crt.c:1276:9: warning: logical 'or' of collectively exhaustive tests is always true [-Wlogical-op]
polarssl-1.3.2/library/x509_crt.c:1279:9: warning: logical 'or' of collectively exhaustive tests is always true [-Wlogical-op]
Source code is
if( ( n1[i] >= 'a' || n1[i] <= 'z' ) && ( diff == 0 || diff == 32 ) )
continue;
if( ( n1[i] >= 'A' || n1[i] <= 'Z' ) && ( diff == 0 || diff == 32 ) )
continue;
Suggest swap || for && in the a..z checks.
When verifying a X.509 certificate, the process will succeed even if the system time is before the certificate validity period.
This is due to the fact that the member valid_from from the appropriated structure x509_cert will never be checked.
ecp.h openssl.h x509.h missing some open/close extern "C"
There are two erratic #defines in rsa.c. Look for "POLARSSL_PCKS1_V15" instead of "POLARSSL_PKCS1_V15".
This causes the RSA self test not to run even if defined.
Compiling current head of polarssl-1.2 on Solaris 10 appears to be missing linker flags (-lsocket, -lnsl)? Compilation fails.
$ make
...
CC pkey/dh_client.c
Undefined first referenced
symbol in file
bind ../library/libpolarssl.a(net.o)
accept ../library/libpolarssl.a(net.o)
listen ../library/libpolarssl.a(net.o)
gethostbyname ../library/libpolarssl.a(net.o)
socket ../library/libpolarssl.a(net.o)
setsockopt ../library/libpolarssl.a(net.o)
connect ../library/libpolarssl.a(net.o)
shutdown ../library/libpolarssl.a(net.o)
ld: fatal: symbol referencing errors. No output written to pkey/dh_client
collect2: ld returned 1 exit status
make[1]: *** [pkey/dh_client] Error 1
make: *** [all] Error 2
(Reposting from the forum since I'm not sure where the definitive place to post issues is and this seems a better place for tracking: https://polarssl.org/discussions/bug-report-issues/solaris-10-build-failure).
Build of polarssl 1.2.6 (and current HEAD at github) fails on Solaris 10 (u9, x86 and SPARC) because struct dirent does not include a d_type member as required by library/x509parse.c line 1952.
This struct has not been updated for Solaris 11 or 11.1 so presumably will not build there either.
Opengroup ref: http://pubs.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html
$ uname -a
SunOS sol10u9 5.10 Generic_142910-17 i86pc i386 i86pc
$ gcc --version
gcc (GCC) 4.4.2
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ make
...
CC x509parse.c
x509parse.c: In function 'x509parse_crtpath':
x509parse.c:1952: error: 'struct dirent' has no member named 'd_type'
x509parse.c:1952: error: 'DT_REG' undeclared (first use in this function)
x509parse.c:1952: error: (Each undeclared identifier is reported only once
x509parse.c:1952: error: for each function it appears in.)
make[1]: *** [x509parse.o] Error 1
make: *** [all] Error 2
/usr/include/sys/dirent.h:
/*
* File-system independent directory entry.
*/
typedef struct dirent {
ino_t d_ino; /* "inode number" of entry */
off_t d_off; /* offset of disk directory entry */
unsigned short d_reclen; /* length of this record */
char d_name[1]; /* name of file */
} dirent_t;
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
The following tests FAILED:
33 - md-suite (Failed)
34 - mdx-suite (Failed)
35 - mpi-suite (SEGFAULT)
40 - pkparse-suite (Failed)
41 - pkwrite-suite (Failed)
42 - shax-suite (Failed)
46 - x509parse-suite (Failed)
47 - x509write-suite (Failed)
Support for RIPEMD-160 would be a nice enhancement.
It would be very useful for people working on Bitcoin related projects e.g. jgarzik/picocoin#7
The same goes for ECDSA secp256k1, which is also used by Bitcoin.
Recently upgraded to OsX mavericks, which comes with a new compiler, that identifies itself as:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.1.0
Building PolarSSL v.2.3.3:
Undefined symbols for architecture x86_64:
"___udivti3", referenced from:
_mpi_div_mpi in libpolarssl.a(bignum.o)
The error is in bignum.c at line 1239:
t_udbl r;
r = (t_udbl) X.p[i] << biL;
r |= (t_udbl) X.p[i - 1];
r /= Y.p[t]; <---- this line
if( r > ((t_udbl) 1 << biL) - 1)
r = ((t_udbl) 1 << biL) - 1;
Z.p[i - t - 1] = (t_uint) r;
Looks like clang can't find its own definition of a built-in 128 bit division. I have a workaround for now: undefine POLARSSL_HAVE_UDBL in bignum.h
I get the following errors after running cmake . && make:
/var/folders/m2/h8x9nnlj6ld196rpd26qrt9m0000gn/T//ccjiXQHX.s:114:no such instruction: `pclmulqdq $0x00, %xmm0,%xmm1'
/var/folders/m2/h8x9nnlj6ld196rpd26qrt9m0000gn/T//ccjiXQHX.s:115:no such instruction: `pclmulqdq $0x11, %xmm0,%xmm2'
/var/folders/m2/h8x9nnlj6ld196rpd26qrt9m0000gn/T//ccjiXQHX.s:116:no such instruction: `pclmulqdq $0x10, %xmm0,%xmm3'
/var/folders/m2/h8x9nnlj6ld196rpd26qrt9m0000gn/T//ccjiXQHX.s:117:no such instruction: `pclmulqdq $0x01, %xmm0,%xmm4'
make[2]: *** [library/CMakeFiles/polarssl.dir/aesni.c.o] Error 1
make[1]: *** [library/CMakeFiles/polarssl.dir/all] Error 2
make: *** [all] Error 2
I am running Mac OS 10.7.5. I get the same errors when using clang or the GNU toolchain.
If I use a clean copy where I haven't run cmake and just use the provided makefile, then it works fine. However, for the project that I am a part of I need cmake to work properly.
I encountered an issue when attempting to compile a shared library with make. This problem does not occur when using cmake with
option(USE_SHARED_POLARSSL_LIBRARY "Build PolarSSL as a shared library." ON)
Any tips on resolving this without using cmake?
[ayrx@c00kies library]$ make shared
CC aes.c
CC aesni.c
CC arc4.c
CC asn1parse.c
CC asn1write.c
CC base64.c
CC bignum.c
CC blowfish.c
CC camellia.c
CC certs.c
CC cipher.c
CC cipher_wrap.c
CC ctr_drbg.c
CC debug.c
CC des.c
CC dhm.c
CC ecdh.c
CC ecdsa.c
CC ecp.c
CC ecp_curves.c
CC entropy.c
CC entropy_poll.c
CC error.c
CC gcm.c
CC havege.c
CC md.c
CC md_wrap.c
CC md2.c
CC md4.c
CC md5.c
CC memory.c
CC memory_buffer_alloc.c
CC net.c
CC oid.c
CC padlock.c
CC pbkdf2.c
CC pem.c
CC pkcs5.c
CC pkcs11.c
CC pkcs12.c
CC pk.c
CC pk_wrap.c
CC pkparse.c
CC pkwrite.c
CC rsa.c
CC sha1.c
CC sha256.c
CC sha512.c
CC ssl_cache.c
CC ssl_cli.c
CC ssl_srv.c
CC ssl_ciphersuites.c
CC ssl_tls.c
CC threading.c
CC timing.c
CC version.c
CC x509.c
CC x509_create.c
CC x509_crl.c
CC x509_crt.c
CC x509_csr.c
CC x509write_crt.c
CC x509write_csr.c
CC xtea.c
AR libpolarssl.a
ar: creating libpolarssl.a
RL libpolarssl.a
LD libpolarssl.so.5
/usr/bin/ld: aes.o: relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC
aes.o: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
make: *** [libpolarssl.so.5] Error 1
https://www.securityinnovation.com/products/encryption-libraries/ntru-cryptography.html
Reference Code (GPL2):
https://github.com/NTRUOpenSourceProject/ntru-crypto
but:
Is NTRU Patented?
Yes. The patents will still be enforced but may be used under the GPL, i.e. under the condition that any work that uses them is also made available under the GPL. The patents and the code implementations are also available under standard commercial terms.
Why has NTRU been open source licensed?
By offering NTRU source code and patents under the Gnu Public License (GPL) v2, we are intending to remove barriers to widespread deployment. We want to enable the developers of the open-source software that powers the internet to test, use, deploy, and start transitioning to fast, future-proof cryptography. Recent revelations and speculation about NSA influence on both crypto algorithms and crypto implementations have made it clear that the security community desperately needs alternatives to existing crypto solutions.
Making NTRU open-source also removes barriers to testing of both the algorithm and the implementation. Open scrutiny and testing is the only way to instill confidence in any encryption solution.
Furthermore, the open source licensing allows users to implement the NTRU algorithm in other languages and for other operating systems beyond those we currently support.
Are there any commercial licenses available?
For commercial (not open source) applications, Security Innovation offers a commercial license (see repository) that is not limited to use in open source applications only.
The following:
!defined(POLARSSL_ECP_DP_SECP192K1_ENABLED) && \
!defined(POLARSSL_ECP_DP_SECP224K1_ENABLED) && \
!defined(POLARSSL_ECP_DP_SECP256K1_ENABLED) && \
should probably be added to the following block in config.h:
#if defined(POLARSSL_ECP_C) && ( !defined(POLARSSL_BIGNUM_C) || ( \
!defined(POLARSSL_ECP_DP_SECP192R1_ENABLED) && \
!defined(POLARSSL_ECP_DP_SECP224R1_ENABLED) && \
!defined(POLARSSL_ECP_DP_SECP256R1_ENABLED) && \
!defined(POLARSSL_ECP_DP_SECP384R1_ENABLED) && \
!defined(POLARSSL_ECP_DP_SECP521R1_ENABLED) && \
!defined(POLARSSL_ECP_DP_BP256R1_ENABLED) && \
!defined(POLARSSL_ECP_DP_BP384R1_ENABLED) && \
!defined(POLARSSL_ECP_DP_BP512R1_ENABLED) ) )
#error "POLARSSL_ECP_C defined, but not all prerequisites"
#endif
and similar in ecp.c
defined(POLARSSL_ECP_DP_SECP192K1_ENABLED) || \
defined(POLARSSL_ECP_DP_SECP224K1_ENABLED) || \
defined(POLARSSL_ECP_DP_SECP256K1_ENABLED) || \
The "Include Directories" property under Project Settings>"Configuration Properties">"VC++ Directories" is changed from the default for the Debug configurations only. This breaks the Debug builds on my system (Windows 7 with VS Express 2013). Changing the property to "inherit from project defaults" fixes this.
Have an OpenVPN configuration that works with
a WinXP client and Linux x86_64 server.
PolarSSL reject same exact certs that work with
aforementioned configuration.
Much detail at
The GCM context does not get freed in programs/test/benchmark.c. There is a missing gcm_free() after line 300.
I've purchased an mbed prototype board (http://www.mbed.org) and would love to have PolarSSL as a component as I use it in my other projects as well.
Do you plan to make a component there?
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.