Re: Regarding "ec_GFp_simple_add" implementation

[Billy Brumley]

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 implementation of "ec_GFp_simple_add"?


That ECC code pre-dates Wikipedia, so the answer is "no" :)

I believe it is A.10.5 from P1363 or extremely similar. (A crypto standard 
from the late 90s---you'll have to do your own digging.)


At a high level, it is Jacobian projective coordinates with codepath 
optimizations for mixed projective-affine inputs (if applicable).


Please keep in mind the fact that this particular code uses (any form of) 
projective coordinates is only internally relevant for OpenSSL. In the 
public API, all getters / setters / etc related to projective coordinates 
were deprecated as of OpenSSL 3.0.


Hope it helps,

BBB

Re: “EC PUBLIC KEY”

[Billy Brumley]

> # 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 header "BEGIN PUBLIC KEY", but it's an ECC public key in 
> PEM format.

That's an ed25519 key. Not an ECC key. They are different formats, at
both the OID and asn1 structure levels.

> This version of OpenSSL doesn't recognize "BEGIN EC PUBLIC KEY", but it'd be 
> trivial to script copying the key to a temporary file and editing the PEM 
> header and footer.

I don't think that's what's happening here. They are likely different
formats, when you look at the asn1 structure.

BBB

Re: API to get BIGNUM member "top" in openssl 3.0

[Billy Brumley]

>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 structure is opaque, I can't imagine _really_ needing access
to ->top since that is a BIGNUM-internal concept.

Can you give a MWE for what you are trying to achieve?

Cheers,

BBB

Re: How to get rsa-private key in plain text format?

[Billy Brumley]

> > 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 -text

Since I would expect the rsa command to go the same was as the rsautl
command in the future.

Happy Friday!

BBB

Re: Query regarding openssl-3.0.0 ecdsa self tests

[Billy Brumley]

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 is right. It does only pairwise consistency test as the
> KAT is impossible to do for regular DSA and ECDSA due to random nonce
> being input of the signature algorithm and thus the signature always
> changes.
>
> Tomas
>
> On Fri, 2021-08-27 at 22:47 +0530, Nagarjun J wrote:
> > Hi,
> >
> > Does openssl-3.0.0 really does ecdsa KAT ? The post test logs says
> > "ECDSA KAT :PASS. But when i debuged the code it actually doing ECDSA
> > pairwise consistency test.
> >
> > Thanks,
> > Nagarjun
>
> --
> Tomáš Mráz
> No matter how far down the wrong road you've gone, turn back.
>   Turkish proverb
> [You'll know whether the road is wrong if you carefully listen to your
> conscience.]
>
>

Re: HMAC verification with EVP Interface

[Billy Brumley]

> > 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 attacker can adaptively construct a valid tag, or
forgery, for a chosen message (with no previous valid tag seen) by
varying tag bytes and submitting a chosen message with the candidate
tag for verification, and measuring the time. A regular memcmp will
early exit on the first mismatch between the purported tag and the
ground truth tag. In this way, the attack is linear in complexity.

This is the textbook example I give in my crypto courses for timing attacks.

Cheers,

BBB

Re: Install/Build openssl with following ciphers - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_G

[Billy Brumley]

> 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/news/changelog.html

BBB

Re: Edwards and public key validation

[Billy Brumley]

Hey John,

(Apologies I missed the reply all.)

Your Weierstrass tests are likely redundant with what EVP_PKEY_check
etc are doing under the hood. You should also be aware, with
Weierstrass curves, it is impossible to get a point that is not on the
curve through the OpenSSL API. (As far as I know.)

If you really want those Edwards tests, that functionality does not
exist yet in the library. Even if you roll your own at the application
level with BN functions, I would still suggest opening an issue on GH
because the missing function pointers I mentioned are library
deficiencies. When those get properly populated, you can eventually
throw away any application level code doing validation.

(If you are saying, your application exists solely for the purpose of
direct low level testing of PKCS11 devices / generating test vectors,
and does not pass this PKCS11 functionality through e.g. an OpenSSL
engine, then please just ignore me. Although in that case I would
kindly suggest OpenSSL might not really be the best tool for you.
Unless you are doing some kind of differential testing.)

Hope it helps,

BBB

On Sun, Feb 21, 2021 at 3:40 PM  wrote:
>
> Thanks Billy for getting back to me.
>
> The bigger picture on this is that I have a very comprehensive test harness 
> for testing PKCS#11 devices.  I already have developed and successfully run 
> tests that test Weierstrass curves.  I have successfully tested many PKCS#11 
> tokens for their implementation of NIST P-* and Brainpool curves against the 
> 4 tests specified in X9.62 (and now in NIST SP 800-186 (yes the draft one).  
> I use some of the OpenSSL functions to assist this - especially the BN 
> functionality.
>
> Because my test harness doesn't currently support Edwards curves - and 
> OpenSSL and SoftHSMv2 supports them - I thought it would be useful to add 
> Edward testing functionality into my harness.
>
> I can successfully generate ed25519 keypairs using SoftHSMv2 via the PKCS#11 
> interface - but now adding in tests to validate the  generated public keys - 
> according to NIST SP 800-186.
>
> I thought I would look at what OpenSSL does internally - including it tests.  
> That is where I noticed that the Edwards support is not as rich as the 
> support for "normal" EC curves.
>
> In fact to do the four tests in 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!
>
>
> Regards
>
> John
>
> >>-Original Message-
> >>From: Billy Brumley 
> >>Sent: 21 February 2021 12:06
> >>To: john.hug...@secid.co.uk
> >>Cc: openssl-users@openssl.org
> >>Subject: Re: Edwards and public key validation
> >>
> >>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 implemented something for Weierstrass curves – and have used helper
> >>functions to obtain the curve/group, domain parameters,
> >>EC_POINT_is_at_infinity()  etc etc – but nothing for Edwards.
> >>
> >>I don't believe you actually have to do that for Weierstrass curves.
> >>That is why EVP_PKEY_check and EVP_PKEY_public_check exist, and aren't even
> >>legacy EC specific -- thrown any PKEY at them (I cannot say 110% it is 
> >>doing all
> >>the validation you want, but check it in the debugger). You can reach it 
> >>even
> >>from the CLI
> >>
> >>openssl pkey -in key.pem -check
> >>
> >>
> >>I will reiterate what I wrote recently on the IETF CFRG mailing list 
> >>regarding
> >>OpenSSL's (EC) API, after which many armchair engineers either replied on 
> >>the
> >>list or directly to me, telling me how wrong I
> >>was:
> >>
> >>BBB: "If you (=application developer) are dealing with points directly in 
> >>OpenSSL,
> >>you are probably already doing it wrong."
> >>
> >>So your message (at least, about Weierstrass curves) is a good example of 
> >>what
> >>I said -- you've apparently rolled your own key validation, when the 
> >>library is
> >>perfectly capable of doin

Re: Edwards and public key validation

[Billy Brumley]

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 implemented something for Weierstrass curves – and have used helper 
> functions to obtain the curve/group, domain parameters, 
> EC_POINT_is_at_infinity()  etc etc – but nothing for Edwards.

I don't believe you actually have to do that for Weierstrass curves.
That is why EVP_PKEY_check and EVP_PKEY_public_check exist, and aren't
even legacy EC specific -- thrown any PKEY at them (I cannot say 110%
it is doing all the validation you want, but check it in the
debugger). You can reach it even from the CLI

openssl pkey -in key.pem -check


I will reiterate what I wrote recently on the IETF CFRG mailing list
regarding OpenSSL's (EC) API, after which many armchair engineers
either replied on the list or directly to me, telling me how wrong I
was:

BBB: "If you (=application developer) are dealing with points directly
in OpenSSL, you are probably already doing it wrong."

So your message (at least, about Weierstrass curves) is a good example
of what I said -- you've apparently rolled your own key validation,
when the library is perfectly capable of doing that for you, off the
shelf.

(John I am not trying to knock on your or any other well-intentioned
developer. I am just saying, with OpenSSL, developers should avoid
jumping straight to the lowest level API, and consider first what the
high level APIs can/should provide you.)


For ed25519 and ed448, your message (AFAICT, attaching a debugger to
openssl pkey ... -check) indicates those function pointers are not set
in the ed25519 and ed449 ameths:

https://github.com/openssl/openssl/blob/master/crypto/ec/ecx_meth.c#L726

(you can see, they are NULL here.)

I am going to guess part of the reason is because FIPS186-5 is only
draft status therefore OpenSSL has not mainlined anything, with the
possibility the standard will (and should, IMO) shift before being
finalized. In that sense when you write "NIST SP 800-186 appendix
D.1.3" I think it is very misleading because that is not actually a
standard -- only a draft as of this writing.


At least in the context of ed25519 and ed448, the D.1.3 validation
doesn't really make any sense. This is generally the problem when NIST
tries to backport modern cryptography to legacy standards. With these
modern curves, the whole idea is you don't have to validate like that
-- at least not the computational aspects of legacy EC key validation.


Having said that, I see no harm in discussing to add support for this
kind of validation.

Would you please raise an issue on GH?

Thanks,

BBB

openssl 3 and deprecation

[Billy Brumley]

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

Re: Generating and checking SM2 signatures

[Billy Brumley]

> 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 signature needs to be generated over H(data input) || H(some
> ID) , so I cannot use the EVP-Method as I understand it from
> https://www.openssl.org/docs/manmaster/man7/SM2.html (here, H is the SM3
> hash function). This would be possible to achieve by generating the
> digest and then using the (albeit deprecated) function ECDSA_do_sign for
> ECDSA but I don't know how to do it for SM2.

It seems like you're trying to roll your own SM2 -- don't do that ;)

