Skip to content

Commit 296898c

Browse files
julikanakinj
authored andcommitted
Add a good explainer
1 parent 1d91509 commit 296898c

File tree

1 file changed

+14
-0
lines changed

1 file changed

+14
-0
lines changed

lib/jwt/jwk/ec.rb

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -206,6 +206,20 @@ def create_ec_key(jwk_crv, jwk_x, jwk_y, jwk_d)
206206

207207
def decode_octets(base64_encoded_coordinate)
208208
bytes = ::JWT::Base64.url_decode(base64_encoded_coordinate)
209+
# Some base64 encoders on some platform omit a single 0-byte at
210+
# the start of either Y or X coordinate of the elliptic curve point.
211+
# This leads to an encoding error when data is passed to OpenSSL BN.
212+
# It is know to have happend to exported JWKs on a Java application and
213+
# on a Flutter/Dart application (both iOS and Android). All that is
214+
# needed to fix the problem is adding a leading 0-byte. We know the
215+
# required byte is 0 because with any other byte the point is no longer
216+
# on the curve - and OpenSSL will actually communicate this via another
217+
# exception. The indication of a stripped byte will be the fact that the
218+
# coordinates - once decoded into bytes - should always be an even
219+
# bytesize. For example, with a P-521 curve, both x and y must be 66 bytes.
220+
# With a P-256 curve, both x and y must be 32 and so on. The simplest way
221+
# to check for this truncation is thus to check whether the number of bytes
222+
# is odd, and restore the leading 0-byte if it is.
209223
if bytes.bytesize.odd?
210224
"\0".b + bytes
211225
else

0 commit comments

Comments
 (0)