Verifying web crypto signatures in erlang/Elixir

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
  • use :public_key.verify

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.

1 Like

The JS API returns a ‘raw’ signature, whereas OTP’s :public_key API expects a DER-encoded signature.

Try this:

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 :public_key:

I might add it to x509 at some point…


Thanks for this. So to use the functions bellow I would use?

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

1 Like

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.

What about Crypto.getRandomValues()?

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