Retrieving public key from x and y

[Benjamin Schäfer]

Hi there,

I'm trying to retrieve a public key, given x and y with the following code:

//x and y came from a webservice

std::string x = "40BA49FCBA45C7EEB2261B1BE0EBC7C14D6484B9EF8A23B060EBE67F97252BBC";

std::string y = "00987BA49DF364A0C9926F2B6DE1BAF46068A13A2C5C9812B2F3451F48B75719EE";

std::string pt = x + y;
CryptoPP::HexDecoder decoder;
decoder.Put((byte*)pt.data(), pt.size());
decoder.MessageEnd();

CryptoPP::ECP::Point q;
size_t len = decoder.MaxRetrievable();

q.identity = false;
q.x.Decode(decoder, len / 2);
q.y.Decode(decoder, len / 2);            //Wrong value
   
    CryptoPP::ECDSA<CryptoPP::ECP, CryptoPP::SHA256>::PublicKey publicKey;
    publicKey.Initialize(CryptoPP::ASN1::brainpoolP256r1(), q);

After Initializing the public key, I try to validate it:

CryptoPP::ECDSA<CryptoPP::ECP, CryptoPP::SHA256>::Verifier verifier(publicKey);

    CryptoPP::AutoSeededRandomPool prng;
    bool result = publicKey.Validate(prng, 3);

result is always false and I tried to get the int-values of x and y with the following:

const CryptoPP::ECP::Point& qq = publicKey.GetPublicElement();
    std::ostringstream cou;
    cou << "Q.x: " <<  qq.x;
    cou << "Q.y: " <<  qq.y;
    OutputDebugStringA(cou.str().c_str());

While x seems to be okay, y is not. And I don't know what to do... Is there anybody with a similar problem and a possible solution?


Best regards

[Benjamin Schäfer]

Ok, I was able to find out, why I get a wrong y coordinate (leading zeros in Hex-String brings up this crap). Validation seems to be okay.

