I'm looking for a function or a library that can verify an ethereum signed message. I just want the signature verification function. Is there one readily available?
Related
JWT noob here, so sorry if this is a stupid question: Is it possible to sign JWTs with assymetric keys/certificates/etc?
If I understand JWTs right, the idea is that the client can authenticate to the server with them because they contain a signature the server can check.
All the examples I've seen online rely on the same secret key for creating and verifying the JWT.
Now, if I wanted to issue JWTs for different servers and did it like that, I'd have to give them my secret key (probably one for each server), and they'd be able to issue JWTs with it. I might not want to allow that. Also each server could only verify JWTs that were created specifically for it or one with the same key.
On the other hand, I do know that things can be signed with assynchronous algorithms in such a way that you can verify the signature with a public key, but sign stuff only with the private key.
That would solve the problem, because each server that wants to accept JWTs my server signed only has to download my public key. Does such a thing exist in JWT?
I think you mean an asymmetric algorithm, not an asynchronous algorithm.
The short answer is yes - you can use an asymmetric algorithm like RS512 to sign a token with a private key and then validate it with the matching public key. This way you don't have to share the secret outside of the service that signs the token.
Note that different libraries may support different algorithms, so make sure to check which algorithms the library you use supports. JWT.io has a pretty comprehensive listing of which libraries support which algorithms.
I'm receiving a JWT from Microsoft Azure, and I need to verify it on my server. The JWT is signed using RS256, i.e. using asymmetrical private/public key encryption.
I know that various libraries exist that can be used to verify a JWT signature directly from our backend server. But I'm curious if it wouldn't be possible to verify the JWT signature using an online service? Since it's using RS256 and not HS256, only public keys are involved in the verification process, no private keys or other secrets.
It seems like it would be simple to put up a REST service that can take an asymmetrically signed JWT, verify the signature and give back true/false. But when Googling I can't find any such services. Not even from big names in the JWT-world, like Auth0.
Why is that? Is there some security concern with letting another server verify the JWT signature?
For fun, I recently build a e-signature web app to allow users to add a handwritten signature to PDF (IE signing a TOS agreement).
It only took a couple minutes of research to realize my method of just added a written signature image to a PDF probably wouldn't hold up very well in a legal dispute.
A cryptographic digital signature is needed to verify the identity of the signee as well as ensure the document has not been altered since signing.
It got me wondering how companies like Docusign can provide digital signatures without having a certificate from the signee.
I found this marketing heavy explanation where it says that they are considered a trusted CA themselves.
Does this mean Docusign is issuing certificate to the users who are signing for them to sign with?
Even that you just need a link to a document envelope to sign (in most cases), this doesn't seem very meaningful.
UPDATE
Looks like you can "verify" signatures using acrobat reader to see the details. I opened up a PDF that I recently signed on Docusign and it appears that docusign is the signing identity?
Maybe I'm confusing "adding an e-signature" with "digitally signing", but shouldn't I be the Signed By __ identify?
Re: It got me wondering how companies like Docusign can provide digital signatures without having a certificate from the signee.
Answer: DocuSign enables three different types of electronic signatures:
Simple Electronic Signatures (SES) are legal in the US and other common law countries for many purposes. They don't require a digital cert from the signer.
Advanced Electronic Signatures (AES) are a digital signature which provides a guarantee that the signer was identified by a digital cert and that the signed document has not been changed since it was signed. This type of signature is required for some purposes in common law countries (like the US) and for many purposes in civil law countries.
Qualified Electronic Signatures (QES) are like AES signatures but the signer cert is granted by a company that is authorized directly or indirectly by a government authority.
How it works
If the DocuSign signature is an SES signature then no signer cert is needed. And yes, these types of signatures are valid and legal for most any type of transaction in the US. See a lawyer for details on whether your transaction type can use this type of eSignature or not. Here is a summary of the law for the US.
For these types of signatures, when you download the signed document from DocuSign, the downloaded document is digitally signed (using an AES signature) by the company DocuSign. The DocuSign AES signature assures you that the document is the same as the document that was signed by one or more signers who used SES via DocuSign.
For AES signatures via DocuSign, the signer can use a cert that is issued to them by DocuSign. Or the signer can use a cert issued to them by their associated company/organization.
For QES signatures via DocuSign, the signer's cert comes from a qualified trust provider.
Re: Does this mean Docusign is issuing certificate to the users who are signing for them to sign with?
Yes, for AES signatures, DocuSign can issue a cert to a signer. But that is not what happened in your example screenshot. In your screenshot, DocuSign enabled the signer to use a SES eSignature. DocuSign then provided an AES signature to guarantee to any relying party that the document was SES signed via DocuSign.
X.509 certificate has signature value.
I want to verify the signature in client certificate with public key of root CA or intermediate CA.
I know the information of both of them. But I don't know what messages needed.
I want to ask what's the messages needed to generate the signature value?
It only need Issuer information or Subject Name by hex? or is the issuer arbitrary when generating a certificate?
Verifying the signature is not sufficient, you need to validate the certificate chain and all of the associated policy constraints. In Windows / C you would use CertGetCertificateChain(https://learn.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-certgetcertificatechain), but each platform has its own approach to this problem. Its far more complicated than most realize (https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf) so please stick to platform APIs for this validation.
Although Thinktecture.IdentityServer supports signing a jwt using a symmetric key, the OidcClient class does not support validating a token using one - it only supports validating tokens signed using a certificate.
Is this deliberate and are there problems or any limitations with signing a jwt with the client secret?
I am getting some push back with requiring client apps to have a certificate and if I can avoid it without compromising security I would like to do so.
IIRC OidcClient is quite old - we just did not implement it. And you apps don't need a certificate, they just need to be able to verify a signature using asymmetric crypto.
Using a symmetric key makes only sense for server-based apps since that key must be stored securely (otherwise anyone who reverse engineers the app can create valid identity tokens).
The other option is to send the id token back to idsrv to validation (for clients that don't have the required crypto libraries). This endpoint does not exist currently in beta 1 - but is on our todo list.