> Is there any way to do this with openssl? Any help or pointer is very
> much appreciated!

I ... think it is possible directly with EVP and control strings. Step through

openssl pkeyutl -inkey private.key -in /some/file -rawin -sign
-pkeyopt sm2_id:foobar

in a debugger and that should get you on the right path.

BBB

Re: Compute EC_KEY starting from X or Y coordinate only

[Billy Brumley]

> 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? Or it is correctly
> considered as the x coordinate?

What you are saying and what you are doing are two different things.

Your code is at a very low level.

Above this there is some encoding of points, depending on any number
of standards. OpenSSL implements some of them, but at a higher level.

The low level API you're talking about provides maximum flexibility to
map that high level encoding in to the API's "x-coord + y-bit"
concept. It's up to you to figure out the details. (Including
determining if the encoding in OpenSSL matches what's expected in your
spec.)

You need to play around a bit with the lib -- you can't expect this
list to interpret the standard for you. Check the "test" folder for
sample code.

BBB

Re: Compute EC_KEY starting from X or Y coordinate only

[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 the y coordinate based on the y_bit argument.

EC_POINT_set_compressed_coordinates_GFp(group, p, x, 0, ...
EC_POINT_get_affine_coordinates_GFp(group, p, X0, Y0 ...

That will get you one of the points in X0, Y0.

EC_POINT_set_compressed_coordinates_GFp(group, p, x, 1, ...
EC_POINT_get_affine_coordinates_GFp(group, p, X1, Y1 ...

That will get you the other point in X1, Y1. (Where X0 = X1 = x.)

(But you are probably looking to do something cryptographically
interesting between set/get, which is application specific.)

Generally, in addition to the man pages which you seem to have found,
check the "tests" folder if you are looking for examples to get
started.

BBB

Re: Compute EC_KEY starting from X or Y coordinate only

[Billy Brumley]

Don't do that. As I said, the library is trying to tell you that's not a
point on the secp256k1 curve.

Quickly browsing the standard, you are likely looking for the prime256v1
curve.

BBB

On Fri, 25 Oct 2019, 9.28 Luca Di Mauro,  wrote:

> I think it is correct because I extracted the hexadecimal string from
> a packet contained in a pcap.
>
> This compressed point is created following the ETSI TS 103 097 v1.3.1
> standard for secured communications in the vehicular communication
> context
> (
> https://www.etsi.org/deliver/etsi_ts/103000_103099/103097/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  ha scritto:
>
> >> 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 the debugger, that is
> > probably what it is telling you.
> >
> > Where did this curve / x-coord pair come from?
> >
> > BBB
>
>
>
>

Re: Compute EC_KEY starting from X or Y coordinate only

[Billy Brumley]

> 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 the debugger, that is
probably what it is telling you.

Where did this curve / x-coord pair come from?

BBB

Re: Add ECDSA signature R and S to X509 structure

[Billy Brumley]

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/ECDSA_SIG_set0.html

You might find some snippets in ecdsatest.c.

Hope it helps,

BBB

Re: query related to openssl certificate generation of Ed X25519, X448

[Billy Brumley]

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:
>
> Hi ,
> Have query regarding generation of X255519 and X448 certificate chain
>
> Below is the script which i used to generate certificate chain of Ecdsa type.
> https://github.com/raja-ashok/sample_certificates/blob/master/ECC_Prime256_Certs/gen_ecc_cert.sh
>
> Now for generating EdDSA certificate chain I am using command from 
> (https://github.com/openssl/openssl/issues/6201). But with this command I am 
> able to generate only certificate and private key pair. But not able to 
> generate certificate chain.
>
>
>
> Below is the command used for generating end entity cert
>
> Openssl req -config openssl.cnf -new -key serverkey.pem 
> -subj”/C=IN/ST=kar/L=En/0=htipl/OU=team/CN=server” -outr server_cert.csr
>
> Openssl ca -config openssl.cnf  -cert rootcert.pem -key rootkey.pem 
> -extensions usr_cert -subj -days 360 -md sha256 -in server_cert.csr -out 
> server_cert.pem
>When i executed above command below errro is thrown
>
> Cant open ./root/private/cakey.pem for reading no such file or directory
>  System library:fopen:no such file or directory:crypto/bio/bss_file.c :72
> Bio routines :BIO_new_file:no such file crypto/bio:bss_file.c
>
>
>
>
> Tried another command to generated server cert that is openssl x509 -req 
> -days 360 -in server_cert.csr -signkey rootykey.pem -sha256 -out serever.crt
>
> For this   elliptic curve routines:pkey_ecd_ctrl:invalid digest 
> type:crypto/ec/ecx_meth.c
>  error will be thrown
>
>
> Please help me out to resolve this issue
>
>
> Thanks ,
> Soumya pattada.
>
>

Re: Blinding implementation in OpenSSL

[Billy Brumley]

("OpenSSL doesn't do" _scalar_ blinding! Coordinate blinding is there.
sorry ...)

Re: Blinding implementation in OpenSSL

[Billy Brumley]

> > 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 key from extracting from memory/swap/etc? Am I wrong?
>
> No, blinding is done during the private key operations to "randomize"
> the computations so timing and other side channels do not leak the
> private key. The private key itself is not modified.

Dmitry is correct in that coordinate blinding and scalar blinding are
different things. The question seems to be why doesn't OpenSSL do
coordinate blinding. (Hoping I'm not interpreting too much.)

BBB

Re: [openssl-users] possible C bugs in ecp_nistp521

[Billy Brumley]

> 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 internal code across the library
that makes assumptions about the inputs, e.g. in this case the
internal caller using some non-trivial representation that somehow
bounds limbs.

In this instance, I suspect Patrick's statement is valid -- hopefully
it's just a documentation typo and the bounds are tighter.

In any case, this (and any other might-be arithmetic bug) is
potentially a security issue so it shouldn't be discussed on a public
mailing list.

BBB
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Problems with deriving EC public key from private

[Billy Brumley]

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. Generate a key-pair of type NID_X9_62_prime256v1
> 2. Write the public and private components to memory
> 3. Read the private key back from memory, derive the public key, and write 
> that back out.
> 4. Compare this “round-tripped” public key to the public key generated in 
> step 2.
>
> The public key from step 2 almost always matches the public key from step 3, 
> but about 0.4% of the time they will differ. (The sample program runs a loop 
> to determine this.) Further experiments suggest it’s the 
> private_key_from_binary() function that is the problem, where I derive the 
> public key using EC_POINT_mul(). The sample program omits error checking, but 
> in the production code no errors are reported.
>
> Does anyone see a flaw in my logic, especially in how I’m deriving the public 
> key from the private key? Also let me know if this would be better submitted 
> as a GitHub issue, or even if it needs to be handled as a paid support 
> request.

The sample code just segfaults for me in the first iteration, before
really generating a key, so it's hard to test:

Program received signal SIGSEGV, Segmentation fault.
0x77a7e3e0 in pkey_set_type (pkey=0x380, type=408, str=0x0,
len=-1) at crypto/evp/p_lib.c:181
(gdb) bt
#0  0x77a7e3e0 in pkey_set_type (pkey=0x380, type=408,
str=0x0, len=-1) at crypto/evp/p_lib.c:181
#1  0x77a7e546 in EVP_PKEY_set_type (pkey=0x380, type=408) at
crypto/evp/p_lib.c:221
#2  0x77a7e663 in EVP_PKEY_assign (pkey=0x380, type=408,
key=0x557587c0) at crypto/evp/p_lib.c:249
#3  0x77a248fb in pkey_ec_keygen (ctx=0x55758760,
pkey=0x380) at crypto/ec/ec_pmeth.c:416
#4  0x77a80912 in EVP_PKEY_keygen (ctx=0x55758760,
ppkey=0x7fffdd18) at crypto/evp/pmeth_gn.c:107
#5  0x5046 in generate_ec_key () at foo.c:18
#6  0x5256 in main () at foo.c:73

But 0.4% is suspiciously close to 1/256, so I'm willing to bet your
problem surrounds your size assumptions in various functions. Check
the manpage of e.g. EC_POINT_point2oct and grep for usage in the
library, but the idea is to pass NULL first, then malloc, then pass
that pointer. BN_bn2bin is different. Probably the size won't be fixed
(e.g., there is a 1/256 chance you'll have one byte less, i.e. leading
zero).

So all the static 32 and 33 byte assumptions aren't holding.

Also BN_bn2bin and EC_KEY_oct2priv are not inverses of each other
IIRC. (The former is raw bytes, latter ASN1 encoding.)

BBB
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL 1.0.2: CVE-2018-5407 PortSmash

[Billy Brumley]

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
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Sign and verification using ECC 25519 curve- Bernstein

[Billy Brumley]

> > 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.

Shameless self plug -- libsuola is an OpenSSL engine providing
curve25519 and ed25519 support for 1.0.2, 1.1.0, and 1.1.1:

https://github.com/romen/libsuola

With different "backends" including libsodium or formally verified HACL*.

BBB
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Building openssl-1.1.1

[Billy Brumley]

> 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 "ldd /path/to/openssl"

I dunno what current recommendation is, but I normally use RPATH:

https://wiki.openssl.org/index.php/Compilation_and_Installation#Using_RPATHs

Hope it helps,

BBB
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] EDDSA support yet?

[Billy Brumley]

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:10 -0400, Robert Moskowitz wrote:
>> > > On 07/26/2018 10:07 AM, Viktor Dukhovni wrote:
>> > > > > On Jul 26, 2018, at 9:01 AM, Robert Moskowitz > > > > > t.co
>> > > > > m> wrote:
>> > > > >
>> > > > > My Fedora 28 shipped with:
>> > > > >
>> > > > > OpenSSL 1.1.0h-fips  27 Mar 2018
>> > > > >
>> > > > > Does that have ED25519 support?
>> > > >
>> > > > No.  You'd need 1.1.1 for that, it is currently in beta.
>> > > >
>> > >
>> > > No wonder Dr. Google failed me.  I will have to see what I can
>> > > do.
>> > > Perhaps put together a Rawhide system then try for a build.  But
>> > > that
>> > > takes for a time commitment.
>> > >
>> >
>> > Please note that there is now openssl-1.1.1-pre8 in Rawhide since
>> > yesterday. Hopefully the TLS-1.3 is final before Fedora 29 final
>> > release so we will not ship an openssl prerelease in it.
>> >
>>
>> Does this include the armv7hl image?  If so, it is not a stretch for
>> me
>> to build an image on one of my test Cubieboards.
>
> Fedora does builds for armv7hl. However I do not see any sufficiently
> fresh Rawhide image that would contain this build.
>
> --
> Tomáš Mráz
> No matter how far down the wrong road you've gone, turn back.
>   Turkish proverb
> [You'll know whether the road is wrong if you carefully listen to your
> conscience.]
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL 1.1.0 providing new OIDs to source code

[Billy Brumley]

> 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 objxref.pl obj_mac.num obj_xref.txt > obj_xref.h

Try 'make update' instead.

BBB
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] ECC private key length

[Billy Brumley]

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 the contents of a PEM ECC keypair file for the secp160k1/r1/r2 
> curves, OpenSSL says the private key is 161 bits:
>
> $ openssl ecparam -name secp160k1 -genkey -out test.pem
> $ openssl ec -in test.pem -text -noout
> read EC key
> Private-Key: (161 bit)
> priv:
> 77:76:fb:ae:7a:0b:97:98:aa:c0:70:7d:af:28:14:
> 6d:4f:03:d9:b5
> pub:
> 04:9b:98:38:4a:d0:e4:22:a2:3f:80:ce:02:90:02:
> d3:35:51:dc:8f:7b:5e:30:7d:2d:5e:98:6f:4b:9b:
> 4b:c8:01:1c:2d:ce:39:37:04:c5:61
> ASN1 OID: secp160k1
>
> However, following "priv:", there are only 20 bytes (160 bits). Why is this?
>
> When printing the keypair for other curves, the number of bytes after "priv:" 
> seem to always be the same or higher than the number of bits shown after 
> "Private-Key:".
>
> Thanks in advance,
> Frode
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Elliptic curve implementation sanity check

[Billy Brumley]

> * 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 Weierstrass
implementation" since 2009.

BBB
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Delay of email delivery for the list

[Billy Brumley]

 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
stopped archiving the OpenSSL lists, e.g.

http://openssl.org/support/community.html

Those don't have anything since January. I emailed MARC about it but
got no reply. Maybe the list owners should try?

BBB
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openssl dgst computes wrong HMAC?

[Billy Brumley]

 $ 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 -sha256 -mac HMAC -macopt hexkey:aabbcc
(stdin)= 985343745ee86b452c7c0b327171829c77e1a022f423d95156b52fa22083db8e

BBB
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: ECDSA - OpenSSL Implementation using the modulus (N) instead of field size (q)?

[Billy Brumley]

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 operations but is not
necessarily needed at the ECDSA level -- all that needs is the outputs
from scalar multiplication (i.e., p is used under the hood in
EC_POINT_mul and EC_POINT_get_affine_coordinates_GFp).

BBB


On Thu, Dec 19, 2013 at 2:52 AM, Paddy stonecold...@gmail.com wrote:
 Hi,

 From my understanding ECDSA has a modulus N and a field size of q.

 When generating the co-ordinates (x,y) using the generator and random value
 k - g * k = (x,y) - the x and y values should be restricted to the range x =
 [1, ... , q-1] and y = [1, ... , q -1].

 Then of course to get r we do:

 r = x mod N

 From what I can see in the implementation (ecs_ossl.c) when using
 ecdsa_sign_setup - the 'q' field size is never used!

 /*
  * Does the multiplciation of G (generator) * k to produce curve point (x,y)
  */
 EC_POINT_mul(group, temp_point, k, NULL, NULL, ctx)

 /*
  * Retrieve BIGNUM for X value (don't need y)
  */
 if (EC_METHOD_get_field_type(EC_GROUP_method_of(group)) ==
 NID_X9_62_prime_field)
 {
 if (!EC_POINT_get_affine_coordinates_GFp(group,
 tmp_point, X, NULL, ctx))
 {
 ECDSAerr(ECDSA_F_ECDSA_SIGN_SETUP,ERR_R_EC_LIB);
 goto err;
 }
 }

 /*
  * Get r value by doing r = x mod N
  */
 if (!BN_nnmod(r, X, order, ctx))
 {
 ECDSAerr(ECDSA_F_ECDSA_SIGN_SETUP, ERR_R_BN_LIB);
 goto err;
 }

 As well, in the verification of a signature 'q' should be used - but from
 the implementation in the do_verify method, when 'mod q' should be executed
 - it is actually doing it on the order N:

 /* u1 = m * tmp mod order */
 if (!BN_mod_mul(u1, m, u2, order, ctx))
 {
 ECDSAerr(ECDSA_F_ECDSA_DO_VERIFY, ERR_R_BN_LIB);
 goto err;
 }

 /* u2 = r * w mod q */
 if (!BN_mod_mul(u2, sig-r, u2, order, ctx))
 {
 ECDSAerr(ECDSA_F_ECDSA_DO_VERIFY, ERR_R_BN_LIB);
 goto err;
 }

 

 To sum up - when does the field size 'q' get used (as depicted in the
 algorithm description)? As it makes the r = x mod N operation pointless?



 --
 View this message in context: 
 http://openssl.6102.n7.nabble.com/ECDSA-OpenSSL-Implementation-using-the-modulus-N-instead-of-field-size-q-tp47743.html
 Sent from the OpenSSL - User mailing list archive at Nabble.com.
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: ECDSA - OpenSSL Implementation using the modulus (N) instead of field size (q)?

[Billy Brumley]

It's in the EC_GROUP structure: group-field. Check crypto/ec/ec_lcl.h. BBB

On Thu, Dec 19, 2013 at 9:54 AM, Patrick McCorry stonecold...@gmail.com wrote:
 Thank you Billy for the clarification - is there a way to retrieve the value 
 for p that is used under the hood? I assume the p value does not change 
 (unless the curve is changed).

 Sent from my iPhone

 On 19 Dec 2013, at 17:35, Billy Brumley bbrum...@gmail.com wrote:

 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 operations but is not
 necessarily needed at the ECDSA level -- all that needs is the outputs
 from scalar multiplication (i.e., p is used under the hood in
 EC_POINT_mul and EC_POINT_get_affine_coordinates_GFp).

 BBB


 On Thu, Dec 19, 2013 at 2:52 AM, Paddy stonecold...@gmail.com wrote:
 Hi,

 From my understanding ECDSA has a modulus N and a field size of q.

 When generating the co-ordinates (x,y) using the generator and random value
 k - g * k = (x,y) - the x and y values should be restricted to the range x =
 [1, ... , q-1] and y = [1, ... , q -1].

 Then of course to get r we do:

 r = x mod N

 From what I can see in the implementation (ecs_ossl.c) when using
 ecdsa_sign_setup - the 'q' field size is never used!

 /*
 * Does the multiplciation of G (generator) * k to produce curve point (x,y)
 */
 EC_POINT_mul(group, temp_point, k, NULL, NULL, ctx)

 /*
 * Retrieve BIGNUM for X value (don't need y)
 */
 if (EC_METHOD_get_field_type(EC_GROUP_method_of(group)) ==
 NID_X9_62_prime_field)
 {
if (!EC_POINT_get_affine_coordinates_GFp(group,
tmp_point, X, NULL, ctx))
{
ECDSAerr(ECDSA_F_ECDSA_SIGN_SETUP,ERR_R_EC_LIB);
goto err;
}
 }

 /*
 * Get r value by doing r = x mod N
 */
 if (!BN_nnmod(r, X, order, ctx))
 {
ECDSAerr(ECDSA_F_ECDSA_SIGN_SETUP, ERR_R_BN_LIB);
goto err;
 }

 As well, in the verification of a signature 'q' should be used - but from
 the implementation in the do_verify method, when 'mod q' should be executed
 - it is actually doing it on the order N:

 /* u1 = m * tmp mod order */
 if (!BN_mod_mul(u1, m, u2, order, ctx))
 {
ECDSAerr(ECDSA_F_ECDSA_DO_VERIFY, ERR_R_BN_LIB);
goto err;
 }

 /* u2 = r * w mod q */
 if (!BN_mod_mul(u2, sig-r, u2, order, ctx))
 {
ECDSAerr(ECDSA_F_ECDSA_DO_VERIFY, ERR_R_BN_LIB);
goto err;
 }

 

 To sum up - when does the field size 'q' get used (as depicted in the
 algorithm description)? As it makes the r = x mod N operation pointless?



 --
 View this message in context: 
 http://openssl.6102.n7.nabble.com/ECDSA-OpenSSL-Implementation-using-the-modulus-N-instead-of-field-size-q-tp47743.html
 Sent from the OpenSSL - User mailing list archive at Nabble.com.
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: ECDSA - OpenSSL Implementation using the modulus (N) instead of field size (q)?

[Billy Brumley]

... yet it seems you are free to use it as you please (like the rest
of the library does) internally, so it depends on what you are doing.
(Modifying the library or creating an application -- since you posted
code snippets I assumed the former, Matt points out the proper way
externally.)

BBB

On Fri, Dec 20, 2013 at 12:44 AM, Matt Caswell fr...@baggins.org wrote:
 On 19 December 2013 18:52, Billy Brumley bbrum...@gmail.com 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 you shouldn't really rely on it as it may change.

 Better is to use:
 int EC_GROUP_get_curve_GFp(const EC_GROUP *group, BIGNUM *p, BIGNUM
 *a, BIGNUM *b, BN_CTX *ctx);

 or

 int EC_GROUP_get_curve_GF2m(const EC_GROUP *group, BIGNUM *p, BIGNUM
 *a, BIGNUM *b, BN_CTX *ctx);

 as appropriate dependent on the type of curve that you have.


 On Thu, Dec 19, 2013 at 9:54 AM, Patrick McCorry stonecold...@gmail.com 
 wrote:
 From what I can see in the implementation (ecs_ossl.c) when using
 ecdsa_sign_setup - the 'q' field size is never used!

 /*
 * Does the multiplciation of G (generator) * k to produce curve point 
 (x,y)
 */
 EC_POINT_mul(group, temp_point, k, NULL, NULL, ctx)


 What you call 'q' (called 'p' within openssl) is used in this
 operation. It is a parameter of the group and is required to do the
 point multiplication.


 Matt
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Concerning the ECDSA_sig size

[Billy Brumley]

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
even smaller depending on how the modular reduction goes.

BBB

$ openssl ecparam -name prime256v1 -out private.pem -genkey -noout
$ echo -n 0xDEADBEEF | openssl dgst -sign private.pem -sha256 -out sig.bin
$ openssl asn1parse -in sig.bin -inform DER
0:d=0  hl=2 l=  70 cons: SEQUENCE
2:d=1  hl=2 l=  33 prim: INTEGER
:F5DCE3A83786EC0F54E0B0019DB481D30CB8DE5DB3F83349E5D00DCC87EEFEB1
   37:d=1  hl=2 l=  33 prim: INTEGER
:E5A3542861A325636D290A6133D99E7B4A28F252C5C9A5DA0B0B884D1AD70D29
$ echo -n 0xDEADBEEF | openssl dgst -sign private.pem -sha256 -out sig.bin
$ openssl asn1parse -in sig.bin -inform DER
0:d=0  hl=2 l=  68 cons: SEQUENCE
2:d=1  hl=2 l=  32 prim: INTEGER
:55B9639848C7A47DBDFEEC25B9D8CA772CB984E494BEB4DE4A843EED95254547
   36:d=1  hl=2 l=  32 prim: INTEGER
:0EF138F87E44CCBEE3BC509D661B9B565DA04D39BD0C3914A783B26762FF85B7


On Tue, Sep 17, 2013 at 12:48 PM, redpath redp...@us.ibm.com wrote:

 I am glad someone is asking this question.
 I sign the same data with same private key and sometimes the signature is
 63
 and sometimes it is 64 but overall the verification works for each
 anyhow.








 --
 View this message in context:
 http://openssl.6102.n7.nabble.com/Concerning-the-ECDSA-sig-size-tp46553p46559.html
 Sent from the OpenSSL - User mailing list archive at Nabble.com.
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

Re: ECDH-RSA and TLS 1.2

[Billy Brumley]

 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 in the code base?

BBB
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: ECDH vs. ECDHE

[Billy Brumley]

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 operations.

They also differ in how the handshake gets authenticated. (ECDH is
sort of implicit and ECDHE explicit.)

Note that unless you explicitly tell it not to, OpenSSL will reuse DH
keys anyway in ECDHE for performance reasons. This may or may not be a
problem for you depending on how your application is being launched.

BBB


On Mon, Apr 30, 2012 at 3:27 AM, Hanno Böck ha...@hboeck.de wrote:
 Hello,

 I'm trying to make sense out of the various abbrevations used for the
 SSL cipher suites listed by openssl ciphers.

 I've googled, but found no explanation of what ECDHE is and how it
 compares to ECDH.

 I'm aware that ECDH stands for elliptic curve diffie hellman key
 exchange (and I'm also - cryptographically - aware what that means -
 perfect forward secrecy and such).

 What is ECDHE, is it better than just ECDH and what's the difference?

 Yours,
 --
 Hanno Böck              mail/jabber: ha...@hboeck.de
 GPG: BBB51E42           http://www.hboeck.de/
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: RE: Esdsa test problem

[Billy Brumley]

It's likely you're hitting RT #1593:

http://rt.openssl.org/Ticket/Display.html?id=1593user=guestpass=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 yourself.

If none of the above work for you, contact me directly with the particulars.

Billy
On Aug 23, 2011 7:22 PM, Mark Shnaider m...@arx.com wrote:
 Hello ,
 I tested problematic signature using Bcrypt API on Window7 ,
 and function BCryptVerifySignature succeed .
 To my mind function ecdsa_do_verify implemented in the OpenSSL has bug.
 I do not know how solve this problem?
 Thanks for any help.
 Mark


 -Original Message-
 From: owner-openssl-us...@openssl.org [mailto:
owner-openssl-us...@openssl.org] On Behalf Of Mark Shnaider
 Sent: Monday, August 22, 2011 1:55 PM
 To: openssl-users@openssl.org
 Subject: Esdsa test problem

 Hello,
 We performed long test for Edsa sign(ECDSA_do_sign function) and verify
(ECDSA_do_verify function).
 The test sometimes fails after 20 -30 cycles.
 The each cycle use the same private and public key and the same digest
input.
 The output of function ECDSA_do_sign in this case depends only of random
returned
 from function RAND_bytes (fie rand_lib.c).

 We found random when ECDSA_do_verify fails:

 openssl-0.9.8g
 NID_X9_62_prime256v1 /* secp256r1 (23) */

 Data to sign - (5)
 31 32 33 34 35

 Returned Singed data from ECDSA_do_sign function (sin-r,sign-s 64 bytes)
 54 09 a3 be 2e 6d 11 de de 1a cf a3 8f 24 1d 6f 2c bf d7 0e ba 33 06 78 ea
da 93 88 7b 5c 43 93 ca f1 c7 d9 2f 6f 5d 54 54 06 7d a0 5e de d2 c0 5d 18
b5 8c 78 d5 88 14 2f c7 88 8c 0a 07 b6 ef

 EC private key value (34 bytes)
 02 20 1F 07 87 EE BE A6 89 F8 2D FD 56 BB B2 53 0F BE 97 0F 08 5C FE 3E 41
AD F7 13 D2 B7 F8 C9 F6 56

 EC public key value (65)
 04 36 1B E1 51 43 FF E6 E3 CB 3E 80 0F 7D 91 0D F2 C2 CF 75 87 05 47 F4 19
DD 1B CF 64 77 87 FF 88 BF 38 67 62 FF 61 8D D4 7B 39 08 C6 4A 63 17 DB 92
3D 52 0F AA B2 04 6A 02 DB C7 FF E4 96 19 5E

 Random from (32 bytes from function RAND_bytes )
 1e bb 51 83 7f b2 78 8d 09 0d c5 b9 bb 60 eb 79 2a c9 0c a5 04 f6 99 ec 4b
ec 0b 94 45 15 05 79

 Hex C format:
 Data to sign - (5)
 0x31,0x32,0x33,0x34,0x35

 Returned Singed data from ECDSA_do_sign finction (64 bytes)
 0x54,0x09,0xa3,0xbe,0x2e,0x6d,0x11,0xde,
 0xde,0x1a,0xcf,0xa3,0x8f,0x24,0x1d,0x6f,
 0x2c,0xbf,0xd7,0x0e,0xba,0x33,0x06,0x78,
 0xea,0xda,0x93,0x88,0x7b,0x5c,0x43,0x93,
 0xca,0xf1,0xc7,0xd9,0x2f,0x6f,0x5d,0x54,
 0x54,0x06,0x7d,0xa0,0x5e,0xde,0xd2,0xc0,
 0x5d,0x18,0xb5,0x8c,0x78,0xd5,0x88,0x14,
 0x2f,0xc7,0x88,0x8c,0x0a,0x07,0xb6,0xef

 EC private key value (34 bytes)
 0x02,0x20,0x1F,0x07,0x87,0xEE,0xBE,0xA6,
 0x89,0xF8,0x2D,0xFD,0x56,0xBB,0xB2,0x53,
 0x0F,0xBE,0x97,0x0F,0x08,0x5C,0xFE,0x3E,
 0x41,0xAD,0xF7,0x13,0xD2,0xB7,0xF8,0xC9,0xF6,0x56

 EC public key value (65)
 0x04,0x36,0x1B,0xE1,0x51,0x43,0xFF,0xE6,0xE3,
 0xCB,0x3E,0x80,0x0F,0x7D,0x91,0x0D,0xF2,
 0xC2,0xCF,0x75,0x87,0x05,0x47,0xF4,0x19,
 0xDD,0x1B,0xCF,0x64,0x77,0x87,0xFF,0x88,
 0xBF,0x38,0x67,0x62,0xFF,0x61,0x8D,0xD4,
 0x7B,0x39,0x08,0xC6,0x4A,0x63,0x17,0xDB,
 0x92,0x3D,0x52,0x0F,0xAA,0xB2,0x04,0x6A,
 0x02,0xDB,0xC7,0xFF,0xE4,0x96,0x19,0x5E

 Random from (32 bytes from function RAND_bytes):
 0x1e,0xbb,0x51,0x83,0x7f,0xb2,0x78,0x8d,
 0x09,0x0d,0xc5,0xb9,0xbb,0x60,0xeb,0x79,
 0x2a,0xc9,0x0c,0xa5,0x04,0xf6,0x99,0xec,
 0x4b,0xec,0x0b,0x94,0x45,0x15,0x05,0x79

 Please help us to solve this problem.
 What is wrong?
 Best regards
 Mark

 Mark Shnaider |Senior Software engineer | ARX
 phone: +972.3.9279543 | mobile: +972.54.2448543 | email: m...@arx.com |
www.arx.com

 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing List openssl-users@openssl.org
 Automated List Manager majord...@openssl.org
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing List openssl-users@openssl.org
 Automated List Manager majord...@openssl.org

Re: ECDSA public key token to/from binary

[Billy Brumley]

 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
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: ECDSA public key token to/from binary

[Billy Brumley]

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 *x, BIGNUM *y, BN_CTX *);

where EC_GROUP is setup for P-521 (have a look at
EC_GROUP_new_by_curve_name), EC_POINT is the public key from the
previous call; it dumps the coordinates to x and y, where you can use
BN_bn2bin or whatever you like. You'd reverse it with

int EC_POINT_set_affine_coordinates_GFp(const EC_GROUP *, EC_POINT *,
const BIGNUM *x, const BIGNUM *y, BN_CTX *);

followed by

int EC_KEY_set_public_key(EC_KEY *, const EC_POINT *);

While this is the manual way to do it that you've asked for, there are
a few caveats that can affect security so if possible I'd consider
standard (ANSI? P1363?) methods like EC_POINT_point2bn and so on.
Those also easily allow point compression if that's needed. In
general, poke around in include/openssl/ec.h and there is lots of
useful functionality, although not as much documentation.

Sincerely,

Billy


On Fri, Jul 15, 2011 at 10:54 AM, Kenneth Goldman kgold...@us.ibm.com wrote:
 I have to extract a binary (unsigned char *) representation of a public key
 from an ECDSA openssl key structure.  Later, I want to use that binary to
 reconstruct an openssl public key structure that I can use to verify a
 signature.  The curve is fixed - P521.

 I don't need any certificates, just a public key that I can embed in the
 verifier.

 Can someone point me toward sample code?  Or, can someone give me some
 hints?

 --
 Ken Goldman   kg...@watson.ibm.com
 914-784-7646 (863-7646)

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: key length discrepancy in key generated by sect233r1

[Billy Brumley]

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^{232} + a where a is a constant close to sqrt(2^{232}).
So with overwhelming probability, the top bit will always be zero.
(You can still hit these negligible private keys in OpenSSL; it just
won't happen in your lifetime. The implementation is correct.)

Billy

On Thu, May 12, 2011 at 9:37 AM, PMHager h...@prima.de wrote:
 dhoward wrote on Wednesday, May 11, 2011 20:01:

 I was recently playing around with OpenSSL's EC_KEY interface, specifically
 generating and examining keys generated using the curve sect233r1, when I
 decided to print the raw key out, in hex form. A quick analysis showed me
 that the key was stored in 232 bits, not 233 bits as the curve sect233r1
 requires - in fact, no matter how many keys I generated and checked this
 way, I was always missing a bit. Is there some reason that OpenSSL uses only
 232 bits instead of the full 233?

 Did you take into account the point compression as described in
 SEC 1: Elliptic Curve Cryptography
 2.3.3 EllipticCurvePoint-to-OctetString Conversion
 [http://www.secg.org/collateral/sec1_final.pdf]

 --

 Peter-Michael Hager - acm senior - HAGER-ELECTRONICS GmbH - Germany

 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-users@openssl.org
 Automated List Manager                           majord...@openssl.org

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org