I’m experimenting with using the web crypto API. and want to verify signatures from the browser in Elixir (or erlang, so far I have used only modules that are also available in erlang).
The steps in the browser are:
- generate a key pair.
- export public-key in PEM format
- Sign message
- Base64 encode the signature
- Send the PEM public-key and encoded signature to the backend
The steps to verify on the backend:
- decode PEM
- decode signature
The exact code I run is available in this gist.
This files can be used by copy pasting
sign.js into the browser console and
verify.ex into an iex session.
Doing this the verify function will return false.
I have tried several variations of how I encode/decode. I do need these encode steps because I eventually want to send the signature in the
authorization header of a request.
Any help would be greatly appreciated.
The JS API returns a ‘raw’ signature, whereas OTP’s
:public_key API expects a DER-encoded signature.
message = "abc"
encoded_signature = "AOqjfvb1P0fYdbnq+f3XsbOR/Lylq4csC5e1Ks4cKRTcWKQyH4CVr/XRHCmZDEWOpaA8gwuM3Z3qD21vMaixySUPASTDnd1J8shNx51MCbONIReTNuH53kzxykLpf0riSyMbEBQtie4/pxlrolUOsDja2f/ikgM/lGXtCTXz2faV4m2Y"
public_PEM = "-----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----"
raw_signature = Base.decode64!(encoded_signature)
size = div(byte_size(raw_signature), 2)
<<r::binary-size(size), s::binary-size(size)>> = raw_signature
signature = <<48, 129, 136, 2, size, r::binary, 2, size, s::binary>>
[key_entry] = :public_key.pem_decode(public_PEM)
public_key = :public_key.pem_entry_decode(key_entry)
# returns true
To clean up that code, here’s a module that can help convert from raw format to DER format using
I might add it to x509 at some point…
Thanks for this. So to use the functions bellow I would use?
signature = ECDSASignature.new(raw_signature) |>ECDSASignature.to_der()
Also does the
:public_key module not expect DER encoding for RSA keys? My original code seams to work for rsa signatures
I am curious to know what are you trying to achieve with this approach of sending the signature in the
authorization header of a request?
An RSA signature is just a single integer, which is simply encoded as a binary by all implementations. An ECDSA signature consists of two integers. Some implementations wrap those in an ASN.1 ‘Sequence’ and others just concatenate them (which may require zero-padding of the smaller of the two, to remove ambiguity about where to split).
Just some experiments at the moment, but in general i’m looking at alternatives to passwords
Client side generated secrets can be reverse engineered in mobile apps, that ship their code obfuscated in binaries, and in the web is even more easy to reverse engineer this process, thus anything generated programmatically in the client side cannot be trusted for authentication purposes.
Sorry I was not meaning the code used to generate the secret… What I was trying to say is that any secret generated in the client side can be reused by an automated script to access the backend as the genuine web app or mobile app.
Another approach is that the automated script can use the same code of your app to generate the authorization secret, thus your backend will trust in requests from automated bots, when you want it to only trust in requests from your genuine web app or mobile app.
Ahh I think I see. I don’t think I have any problems with people using their own client to access my API, if they want to go to that effort
So it seems I am missing the point of what your research is trying to achieve???
Is there any way to achieve this result using an HEX public key?
Would be great to sign via Web3 a message using user private key, and validating it on a backend server using the public key.
Tried to experiment it but failed converting a public wallet address into ed_public_key struct.