I've got a negative number in a BIGNUM:
BN_hex2bn(&a, "00afd72b...bd3ae65d");
BN_dec2bn(&n, "-1");
...
BN_mul(r, a, n, ctx);
I then convert it to an ASN1 INTEGER, and then fetch the ASN1 integer:
ASN1_INTEGER* x = BN_to_ASN1_INTEGER(r, NULL);
const unsigned char* ptr =
On Thu, Jul 24, 2014 at 08:07:01AM -0700, phildoch wrote:
> The key format needed by the system is algorithm-specific DER format.
I am not aware of any standard formats for keys other than PKCS#8
or PKCS#12. In particular, the algorithm-specific PEM encodings
output by "openssl rsa|ec" are I bel
It is hard to imagine that a few random bytes makes a measurable difference,
but I suppose it’s possible. You’ve checked, for example, that you’re using
the same cipher suite in both cases? And what’s a transaction – connect, then
shutdown with no application-level traffic to get in the way?
0200274D means ECONNREFUSED. There's most likely nothing listening on port 700
on your local machine. The reason(1869) is gibberish and a known issue with
Winsock, so don't pay any attention to that.
The suggested solution would firstly be to ensure that something is listening
on port 700. Fur
On Thu, Jul 24, 2014 at 2:57 AM, Sharath B wrote:
> Admin,
>
> We are getting following error while connecting to server.
>
> 4992:error:0200274D:system
> library:connect:reason(1869):.\crypto\bio\bss_conn.c:269:host=localhost:700
> 4992:error:20073067:BIO routines:CONN_STATE:connect
> error:.\cry
Hi guys,
I have a question regarding TLS1.0 and TLS1.2 performance.
Is it a correct expectation is that TPS (transactions per seconds)
performance is worse with TLS1.2 protocol compared to TLS1.0?
I found is that TLS1.2 has additional overhead in explicit IV vector
initialization with random byt
Admin,
We are getting following error while connecting to server.
4992:error:0200274D:system
library:connect:reason(1869):.\crypto\bio\bss_conn.c:269:host=localhost:700
4992:error:20073067:BIO routines:CONN_STATE:connect
error:.\crypto\bio\bss_conn.c:273:
Please suggest the solution.
Regards,
S
Viktor,
The key format needed by the system is algorithm-specific DER format. It is
received from the user in the same algorithm-specific in PEM format.
The algorithm can be:
1) secp384r1 (i.e. created by "openssl ecparam -out ec_key.pem -name
secp384r1 -genkey")
2) rsa:2048(i.e. created by "
On Thu, Jul 24, 2014 at 06:13:45AM -0700, phildoch wrote:
> I currently have a short program that converts a certificate from pem format
> to der format.
PEM and DER are strictly speaking encodings, not formats. The
underlying data is identical, an ASN.1 DER X.509v3 certificate,
which in the PEM
Just do base64 decode.
--
Principal Security Engineer, Akamai Technologies, Cambridge, MA
IM: rs...@jabber.me; Twitter: RichSalz
__
OpenSSL Project http://www.openssl.org
User Support Mailing Li
Hello,
I currently have a short program that converts a certificate from pem format
to der format.
static int vpncm_convert_pem_to_der(struct cm_module *module, char
*pem_file_name, char *der_file_name )
{
int res,ret = 0;
FILE* f;
BIO *out = NULL;
X509 *loaded = NULL;
f = fo
On 24 July 2014 10:38, Iñaki Baz Castillo wrote:
>
> Anyhow I still insist that the example is broken:
>
> --
> BIO *internal_bio, *network_bio;
> BIO_new_bio_pair(internal_bio, 0, network_bio, 0);
> --
>
> It should be:
>
> --
> BIO *internal_bio, *network_bio;
Thanks, will do.
2014-07-23 17:09 GMT+02:00 Bodo Moeller :
> Good point, this doesn't look right; this is not how OpenSSL normally
> reports details. The DTLS code hasn't received the same attention as the
> SSL/TLS code yet, because it's used a lot less. Filing a report to
> r...@openssl.org make
2014-07-18 8:44 GMT+02:00 Thulasi Goriparthi :
> In the example, only internal_bio is set using SSL_set_bio as below.
>
> SSL_set_bio(ssl, internal_bio, internal_bio);
>
> network_bio is not linked to SSL session. So it has to be freed explicitly.
Sorry, you are right. But, is it ok the example?
14 matches
Mail list logo
