It's not clear if you're talking about the private or public part of the key.
If you're talking about the private part, that's because only a
negligible number of private keys for that curve need 233 bits to be
stored. This is due to the fact that the large, prime-order subgroup
has the form 2^{23
Dear Ken,
One way to accomplish this is something along the lines of
EC_POINT *EC_KEY_get0_public_key(const EC_KEY *);
where EC_KEY is the key structure, returning the point as an EC_POINT
structure, followed by
int EC_POINT_get_affine_coordinates_GFp(const EC_GROUP *, const
EC_POINT *, BIGNUM
> Thanks for the response. Are X and Y the public key?
The tuple (X,Y), yep. But not in any kind of standard, portable
form--just in OpenSSL BIGNUM structures.
> I tried this and it seems to work. Error checking omitted for
> easier reading. Comments?
That looks sane to me.
Billy
___
It's likely you're hitting RT #1593:
http://rt.openssl.org/Ticket/Display.html?id=1593&user=guest&pass=guest
Options include
A) Use a different curve.
B) Use a 64-bit build.
C) upgrade to at least 0.9.8h.
D) Figure out the series of patches to resolve the bug.
E) Hack the code up to resolve it y
ECDHE is the E=Ephemeral version where you get a distinct DH key for
every handshake.
ECDH has a fixed DH key; one side of the handshake doesn't change from
one instance to the next.
ECDHE gives you forward secrecy; ECDH does not.
ECDHE is less efficient than ECDH; it requires more crypto operat
> Well one reason is that the fixed ECDH cipher suites do not support forward
> secrecy because they always use the same ECDH key.
ECDHE cipher suites as implemented in OpenSSL don't necessarily
support forward secrecy either. I wonder what it takes to get
SSL_OP_SINGLE_ECDH_USE option by default
That's just the way ECDSA and DSA signatures work. Yes the ASN.1 encoding
factors in but mostly it's just the way the math goes. The signature is a
tuple (r,s) where r and s are mod n and n is fixed per curve. r and s are
always smaller than n, normally around the same size as n, but can also be
ev
> EC_GROUP* group = EC_GROUP_new_by_curve_name (NID_secp256k1);
> "c16b4ce0532f5dc9d09114fe121d3956ae84f9eb677a0d4bdac1d3af7a91950c";
I don't believe there's a point on secp256k1 with that x-coordinate.
If you check the failure reason for
EC_POINT_set_compressed_coordinates_GFp in
/01.03.01_60/ts_103097v010301p.pdf
> ).
>
> I notice that the point 'pubPoint' that I created is empty when I try
> to call 'EC_POINT_set_compressed_coordinates_GFp' function. How can I
> put a BIGNUM into an EC_POINT?
>
> Luca
>
> Billy Brumley
> Thank you! I thought they were the same.
>
> And given an x-only coordinate, how can I find the y coordinate? I
> don't find the relative functions on the documentation.
Well it depends on what you mean. Internally,
EC_POINT_set_compressed_coordinates_GFp will internally automatically
compute th
> If I have an x-point which follows this representation
> https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html (so it is
> composed by 33 byte and first byte is '0x02') and I use
> 'EC_POINT_set_compressed_coordinates_GFp' function, it will be
> considered as compressed-y-0 or compressed-y-1
> I'm tasked to implement certain cryptographic functions (chiefly
> signature creation/validation) using the SM2 algorithm for a
> communication testing application. My problem is that the standard which
> I need to follow (which is, unfortunately, not a public standard) states
> that the signatur
Howdy Folks,
I checked https://www.openssl.org/policies/releasestrat.html but did
not manage to find an answer.
At what stages is marking a function deprecated still allowed? Only
before beta? Or at all stages? Or is it case-by-case with potential
OMC vote?
Thanks
BBB
Hey John,
> I want to implement a function that validates a public key produced by either
> ed25519 or ed448 – according to the tests in NIST SP 800-186 appendix D.1.3
>
>
>
> There doesn’t appear to be any helper functions to assist in this – at least
> for Edwards curves.
>
>
>
> I have implem
n 800-186 I don’t actually need any more
> functionality - as the BN functions will (I think) do what I need. Having,
> said that I can't get the "public key on the curve" test working as yet given
> the RFC 8032 test vectors. Hopefully, I will sort it out soon!
>
>
> Bonus question :-) I have a 2 more
> TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 and
> TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
>
> I dont even find these listed on the man pages -
> https://www.openssl.org/docs/man1.0.2/man1/ciphers.html and hence was curious
https://www.openssl.org/new
> > Don't forget to use CRYPTO_memcmp for comparing the HMACs, not regular
> > ol' memcmp.
>
> What's the rationale? The HMAC result isn't secret.
The _purported_ tag is public, but the _ground truth_ tag is not.
Indeed, that's the whole reason to use a constant time compare.
Otherwise, an attack
This is not really true. At least, for some of the tests.
https://github.com/openssl/openssl/blob/master/test/ecdsatest.c#L73
That hijacks the RNG to feed the expected nonce, so it can check vs a KAT.
Cheers,
BBB
On Mon, Aug 30, 2021 at 12:40 PM Tomas Mraz wrote:
>
> Hello,
>
> your analysis
> > Hello,
> > Is there any command-line tool to get the plain text rsa private key
> > like the following format from .pem file?
>
> openssl rsa -in mykey.pem -noout -text
It would in fact be much more educational to advocate pkey, which is
cryptosystem agnostic
openssl pkey -in mykey.pem -noout
>In our application we are accessing BIGNUM member top as bn->top.
> Now we are trying
>
>to migrate to OPENSSL 3.0. I am unable to find API to access this
> member.
>
>Please let me know if there is any get API to get the “top” member
> of BIGNUM.
Since the
> # Generate a new Ed25519 key pair:
> $ openssl genpkey -algorithm ed25519 -out ed25519-key.pem
>
> # Extract its public key:
> $ openssl pkey -in ed25519-key.pem -pubout ed25519-key-public.pem
>
> # Confirm the public key:
> $ openssl pkey -pubin -in ed25519-key-public.pem
>
> This uses the PEM h
I'm new to the ECC area and trying to understand the point addition here. I noticed the
implementation of "ec_GFp_simple_add" is different from the algorithm described
at Wikipedia. Does the function
"ec_GFp_simple_add" implement the algorithm in Wiki? Is there any doc/paper explaining
the impl
Howdy,
I notice that OpenSSL has the 'asn1parse' utility for reading PEM and
DER formatted keys. Is there an analogue that allows to write back a new
value for the secret integers in private keys? Or can I encode data
with 'asn1parse' and then output it in PEM format to build a key?
asn1parse
Howdy,
But my question is why q is not 160 bits but instead 224 bits was used by
openssl since the FIPS 186 standard clearly says to use q size 160 bits for p
size 1024 bits?
Can someone familiar with the topic, clarify my doubt please? Maybe I missed
some fine points in the standard.
I'd
http://en.wikipedia.org/wiki/Elliptic_Curve_DSA
"order" in the code you pasted = "n" in the wiki = "N" in your mail.
The code you pasted refers to GFp so the points (x,y) satisfy 0 <= x <
p and 0 <= y < p. That's probably what you mean by "q". Anyway, it's
used in the underlying elliptic curve op
p value does not change
> (unless the curve is changed).
>
> Sent from my iPhone
>
>> On 19 Dec 2013, at 17:35, Billy Brumley wrote:
>>
>> http://en.wikipedia.org/wiki/Elliptic_Curve_DSA
>>
>> "order" in the code you pasted = "n" in the wiki =
Fri, Dec 20, 2013 at 12:44 AM, Matt Caswell wrote:
> On 19 December 2013 18:52, Billy Brumley wrote:
>> It's in the EC_GROUP structure: group->field. Check crypto/ec/ec_lcl.h. BBB
>>
>
> Anything in the *lcl.h header files does not form part of the public
> API and
> $ echo -n foobar | openssl dgst -sha256 -hex -hmac aabbcc
> (stdin)= 6e74cdc3b72b8b66535b914357c7d656a22acbb1700b4e6de688fd5c091d305c
This gets posted every once in a while -- google around. Something
about the hmac switch not doing what you think it's doing.
$ echo -n foobar | openssl dgst -sh
> The mta.opensslfoundation.net was only very temporary and should
> not be used. openssl-users@openssl.org works just fine and
> doesn't have any delay for me. You can always check the headers
> why or where it has any delay.
Guess I'll mention this here. After the mailing list changes, MARC
st
> * On architectures where nistz256 is not implemented, a default
> OpenSSL build will use the generic Weierstrass implementation. I
> haven't been able to determine whether there are significant timing
> channels in that implementation.
Researches have been beating up "the generic Weierstr
It's because of the form of the group order for the curves you list.
They look roughly like 2**n + 2**(n/2). So while technically possible
to end up with 161 bits, with overwhelming probability you end up with
less.
BBB
On Wed, Apr 6, 2016 at 9:22 PM, Frode Nilsen wrote:
> Hi,
>
> When printing
> i want to contribute some more OIDs. Therefore i added the OIDs inside the
> „Objects.txt“ inside /crypto/objects
>
>
>
> Then i run these commands:
>
> perl objects.pl objects.txt obj_mac.num ../../include/openssl/obj_mac.h
>
> perl obj_dat.pl ../../include/openssl/obj_mac.h obj_dat.h
>
> perl o
Shameless self plug -- OpenSSL engine for 1.0.2, 1.1.0, and later:
https://github.com/romen/libsuola
BBB
On Thu, Jul 26, 2018 at 6:59 PM, Tomas Mraz wrote:
> On Thu, 2018-07-26 at 10:33 -0400, Robert Moskowitz wrote:
>>
>> On 07/26/2018 10:19 AM, Tomas Mraz wrote:
>> > On Thu, 2018-07-26 at 10:
> openssl version
> openssl: /usr/lib/x86_64-linux-gnu/libssl.so.1.1: version
> `OPENSSL_1_1_1' not found (required by openssl)
> openssl: /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1: version
> `OPENSSL_1_1_1' not found (required by openssl)
Sounds like a loader issue.
Try "which openssl" then "ld
> > I am using Qnx 7.0.0 which make use of openssl 1.0.2j.
> >
> > Can you please confirm if I can use ECC related api from openssl which
> > is supported by openssl 1.1.0.
>
> OpenSSL 1.1.0 does not support sign/verify using 25519 (i.e. Ed25519).
> That is only available in OpenSSL 1.1.1.
Shamele
Howdy,
> According to the following website:
> https://www.openwall.com/lists/oss-security/2018/11/01/4
>
> OpenSSL <= 1.1.0h is affected.
> Does that mean the problem also exist in the OpenSSL 1.0.2 release?
Yes, it does. Pending review:
https://github.com/openssl/openssl/pull/7593
BBB
--
On Tue, Dec 18, 2018 at 12:07 AM Mike Blaguszewski wrote:
>
> Some code of mine reads a NIST P256 private key from bytes and derives the
> public key from it, and this derived public key is incorrect about 0.4% of
> the time. I’ve attached a sample program that does the following.
>
> 1. Generat
> I would expect that correct results would be provided for all valid
> inputs (including those inputs that are not otherwise constrained).
> As such, I would class this as a bug in OpenSSL.
These functions are not part of the public OpenSSL API so that's just
not how it works. There is a ton of i
> > Could you please explain how blinding works in OpenSSL?
> >
> > EC_KEY structure seems to have an unblinded private key structure and
> > blinded X, Y, Z- coordinates of the public key when blinding is in
> > use. But if I understand correctly, he idea of blinding is protecting
> > the private
("OpenSSL doesn't do" _scalar_ blinding! Coordinate blinding is there.
sorry ...)
I think the error messages are pretty clear in these cases. Trying to
set a hash with (standardized) EdDSA is not going to go well for you.
Have you tried this very nice walkthrough?
https://tools.ietf.org/html/draft-moskowitz-eddsa-pki-00
BBB
On Thu, Jun 6, 2019 at 9:47 AM Sowmya P wrote:
>
>
Hey Ken,
> I have an ECDSA signature supplied to me as R and S byte arrays and
> lengths (from an HSM).
>
> How do I add them to the X509 structure?
>
> Is there an API, a set of calls, or do you have any hints?
You might be looking for ECDSA_SIG_set0:
https://www.openssl.org/docs/man1.1.0/man3/
42 matches
Mail list logo