But my problem afterward (which I didn't mention to this point, because I thought it will solve itself when I have a correct y-coordinate) is, that if I try to save this public key as PEM, I only get

-----BEGIN PUBLIC KEY-----
MFowMFow-----END PUBLIC KEY-----

as result. This was also my result with wrong y and failed validation.

[Jeffrey Walton]

Drop the leading 00 on the y-coordinate. The leading 00 is needed for
ASN.1 encoding. Crypto++ uses a simple concatenation (x || y). Not
that x and y need to be the size of a field element, which is
32-bytes. So (x || y) should be 64-bytes in total.

Also, are you sure the curve is brainpoolP256r1? ECDSA is usually over
secp256r1.

Jeff

[Jeffrey Walton]

> But my problem afterward (which I didn't mention to this point, because I thought it will solve itself when I have a correct y-coordinate) is, that if I try to save this public key as PEM, I only get
>
> -----BEGIN PUBLIC KEY-----
> MFowMFow-----END PUBLIC KEY-----
>
> as result. This was also my result with wrong y and failed validation.

Something sounds sideways. We probably need to see your code.

If I had to hazard a guess, I'd say there's something wrong with the
public key. The fields are empty.

The following works as expected for me.

$ cat test.cxx
#include <iostream>
#include <string>

#include "cryptlib.h"
#include "filters.h"
#include "eccrypto.h"
#include "osrng.h"
#include "files.h"
#include "sha.h"
#include "hex.h"

#include "pem.h"

int main(int argc, char* argv[])
{
using namespace CryptoPP;

AutoSeededRandomPool prng;
ECDSA<ECP, SHA256>::PrivateKey skey;
skey.Initialize(prng, ASN1::secp256k1());

ECDSA<ECP, SHA256>::PublicKey pkey;
skey.MakePublicKey(pkey);

FileSink fs("pubkey.pem");
PEM_Save(fs, pkey);

return 0;
}

Compiling it:

$ g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe test.cxx ./libcryptopp.a -o test.exe

Running it:

$ ./test.exe
$ cat pubkey.pem
-----BEGIN PUBLIC KEY-----
MFYwEAYHKoZIzj0CAQYFK4EEAAoDQgAEpqAXeayRz3sez/raCNqrx5dRp9GLrRaP
TmRu7a5OqBiJk7V34UolfNSRsDW6iWGmzlsUFJs4Ui+XYv493sS3ng==
-----END PUBLIC KEY-----

And cross check with OpenSSL:

$ openssl ec -in pubkey.pem -inform PEM -pubin -text
read EC key
Public-Key: (256 bit)
pub:
04:a6:a0:17:79:ac:91:cf:7b:1e:cf:fa:da:08:da:
ab:c7:97:51:a7:d1:8b:ad:16:8f:4e:64:6e:ed:ae:
4e:a8:18:89:93:b5:77:e1:4a:25:7c:d4:91:b0:35:
ba:89:61:a6:ce:5b:14:14:9b:38:52:2f:97:62:fe:
3d:de:c4:b7:9e
ASN1 OID: secp256k1

Jeff

[Jeffrey Walton]

On Wed, Sep 15, 2021 at 12:01 PM Jeffrey Walton <nolo...@gmail.com> wrote:
>
> > But my problem afterward (which I didn't mention to this point, because I thought it will solve itself when I have a correct y-coordinate) is, that if I try to save this public key as PEM, I only get
> >
> > -----BEGIN PUBLIC KEY-----
> > MFowMFow-----END PUBLIC KEY-----
> >
> > as result. This was also my result with wrong y and failed validation.

Here's what I am seeing with your data. It looks OK to me. I think we
need to see your program to determine what is going sideways.

$ cat test.cxx
#include <iostream>
#include <string>

#include "cryptlib.h"
#include "filters.h"
#include "eccrypto.h"
#include "osrng.h"
#include "files.h"
#include "sha.h"
#include "hex.h"

#include "pem.h"

int main(int argc, char* argv[])
{
using namespace CryptoPP;

std::string pt =
"40BA49FCBA45C7EEB2261B1BE0EBC7C14D6484B9EF8A23B060EBE67F97252BBC"
"987BA49DF364A0C9926F2B6DE1BAF46068A13A2C5C9812B2F3451F48B75719EE";

HexDecoder decoder;
decoder.Put((byte*)&pt[0], pt.size());
decoder.MessageEnd();

ECP::Point q;
size_t len = decoder.MaxRetrievable();

q.identity = false;
q.x.Decode(decoder, len/2);
q.y.Decode(decoder, len/2);

ECDSA<ECP, SHA256>::PublicKey pkey;

pkey.Initialize(ASN1::brainpoolP256r1(), q);

FileSink fs("pubkey.pem");
PEM_Save(fs, pkey);

return 0;
}

And:

$ ./test.exe
$ cat pubkey.pem
-----BEGIN PUBLIC KEY-----

MFowFAYHKoZIzj0CAQYJKyQDAwIIAQEHA0IABEC6Sfy6RcfusiYbG+Drx8FNZIS5
74ojsGDr5n+XJSu8mHuknfNkoMmSbytt4br0YGihOixcmBKy80UfSLdXGe4=
-----END PUBLIC KEY-----

And: $ openssl ec -in pubkey.pem -inform PEM -pubin -text
Public-Key: (256 bit)
pub:
04:40:ba:49:fc:ba:45:c7:ee:b2:26:1b:1b:e0:eb:
c7:c1:4d:64:84:b9:ef:8a:23:b0:60:eb:e6:7f:97:
25:2b:bc:98:7b:a4:9d:f3:64:a0:c9:92:6f:2b:6d:
e1:ba:f4:60:68:a1:3a:2c:5c:98:12:b2:f3:45:1f:
48:b7:57:19:ee
ASN1 OID: brainpoolP256r1

Jeff

[Benjamin Schäfer]

Ok, at least this gives me a ray of hope. So, to get rid of any interfering codelines, I did:

- Start Visual Studio

- New project (MFC Console, static linked MFC, Multibyte (unicode brings up the same result)

Full code:

#include <iostream>
#include <string>
#include "cryptlib.h"
#include "filters.h"
#include "eccrypto.h"

#include "files.h"
#include "sha.h"
#include "hex.h"
#include "pem.h"

int main()
{

    using namespace CryptoPP;

    std::string pt =
        "40BA49FCBA45C7EEB2261B1BE0EBC7C14D6484B9EF8A23B060EBE67F97252BBC"
        "987BA49DF364A0C9926F2B6DE1BAF46068A13A2C5C9812B2F3451F48B75719EE";

    HexDecoder decoder;
    decoder.Put((byte*)&pt[0], pt.size());
    decoder.MessageEnd();

    ECP::Point q;
    size_t len = decoder.MaxRetrievable();

    q.identity = false;

    q.x.Decode(decoder, len / 2);
    q.y.Decode(decoder, len / 2);

    ECDSA<ECP, SHA256>::PublicKey pkey;
    pkey.Initialize(ASN1::brainpoolP256r1(), q);

    FileSink fs("pubkey.pem");
    PEM_Save(fs, pkey);

    std::cout << "Hello World!\n";
}

But the result remains the same. OpenSSL:

C:\Program Files (x86)\OpenSSL-Win32\bin>openssl ec -in D:\pubkey.pem -inform PEM -pubin -text
read EC key
unable to load Key
22020:error:0908F066:PEM routines:get_header_and_data:bad end line:crypto\pem\pem_lib.c:812:

I really hope that I'm just stupid and don't see the obvious and your code/result speaks exactly for that. But I don't understand what exactly is going wrong here.

[Jeffrey Walton]

On Thu, Sep 16, 2021 at 2:44 AM Benjamin Schäfer <skullm...@gmail.com> wrote:
>
> Ok, at least this gives me a ray of hope. So, to get rid of any interfering codelines, I did:
>
> - Start Visual Studio
> - New project (MFC Console, static linked MFC, Multibyte (unicode brings up the same result)

My Windows testing looks OK to me.

I guess you are going to have to put your project somewhere we can see
it, like GitHub. I'll clone it and try to duplicate the issue.

Here's what I did for Windows testing... I add the PEM source files to
the nmake file:

$ git diff
diff --git a/cryptest.nmake b/cryptest.nmake
index 1164c25f..3e0bba0c 100644
--- a/cryptest.nmake
+++ b/cryptest.nmake
@@ -84,7 +84,8 @@ LIB_SRCS = \
sse_simd.cpp strciphr.cpp tea.cpp tftables.cpp threefish.cpp tiger.cpp \
tigertab.cpp ttmac.cpp tweetnacl.cpp twofish.cpp vmac.cpp wake.cpp \
whrlpool.cpp xed25519.cpp xtr.cpp xtrcrypt.cpp xts.cpp zdeflate.cpp \
- zinflate.cpp zlib.cpp
+ zinflate.cpp zlib.cpp \
+ pem_common.cpp pem_read.cpp pem_write.cpp x509cert.cpp

LIB_OBJS = \
cryptlib.obj cpu.obj integer.obj 3way.obj adler32.obj algebra.obj \
@@ -115,7 +116,8 @@ LIB_OBJS = \
sse_simd.obj strciphr.obj tea.obj tftables.obj threefish.obj tiger.obj \
tigertab.obj ttmac.obj tweetnacl.obj twofish.obj vmac.obj wake.obj \
whrlpool.obj xed25519.obj xtr.obj xtrcrypt.obj xts.obj zdeflate.obj \
- zinflate.obj zlib.obj
+ zinflate.obj zlib.obj \
+ pem_common.obj pem_read.obj pem_write.obj x509cert.obj

ASM_OBJS = \
rdrand-x86.obj rdrand-x64.obj rdseed-x86.obj rdseed-x64.obj
x64masm.obj x64dll.obj

Then, from a Developer Prompt, build the library:

>nmake /f cryptest.nmake
...

Build the test program test.cxx:

cl.exe /nologo /W4 /wd4231 /wd4511 /wd4156 /D_MBCS /Zi /TP /GR /EHsc
/DNDEBUG /D_NDEBUG /Oi /Oy /O2 /MT /FI sdkddkver.h /FI winapifamily.h
/c test.cxx /out:test_pem.obj

Link the test program:

link.exe /nologo /SUBSYSTEM:CONSOLE /DEBUG /DEBUG /OPT:REF
/MACHINE:X64 test_pem.obj cryptlib.lib kernel32.lib /out:test_pem.exe

Run the test program:

C:\Users\Jeff\Desktop\cryptopp>.\test_pem.exe

And dump the contents for the PEM file:

C:\Users\Jeff\Desktop\cryptopp>type pubkey.pem

-----BEGIN PUBLIC KEY-----
MFowFAYHKoZIzj0CAQYJKyQDAwIIAQEHA0IABEC6Sfy6RcfusiYbG+Drx8FNZIS5
74ojsGDr5n+XJSu8mHuknfNkoMmSbytt4br0YGihOixcmBKy80UfSLdXGe4=
-----END PUBLIC KEY-----

I used Visual Studio 2017 Command Line Tools (CLT). But just about any
modern version of Visual Studio should produce the same results. In
fact, I use cryptest.nmake to test back to Visual Studio 2003.

Jeff

[Benjamin Schäfer]

First of all: Thank you for your help and your patience! I really appreciate that.

I've made the same steps with nmake and built the library. Then I did the same steps with my source file you mentioned, everything on the CTL that came with VS2019 (should make no difference).

I uploaded the files here:
https://github.com/bredator/cryptopptest

Everything took place in the same directory where the cryptopp .h and .cpp files are located - so I didn't upload them again, because I took them out of the box. Also I added my .pem file, that came out as I reproduced all the steps.

[Jeffrey Walton]

On Thu, Sep 16, 2021 at 4:37 AM Benjamin Schäfer <skullm...@gmail.com> wrote:
>
> First of all: Thank you for your help and your patience! I really appreciate that.
>
> I've made the same steps with nmake and built the library. Then I did the same steps with my source file you mentioned, everything on the CTL that came with VS2019 (should make no difference).
>
> I uploaded the files here:
> https://github.com/bredator/cryptopptest
>
> Everything took place in the same directory where the cryptopp .h and .cpp files are located - so I didn't upload them again, because I took them out of the box. Also I added my .pem file, that came out as I reproduced all the steps.

You said you are using Visual Studio 2019, but you have a PDB file
vc140.pdb. That is Visual Studio 2015. See
https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B#Internal_version_numbering.

You cannot mix versions of Visual Studio. Everything needs to be built
using Visual Studio 2015 or Visual Studio 2019.

Jeff

[Jeffrey Walton]

On Thu, Sep 16, 2021 at 4:37 AM Benjamin Schäfer <skullm...@gmail.com> wrote:
> I've made the same steps with nmake and built the library. Then I did the same steps with my source file you mentioned, everything on the CTL that came with VS2019 (should make no difference).
>
> I uploaded the files here:
> https://github.com/bredator/cryptopptest

I need all the files you used, and I need all the commands you executed.

Jeff

[Benjamin Schäfer]

I just don't get it. Somehow I can't force the platform toolkit to be used. It remains at 140, when I compile with cl.exe. Going to the UI of VS2019, building the library with toolset 142 and cryptolib with 142 produces those results. When I open the CTL of VS2019 and run the cl.exe command, I get vc140.pdb as output. This drives me crazy - being one step away from the goal and can't figure out what's wrong.

[Benjamin Schäfer]

I've put a 7z archive with all file I've used into the repository. On the CTL I switched the working directory to the extracted one. Then I ran the following commands:

nmake /f cryptest.nmake

cl.exe /nologo /W4 /wd4231 /wd4511 /wd4156 /D_MBCS /Zi /TP /GR /EHsc /DNDEBUG /D_NDEBUG /Oi /Oy /O2 /MT /FI sdkddkver.h /FI winapifamily.h /c test_Pem.cpp /out:test_pem.obj

link.exe /nologo /SUBSYSTEM:CONSOLE /DEBUG /DEBUG /OPT:REF /MACHINE:X86 test_pem.obj cryptlib.lib kernel32.lib /out:test_pem.exe

After executing test_pem.exe, a .pem file appears with the known result.

I will try the same again when I'm at home on a different machine, just to be sure, nothing is screwed up on my working machine.

[Benjamin Schäfer]

Well, I tested it on another machine at home, but the result remains the same :(

[Benjamin Schäfer]

Could you provide me your .exe to test it on my machine? I still don't get it and will try it on a fresh and clean machine also.

[Jeffrey Walton]

On Fri, Sep 17, 2021 at 4:32 AM Benjamin Schäfer <skullm...@gmail.com> wrote:
>
> Could you provide me your .exe to test it on my machine? I still don't get it and will try it on a fresh and clean machine also.

Sure. https://www.cryptopp.com/test_pem.exe.zip

I don't recall if that was built with VS2017 or VS2019. You may need a
specific version of the Visual C++ runtime. They are distributed by
Microsoft. I think you can get them here:
https://support.microsoft.com/en-us/topic/the-latest-supported-visual-c-downloads-2647da03-1eea-4433-9aff-95f26a218cc0
.

Here are the two versions on my Windows machine:

VS2017:
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.0
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
C:\Users\Jeff>cl.exe
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27043 for x64
Copyright (C) Microsoft Corporation. All rights reserved.

VS2019:
**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.9.5
** Copyright (c) 2021 Microsoft Corporation
**********************************************************************
C:\Users\Jeff>cl.exe
Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29915 for x86
Copyright (C) Microsoft Corporation. All rights reserved.

Jeff

[Benjamin Schäfer]

Your exe works perfectly on my machine. I only have VS2019 on my machine here, it says:

**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.10.1

** Copyright (c) 2021 Microsoft Corporation
**********************************************************************

C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional>cl
Microsoft (R) C/C++-Optimierungscompiler Version 19.29.30037 für x86
Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.

The only thing, I can see here, is that your cl.exe on VS2017 says, it's 64 bit. I will investigate that too.

[Jeffrey Walton]

On Fri, Sep 17, 2021 at 5:11 AM Benjamin Schäfer <skullm...@gmail.com> wrote:
>
> Your exe works perfectly on my machine.

I don't know if that's good or bad...

> I only have VS2019 on my machine here, it says:
>
> **********************************************************************
> ** Visual Studio 2019 Developer Command Prompt v16.10.1
> ** Copyright (c) 2021 Microsoft Corporation
> **********************************************************************
>
> C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional>cl
> Microsoft (R) C/C++-Optimierungscompiler Version 19.29.30037 für x86
> Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.
>
> The only thing, I can see here, is that your cl.exe on VS2017 says, it's 64 bit. I will investigate that too.

OK, so I run Windows 8.1 Professional.

Regarding v16.9.5 (mine) vs v16.10.1 (yours), I've installed the
Windows SDKs and update them periodically. So I have a few SDKs
available. I think the Developer Command Prompts use the latest. So it
looks like I am behind you a bit.

I've got a Windows 10 VM somewhere. Let me see if I can get closer to v16.10.1.

Jeff

[Jeffrey Walton]

On Fri, Sep 17, 2021 at 6:06 AM Jeffrey Walton <nolo...@gmail.com> wrote:
>
> ...

> I've got a Windows 10 VM somewhere. Let me see if I can get closer to v16.10.1.

I just tried with my Windows 10 VM. It was OK there, too.

Do you know how to do something like SSH access on Windows? I'll give
you an account on my machine. You can look around and see what is
different about it.

Jeff

[Benjamin Schäfer]

This is somehow ridiculus. I just set up a brand new VM with Win10, new version. Also installed VS2019 Community. Nothing else, ran the upper commands on the content of the 7zip archive and I still get the same result. This can't be something with Intel vs. AMD, could it?

Your offer is fantastic, but I'm not that good in SSH access and besides an dxdiag-output, I won't even know what to look for :(

At the moment I ran out of ideas. I will sleep about that till monday, maybe there comes a idea around the corner. Maybe I did not need the pem as a file. The final goal is to build a JWT and sign it with the public key, constructed out of x and y. If I can find a way to use the public key directly, that may be a workaround of that problem - in the end I don't want a temporary file output anyway. It only grinds my gears that it works when compiled on "not-my-machine"-devices.

First I will try that sleep-thing, it helped me a lot in the past. Again, thank you very much for your help! That helped me that much, that my code itselt can't be that wrong, it stucks somewhere else.

[Jeffrey Walton]

On Friday, September 17, 2021 at 11:26:25 AM UTC-4 skullm...@gmail.com wrote:

This is somehow ridiculus. I just set up a brand new VM with Win10, new version. Also installed VS2019 Community. Nothing else, ran the upper commands on the content of the 7zip archive and I still get the same result. This can't be something with Intel vs. AMD, could it?

I don't install an IDE, like {Community|Professional|Enterprise} Edition. I just install the VS Build Tools. I also install an SDK.

Can you confirm you are using cryptopp Master and crypotpp-pem Master? I think you said you were using cryptopp Master, but I don't recall seeing something for crypotpp-pem.

Finally, I assume you are using the same runtime libraries for everything. Crypto++ uses static linking by default (/MT and MTd). You have to manually switch to dynamic runtimes (/MD and /MDd). Also see https://www.cryptopp.com/wiki/Visual_Studio#Runtime_Linking.

Jeff

[Jeffrey Walton]

On Friday, September 17, 2021 at 11:26:25 AM UTC-4 skullm...@gmail.com wrote:

... The final goal is to build a JWT and sign it with the public key, constructed out of x and y. If I can find a way to use the public key directly, that may be a workaround of that problem - in the end I don't want a temporary file output anyway. It only grinds my gears that it works when compiled on "not-my-machine"-devices.

For JWT, see https://www.cryptopp.com/wiki/JSON_Web_Encryption . It should supply most of the pieces you need for the tokens.

If the JWE article has gaps that are needed for JWT, we can write an article specifically for JWT.

Jeff

[Benjamin Schäfer]

Correction: I have to encrypt the JWT, not sign it. Signing is with the private key - which I don't have. I will take a look at the article and the linking. Maybe that will bring some hints for me. Thanks again :)

[Jeffrey Walton]

On Fri, Sep 17, 2021 at 11:59 PM Benjamin Schäfer
<skullm...@gmail.com> wrote:
>
> Correction: I have to encrypt the JWT, not sign it. Signing is with the private key - which I don't have. I will take a look at the article and the linking. Maybe that will bring some hints for me. Thanks again :)

This may help if you need to verify signatures:
https://www.cryptopp.com/wiki/JSON_Web_Signature

Jeff

[Benjamin Schäfer]

Okay, I've read the articles, but somehow I don't know where to start. I have to use the public key, generated out of x and y, algorith brainpool, to encrypt a JWT. The JWT is generated with the cpp-jwt library and now I really don't know what to do. How can I "convert" the public key I got from

CryptoPP::ECDSA<CryptoPP::ECP, CryptoPP::SHA256>::PublicKey publicKey;

    publicKey.Initialize(CryptoPP::ASN1::brainpoolP256r1(), q);

to the needed byte array. What do I have to use as initialisation vector? I'm no pro in crypto-algorithms but I have to use them for a specific project -_-

[Jeffrey Walton]

> How can I "convert" the public key I got from
>
> CryptoPP::ECDSA<CryptoPP::ECP, CryptoPP::SHA256>::PublicKey publicKey;
> publicKey.Initialize(CryptoPP::ASN1::brainpoolP256r1(), q);
>
> to the needed byte array. What do I have to use as initialisation vector? I'm no pro in crypto-algorithms but I have to use them for a specific project -_-

Sorry, I'm not sure what you need. I'm not familiar with cpp-jwt.

Maybe it would be easier to add Brainpool support to cpp-jwt. Then you
won't need to use other libraries. cpp-jwt will do everything you
need.

cpp-jwt uses OpenSSL for its cryptography. It should be relatively
easy to add the support.

Jeff

[Benjamin Schäfer]

In the end it could be broke down to: I want to encrypt a std::string (the JSON Web Token) with the public key I created out of x and y with crypto++. I will take a look into OpenSSL and what I could do with that, but this project seems to get out of hand.

[Jeffrey Walton]

On Tue, Sep 21, 2021 at 9:54 AM Benjamin Schäfer <skullm...@gmail.com> wrote:
>
> In the end it could be broke down to: I want to encrypt a std::string (the JSON Web Token) with the public key I created out of x and y with crypto++. I will take a look into OpenSSL and what I could do with that, but this project seems to get out of hand.

OK, so based on RFC 7516, they provide an example of public key
encryption using RSA/OAEP. That's what we show on our wiki page.

However, in RFC 7518
(https://datatracker.ietf.org/doc/html/rfc7518#section-4.1), the IETF
lists a boat load of other algorithms. But I don't see a "EC-ES256" or
similar that would indicate public key encryption using P-256.

Typically you don't simply encrypt with an elliptic curve. Typically
encryption using elliptic curves is a hybrid public key encryption
scheme, like ECIES. In ECIES, you encrypt a bulk encryption key for a
block cipher like AES under the public key. But even that is slippery
since you don't really encrypt like with RSA. Rather, you use a key
agreement scheme and the person doing the encryption performs half of
the key exchange using a temporary key and the other party's public
key. The other party with the private key performs the other half of
the key agreement, recovers the bulk encryption key, and then uses a
block cipher like AES to decrypt the actual message.

But getting back to your problem... Do you know which JSON algorithm
you are using?

Jeff

[Jeffrey Walton]

On Tue, Sep 21, 2021 at 10:40 AM Jeffrey Walton <nolo...@gmail.com> wrote:
> ...

> Typically you don't simply encrypt with an elliptic curve. Typically
> encryption using elliptic curves is a hybrid public key encryption
> scheme, like ECIES. In ECIES, you encrypt a bulk encryption key for a
> block cipher like AES under the public key. But even that is slippery
> since you don't really encrypt like with RSA. Rather, you use a key
> agreement scheme and the person doing the encryption performs half of
> the key exchange using a temporary key and the other party's public
> key. The other party with the private key performs the other half of
> the key agreement, recovers the bulk encryption key, and then uses a
> block cipher like AES to decrypt the actual message.

I don't mean to beat a dead horse, but here's what the wikipedia
article on EC says
(https://en.wikipedia.org/wiki/Elliptic-curve_cryptography):

<QUOTE>Elliptic curves are applicable for key agreement, digital
signatures, pseudo-random generators and other tasks. Indirectly, they
can be used for encryption by combining the key agreement with a
symmetric encryption scheme.</QUOTE>

So it is not just simple encryption like RSA.

> But getting back to your problem... Do you know which JSON algorithm
> you are using?

I should have restated... The algorithms are listed in RFC 7518, Section 4.1.

If you are dealing with some sort of custom scheme, do you have a link
to the specification and test vectors?

Jeff