An implementation of JOSE standards (JWE, JWS, JWT) in Go



godoc godoc license build coverage

Package jose aims to provide an implementation of the Javascript Object Signing and Encryption set of standards. This includes support for JSON Web Encryption, JSON Web Signature, and JSON Web Token standards.

Disclaimer: This library contains encryption software that is subject to the U.S. Export Administration Regulations. You may not export, re-export, transfer or download this code or any part of it in violation of any United States law, directive or regulation. In particular this software may not be exported or re-exported in any form or on any media to Iran, North Sudan, Syria, Cuba, or North Korea, or to denied persons or entities mentioned on any US maintained blocked list.


The implementation follows the JSON Web Encryption (RFC 7516), JSON Web Signature (RFC 7515), and JSON Web Token (RFC 7519) specifications. Tables of supported algorithms are shown below. The library supports both the compact and JWS/JWE JSON Serialization formats, and has optional support for multiple recipients. It also comes with a small command-line utility (jose-util) for dealing with JOSE messages in a shell.

Note: We use a forked version of the encoding/json package from the Go standard library which uses case-sensitive matching for member names (instead of case-insensitive matching). This is to avoid differences in interpretation of messages between go-jose and libraries in other languages.


Version 2 (branch, doc) is the current stable version:

import ""

Version 3 (branch, doc) is the under development/unstable version (not released yet):

import ""

All new feature development takes place on the master branch, which we are preparing to release as version 3 when it's ready. Version 2 will continue to receive critical bug and security fixes. Note that starting with version 3 we are using Go modules for versioning instead of as before.

Version 1 (on the v1 branch) is frozen and not supported anymore.

Supported algorithms

See below for a table of supported algorithms. Algorithm identifiers match the names in the JSON Web Algorithms standard where possible. The Godoc reference has a list of constants.

Key encryption Algorithm identifier(s)
RSA-PKCS#1v1.5 RSA1_5
AES key wrap A128KW, A192KW, A256KW
AES-GCM key wrap A128GCMKW, A192GCMKW, A256GCMKW
ECDH-ES (direct) ECDH-ES1
Direct encryption dir1

1. Not supported in multi-recipient mode

Signing / MAC Algorithm identifier(s)
RSASSA-PKCS#1v1.5 RS256, RS384, RS512
RSASSA-PSS PS256, PS384, PS512
HMAC HS256, HS384, HS512
ECDSA ES256, ES384, ES512
Ed25519 EdDSA2

2. Only available in version 2 of the package

Content encryption Algorithm identifier(s)
AES-CBC+HMAC A128CBC-HS256, A192CBC-HS384, A256CBC-HS512
Compression Algorithm identifiers(s)

Supported key types

See below for a table of supported key types. These are understood by the library, and can be passed to corresponding functions such as NewEncrypter or NewSigner. Each of these keys can also be wrapped in a JWK if desired, which allows attaching a key id.

Algorithm(s) Corresponding types
RSA *rsa.PublicKey, *rsa.PrivateKey
ECDH, ECDSA *ecdsa.PublicKey, *ecdsa.PrivateKey
EdDSA1 ed25519.PublicKey, ed25519.PrivateKey
AES, HMAC []byte

1. Only available in version 2 or later of the package


godoc godoc

Examples can be found in the Godoc reference for this package. The jose-util subdirectory also contains a small command-line utility which might be useful as an example as well.

  • jwe using Curve P521, ECDH-ES, and A256GCM does not always work with with other implementations

    jwe using Curve P521, ECDH-ES, and A256GCM does not always work with with other implementations

    I am not able to encrypt/decrypt within Java and Go using Curve P521, ECDH-ES, and A256GCM using the same values for curve X, Y, and D. When I try to take the encrypted value from Java and Decrypt in Go it fails (about half the time) and vice versa it fails with:

    Go: square/go-jose: error in cryptographic primitive

    Sometimes it works though.

    I am manually creating the KeyPair in both programs with the same X, Y, and D. Here is a link to my stackoverflow question.

    bug help wanted 
    opened by dodgeware 23
  • Custom headers and additional header support

    Custom headers and additional header support

    The JWE spec supports more than just the two fields allowed currently in go-jose (alg and enc). You can also specify a kid which is really important when using symmetric encryption like AES with JWE.

    I'm attempting something like so:

        alg := jose.KeyAlgorithm("dir")
        enc := jose.ContentEncryption("A256GCM")
        encrypter, err := jose.NewEncrypter(alg, enc, resp.Plaintext)
        if err != nil {
        obj, err := encrypter.Encrypt([]byte(contents))
        obj.Header.KeyID = "XXXXXX"

    but when I attempt to base64 decode the header (first part), I still only see alg and enc.

    I'm proposing either changing the Encrypter interface to support new funcs for adding kid specifically or a more generic one to allow setting headers that are unrelated to the encryption and key methods being used.

    I can maybe make a PR on this but I need to know which way you'd rather go first.


    enhancement help wanted 
    opened by lusis 16
  • Export Unverified Payload

    Export Unverified Payload

    I want to access JWS payload before it gets verified.

    Use Case: I am building an Open ID Connect clients which accepts ID Tokens (i.e. JWTs signed by JWS) issued by multiple issuers. In this client, parse a JWS payload at first, then recognize the issuer by iss claim of the payload and retrieve JWKs via Open ID Connect Discovery flow, finally verify the JWS using retrieved JWKs.

    I looked for a go-jose's API that exports an unverified JWS payload but could not find. Do you have any plans to support this use case?

    opened by yosida95 12
  • x5c / x5t parameters

    x5c / x5t parameters

    Is it possible to use x5c parameters with go-jose? I want to marshall a RSA private key along a x509 certificate (for HTTP over TLS).


    opened by aeneasr 12
  • Claims encoding/decoding

    Claims encoding/decoding

    Claims represented as concrete type.

    Follows JWT spec on interpretation of claim fields values, namely:

    • NumericDate can be represented as either int or float
    • Audience can be either string or array of strings

    Timestamps are normalized by checking Time.IsZero, otherwise negative timestamp values would show up in encoded JSON.

    Validator is checking Expiry/NotBefore using leeway as indicated in a spec. Current time is provided as argument to Validator.Validate call. Unit tests for validator are still pending.

    opened by shaxbee 12
  • Version 2.5.0: has breaking changes in terms of certificate verfication

    Version 2.5.0: has breaking changes in terms of certificate verfication


    -Add support for x5u, x5t, and x5t#S256 headers for JWK (#242).

    #issue 1 has some breaking changes particularly in the jwk.go, where

    method name : func (k *JSONWebKey) UnmarshalJSON(data []byte) (err error)

    k.CertificateThumbprintSHA1 = raw.X5tSHA1.bytes() k.CertificateThumbprintSHA256 = raw.X5tSHA256.bytes()

    here the raw value is attempted to convert in bytes but it does not work as expected in fact, it returns base64 decoded value for kid attribute in the token.

    as a result following conditions always fails,

    if x5tSHA1Len > 0 && x5tSHA1Len != sha1.Size { return errors.New("square/go-jose: invalid JWK, x5t header is of incorrect size") } if x5tSHA256Len > 0 && x5tSHA256Len != sha256.Size { return errors.New("square/go-jose: invalid JWK, x5t header is of incorrect size") }

    here sha1.Size is the checksum size which is expected to be 20 bytes. but the value which we are assigning k.CertificateThumbprintSHA1 is not a checksum instead it's a raw hash for sha1 or sha256. So when x5tSHA1Len := len(k.CertificateThumbprintSHA1))is executed length turns out to be 40

    solutions: use x5tSHA1Len := len(sha1.Sum(k.CertificateThumbprintSHA1))

    #issue 2

    // If certificate chain and thumbprints are set, verify correctness. if len(k.Certificates) > 0 { leaf := k.Certificates[0] sha1sum := sha1.Sum(leaf.Raw) sha256sum := sha256.Sum256(leaf.Raw) if len(k.CertificateThumbprintSHA1) > 0 && !bytes.Equal(sha1sum[:], k.CertificateThumbprintSHA1) { return errors.New("square/go-jose: invalid JWK, x5c thumbprint does not match x5t value") }

    	if len(k.CertificateThumbprintSHA256) > 0 && !bytes.Equal(sha256sum[:], k.CertificateThumbprintSHA256) {
    		return errors.New("square/go-jose: invalid JWK, x5c thumbprint does not match x5t#S256 value")

    I don't understand what are we trying to validate here but this condition seems to be failing always.

    feel free to reach out in case of questions or queries

    opened by hiten1988 10
  • Add support for PBES2 Key algorithms

    Add support for PBES2 Key algorithms

    Add functionality to support for password-based cryptography with the optional key algorithms:

    • PBES2-HS256+A128KW
    • PBES2-HS384+A192KW
    • PBES2-HS512+A256KW

    PBES2 algorithms require two new parameters in the header p2c (pbkdf2 number of iterations) and p2s (salt). I added those parameters in the recipient and they are optional. Safe defaults are used if they are left empty, 100,000 for the count and a 128 bits salt. NIST recommendation is at least 10,000, but some applications like 1Password are already using 100k.

    I'm open to suggestions, do a PR for the master branch, change the defaults, or use EncrypterOptions to add the extra parameters instead of the recipient.

    opened by maraino 10
  • Support Base64URL-encoded

    Support Base64URL-encoded "n" parameter in JSONWebKey

    The JWA spec says:

    The "n" (modulus) parameter contains the modulus value for the RSA public key. It is represented as a Base64urlUInt-encoded value.

    However, Base64URL-encoded "n" parameter cannot be unmarshalled into JSONWebKey in go-jose.

    Here is what I'm trying to do:

    var d jose.JSONWebKeySet
    if err := json.Unmarshal(body, &d); err != nil {
    	return err

    When the "n" parameter in the json body is Base64URL encoded instead of Base64 encoded, I get the error illegal base64 data at input byte 343. I think this is because encoding/json package expects a Base64-encoded string when decoding to []byte.

    Not sure if I'm missing something?

    This can be solved by changing the type of N in rawJSONWebKey to string. If I'm right, let me know, I'll gladly submit a PR.

    opened by yun-wang 10
  • Switch to case-sensitive encoding/json fork

    Switch to case-sensitive encoding/json fork

    r: @alokmenghrajani @mcpherrinm @sqshh @jsha @rolandshoemaker

    Fixes issue #73 by switching to a forked, case-sensitive version of encoding/json (from Go 1.6).

    Changes in square/go-jose:

    • Switch to forked json package
    • Add tests for case-sensitive parsing behavior
    • Drop Go 1.2 support (broken with forked json)

    Changes in the forked encoding/json package:

    • Remove fold.go, fold_test.go (contained case-sensitive folding functions)
    • Set equalFold to be bytes.Equal in encode.go (no more case-sensitive matching)
    • Removed example_test.go (broke build on older Go versions)

    Also updated some of the test cases in the forked json package, as they were depending on the case-insensitive parsing behavior. In particular, decode_test.go (c.f Ambig struct) was updated.

    opened by csstaub 10
  • Regenerate X.509 cert with SAN extension (v2)

    Regenerate X.509 cert with SAN extension (v2)

    The certificate for CN=TrustedSigner has been regenerated with SAN extension. Due to missing keys, certs for CN=TrustedCA & CN=IntermediateCA have been regenerated as well.

    Resolves #330.

    opened by pippo 9
  • Fix JWK Thumbprint/kid for Ed25519 keys

    Fix JWK Thumbprint/kid for Ed25519 keys

    The format string edThumbprintTemplate was broken, missing opening " before x property name. It cause interoperability issues with other JOSE implementations.

    opened by szkiba 8
  • Add fallback to std URLEncoding for JWKs

    Add fallback to std URLEncoding for JWKs

    In case RawURLEndocing fails while decoing JWKs, try if falling back to Standard URLEncoding can decode - which may be the case i.e with padded JWKs

    Fixes #373

    opened by oxygen0211 4
  • x5t and x5t#S256 headers with padding breaking key unmarshalling

    x5t and x5t#S256 headers with padding breaking key unmarshalling

    Hi everyone,

    I am using go-jose as a transient dependency (in oauth2-proxy) at a customer's in combination with Oracle Access Manager. Since the release of 2.5.1 (I guess due to the fix of #299 ), validation of the JWK in use is breaking with the error message square/go-jose: invalid JWK, x5t header has invalid encoding.

    I think I narrowed the issue down to Base64 padding of the x5t and x5t#S256 headers breaking the decoding of the headers in and respectively for x5t#S256.

    For compliance reasons, I am not able to submit the real key for testing but I was able to construct a test key based on that is triggering the same behavior:

          "kty": "RSA",
          "e": "AQAB",
          "x5t": "wCAFGcBT8CeA4U2mYa4z3xg0-Zw=",
          "kid": "SIGNING_KEY",
          "x5c": [
          "alg": "RS256",
          "n": "xWVFlx-E925RYQjPnKpKtHLqUonJMI1_xyM1f4Orly9RzpcaXX7ajEkgMAzffL3rsvBQkPLmO0vHIHs4KNdWoVUmbLZerjDdfLZQl3FZuXcZKXtzVOLyBVt2SNp_k23VgyGN7-8tiAJWC9SFIPBdWD8U2dxqM9izSEn9pvoMyR5iyaEoZepazJQPLysrF23g1_gI8Bo2EUAHdO5atfGfT2YQbZPSOBWiq09QYwMRBuI0Ye0TI3GwYs1x3_2LoporOj-fkYCl4ki4JK2ifwk-TA5o29cdNSuSoA7rTZL3u-dNw0c6OPxvnW6LtCn4RpieZTh7W2sYLg8ozBwd3PHNTw"

    Unfortunately, this one does not have a SHA 256 fingerprint, though.

    My propose on handling this would be to fall back to decoding with base64.URLEncoding in case base64.RawURLEncoding is failing:

    // x5t parameters are base64url-encoded SHA thumbprints
    // See RFC 7517, Section 4.8,
    x5tSHA1bytes, err := base64.RawURLEncoding.DecodeString(raw.X5tSHA1)
    // we might get base64 encoded parameters that include padding
    // this is not supported by RawURLEncoding, so as a backup, let's try to decode with URL encoding
    if err != nil {
    	x5tSHA1bytes, err = base64.URLEncoding.DecodeString(raw.X5tSHA1)
    if err != nil {
    	return errors.New("square/go-jose: invalid JWK, x5t header has invalid encoding")

    However, I am not a Go expert, so please correct me if there is a better way. Currently I am checking if I can submit a proper PR for this without breaking compliance.

    opened by oxygen0211 0
  • Unencoded Payload Option WithBase64 still encodes payload to base64 through MarshalJSON?

    Unencoded Payload Option WithBase64 still encodes payload to base64 through MarshalJSON?

    As far as I understand, go-jose implements the JSON Web Signature (JWS) Unencoded Payload Option ( via the SigningOption: func (*SignerOptions) WithBase64.

    I tried setting this option via: opt := (&jose.SignerOptions{}).WithBase64(false), but it still leads to a base64 encoded payload when using full serialization. The option is indeed evaluated and the payload is not base64 encoded in signing.go (, but then, in the FullSerialize() the rawJSONWebSignature containing a Payload *byteBuffer is serialized.

    For the byteBuffer, a custom JSON Marshalling method is implemented in encoding.go ( and this method always encodes base64:

    func (b *byteBuffer) MarshalJSON() ([]byte, error) {
    	return json.Marshal(b.base64())

    Did I do something wrong using the WithBase64() option or doesn't this mean setting WithBase64 still leads to base64-encoded payload?

    opened by smo4201 0
  • AutoRefreshing JWK ?

    AutoRefreshing JWK ?

    Does this project have helper methods or something for a jwk that fetch keys from a remote url ? something like below

           const url = ""
    	jwks, err := NewJWKFromWeb(url)
    	key, err := jwks.Key("id1")
    opened by asanka88 1
  • square/go-jose: error in cryptographic primitive

    square/go-jose: error in cryptographic primitive

    I have a decryption key and a JWE token that I can decrypt in python like so:

    from jose import jwe, jwt
    from jose.utils import base64url_decode
    decryption_key_bytes = base64url_decode("ODFfdsdfs879s8fs=")
    decrypted_token = jwe.decrypt(TOKEN, decryption_key_bytes)
    print("Decrypted token:")
    print("\nToken contents:")
    print(jwt.decode(decrypted_token, None, options={"verify_signature": False}))

    Doing the "same" In golang results in the above error:

    package main
    import (
    const customersJweRaw = "sfsdfsdfsfs.sfsfsdfsf.sfsfsfsf"
    func main() {
    	base64Decode, err := base64.StdEncoding.DecodeString("ODFfdsdfs879s8fs=")
    	if err != nil {
    	jwe, err1 := jose.ParseEncrypted(customersJweRaw)
    	if err1 != nil {
    	bytes, err2 := jwe.Decrypt(jose.JSONWebKey{Algorithm: "A256KW", Use: "A256GCM", Key: base64Decode})
    	if err2 != nil {

    I have also tried not specifying the encryption / decryption algorithm and just pass the key like so: jwe.Decrypt(base64Decode), but got the same result.

    Bellow is the screenshot of the document for the token origin. I am not creator of the token, we get it from the client.

    Screen Shot 2022-01-25 at 12 24 45 PM
    opened by apryiomka 1
  • v2.6.0(Jun 5, 2021)

    Last release from the v2 branch, includes various changes and bug fixes.

    For future releases please see v3 at:

    Source code(tar.gz)
    Source code(zip)
  • v2.5.1(May 1, 2020)

  • v2.5.0(Apr 13, 2020)

    New Features

    • Add support for x5u, x5t, and x5t#S256 headers for JWK (#242).
    • Add support for RFC 7638 canonical kid for JWK (#269).

    Bug Fixes

    • Add error checking in jose-util to avoid nil referencing (#250).
    • Documentation improvements (#274, #280, #289).
    Source code(tar.gz)
    Source code(zip)
  • v2.4.1(Dec 16, 2019)

    Bug Fixes

    • Fixes a bug introduced in v2.4.0 that could cause a panic on invalid inputs (#282).
    • Improves performance of parsing payloads with a lot of whitespace (#279).
    Source code(tar.gz)
    Source code(zip)
  • v2.4.0(Oct 23, 2019)

    New Features

    • Add support for the b64 header parameter (#230).
    • Add functions to handle detached signatures (#234).
    • Expose an interface for opaque key encryption/decryption (#261, #257).

    Bug Fixes

    • Fixes a issue with ECDSA on P-521, whereby the generated shared secret derived for encryption was computed incorrectly (#267, #245).
    • Fixes salt length for new RSA-PSS messages to be equal to the hash length, as required by RFC 3447 (#232).
    • Don't include the kid header in a JWT if the key id is an empty string (#227).
    Source code(tar.gz)
    Source code(zip)
  • v2.3.1(Apr 10, 2019)

    Fixes a bug in the serialization of ED25519 keys to JWK (JSON), where X/D values ended up being switched for one another in the serialized output (see #224). Reading a serialized private key would also end up switching the X/D values for another, so keys that were serialized/deserialized with old versions of go-jose would work fine (values should end up in the correct place again). However, sharing a private key with another library would have caused problems. If you have private keys that were previously serialized to JWK using this library, the X/D values will be incorrect and will need to be switched in the JSON serialization before the key can be deserialized with an updated version of go-jose.

    Source code(tar.gz)
    Source code(zip)
  • v2.3.0(Feb 27, 2019)

    New Features

    • Add support for unwrapping JSON Web Key Set in the jwt sub-package. This means the key passed to Claims or Decrypt can now be a set of keys (of type *jose.JSONWebKeySet), and the key will be selected automatically based on the key id in the header of the token.

    Bug Fixes

    • Improves handling of exp, iat and nbf claims. This means proper handling for zero dates (#214), don't error if optional exp and nbf claims are missing from the token (#220), and perform an extra check on iat if it is present (#217). Note that expiration in tokens is optional per standard, if you want to require expiration or other claims to be absolutely present in a token be sure to check the claim is present.

    Note this release also drops support for Go 1.5 and Go 1.6, we now require Go 1.7 or later.

    Source code(tar.gz)
    Source code(zip)
  • v2.2.2(Jan 2, 2019)

    Exports the random reader used for internal randomness to make deterministic tests possible (#212). This allows consumers of the library to add tests that can compare known inputs/outputs deterministically.

    Source code(tar.gz)
    Source code(zip)
  • v2.2.1(Dec 5, 2018)

    This release adds stricter checks (#210) for handling JWKs with elliptic keys. As per RFC 7518, Section to the length of this octet strings for X/Y/D values in JWKs MUST be the full size of a coordinate for the curve specified in the "crv" parameter. As a result, invalid JWKs that were previously accepted (e.g. a JWK where the padding was missing on X/Y coordinates) will now be rejected when parsing them.

    Source code(tar.gz)
    Source code(zip)
  • v2.2.0(Nov 30, 2018)

    Bug Fixes

    • Check that key size when matches cipher for DIRECT encryption mode (issue #204, fix in #205)
    • Fix auth tag length for A192CBC-HS384, A256CBC-HS512 to match spec (issue #206, fix in #207)

    Note: We bumped the minor version in this release because the changes in #207 fixes a compatibility issue with the implementations of the A192CBC-HS384 and A256CBC-HS512 ciphers. The library didn't correctly follow the JOSE specification (RFC 7518) when encrypting and as a result ciphertexts produced with square/go-jose were incompatible with other JOSE implementations. Ciphertexts produced from other libraries with those ciphers would still decrypt correctly. If you were encrypting with A192CBC-HS384 and A256CBC-HS512 using old versions of this library there might be compatibility concerns when upgrading.

    Source code(tar.gz)
    Source code(zip)
  • v2.1.9(Sep 23, 2018)

    This release contains a small change to emit pre-computed values on RSA keys when serializing to a JWK, see pull request #203. This fixes issue #202.

    Source code(tar.gz)
    Source code(zip)
  • v2.1.8(Aug 8, 2018)

  • v2.1.7(Jul 25, 2018)

    New Features

    • Added new cryptosigner sub-package to sign using crypto.Signer implementations (#179).
    • Added new OpaqueSigner (et al) interfaces for implementing custom, opaque signers (#179).

    This release also contains several minor bug fixes and makes unit tests pass in Go 1.11.

    Source code(tar.gz)
    Source code(zip)
  • v1.1.2(Jul 25, 2018)

  • v2.1.6(Mar 29, 2018)

    This release adds support for parsing certificate chains from x5c headers in messages, and expose a function to verify & read them through a new jose.Header#Certificates(opts x509.VerifyOptions) function (see #178).

    Source code(tar.gz)
    Source code(zip)
  • v2.1.5(Mar 23, 2018)

    This release adds DetachedVerify and DetachedVerifyMulti methods on JSONWebSignature to verify detached signatures, i.e. JWS objects where the payload has been stripped and is handled separately from the signature (#175).

    Source code(tar.gz)
    Source code(zip)
  • v1.1.1(Mar 23, 2018)

    Fixes a build issue with Go 1.10 and updates an incorrect error message. This makes the v1 branch compatible with the latest version of Go, but if you haven't already you should probably update to the v2 branch!

    Source code(tar.gz)
    Source code(zip)
  • v2.1.4(Feb 28, 2018)

    Notable changes

    • Fix build issue with Go 1.10 (#173)
    • Use consistent types for ed25519 keys (#165)
    • Added JSONWebKey.Public() to derive public key from private key (#166)
    • Added jwk-keygen tool contributed by @darkk (#166)
    • Expose protected/unprotected headers separately (#164)
    Source code(tar.gz)
    Source code(zip)
  • v2.1.3(Sep 13, 2017)

    Notable changes

    • Add basic support for ED25519 signing via (issue #68, PR #154)
    • Fix panic when creating signer with JWK and setting EmbedJWK to true (issue #157, PR #161)
    • Fix an issue that would cause a panic when encountering null values in headers (PR #159)
    Source code(tar.gz)
    Source code(zip)
  • v2.1.2(Jun 7, 2017)

  • v2.1.1(May 3, 2017)

  • v2.1.0(Feb 25, 2017)

    Notable changes Support for custom/extra header values (#136) thanks to @hlandau. This is a slight change to the v2 interface, so the minor version has been bumped. Also includes a bug fix for symmetric keys to produce JWS objects (#139) thanks to @b1v1r.

    Source code(tar.gz)
    Source code(zip)
  • v2.0.1(Nov 21, 2016)

    Notable changes Support for nested (encrypted and signed) tokens in jwt package (#125) Support for non-pointer JSONWebKey in base package (#124)

    Source code(tar.gz)
    Source code(zip)
  • v2.0.0(Oct 28, 2016)

    Cleaner interface The API for the base package has been reworked. In particular, encrypter/signer/decrypter/verifier objects are now immutable. An options struct can be passed to set various options when creating the object now. This is a bit more flexible and should make it easier to add new things in the future.

    Support for JWT Thanks to @shaxbee, go-jose now includes a new jwt sub-package with functions for dealing with encrypted/signed JWTs. See the documentation for the jwt package for more information.

    Source code(tar.gz)
    Source code(zip)
  • v1.1.0(Sep 23, 2016)

    Fixes and improvements

    • Add new VerifyMulti function to verify multi-signature JWS objects. The existing Verify function has been changed to only accept single-signature objects. This ensures that callers do not accidentally accept multi-signature objects in contexts where they are not expected (#111, 2c5656a).
    • Add new DecryptMulti function to decrypt multi-recipient JWE messages. The existing Decrypt function has been changed to only accept single-recipient messages. This ensures callers do not accidentally accept multi-recipient messages in contexts where they are not expected (#111, 2c5656a).
    • Add checks when deserializing JWS objects to ensure that any embedded JWK (if present) is valid and represents a public key (not private/symmetric key) as per spec. This is to ensure that callers don't accidentally end up accepting embedded JWKs that represent symmetric/private keys (#112, e8e21a9).

    Note that this represents a subtle API change, as the Decrypt and Verify functions are now stricter than before and only accept single-signature/single-recipient inputs. To reflect this change, the minor version has been bumped.

    Source code(tar.gz)
    Source code(zip)
  • v1.0.5(Sep 3, 2016)

    Security fixes Cast all size calculations to uint64 to avoid int overflows on 32-bit architectures (789a4c4)

    Other changes Proper import paths on v1 branch to fix build (3bd67f4)

    Source code(tar.gz)
    Source code(zip)
  • v1.0.4(Aug 31, 2016)

    Security fixes For ECDH-ES key derivation (in JWE), ensure that received public key (from an "epk" header field on an encrypted message) is on expected elliptic curve before performing any cryptographic operations. This also adds various sanity checks for EC keys other places, e.g. when parsing JWK blobs with embedded EC keys. See commits c758193, 03c5c6e, d163d44.

    Other changes Fix expand command in jose-util (c18180c) Remove support for std_json build tag (1f36a88)

    Source code(tar.gz)
    Source code(zip)
  • v1.0.3(Aug 8, 2016)

  • v1.0.2(May 2, 2016)

    Notable changes Switch jose-util to use alecthomas/kingpin for flag parsing (15af859) Add JsonWebKey.Valid method to check key validity (h/t @rolandshoemaker, d2a8471)

    Source code(tar.gz)
    Source code(zip)
  • v1.0.1(Apr 20, 2016)

Go implementation of BLAKE2 (b) cryptographic hash function (optimized for 64-bit platforms).

Go implementation of BLAKE2b collision-resistant cryptographic hash function created by Jean-Philippe Aumasson, Samuel Neves, Zooko Wilcox-O'Hearn, an

Dmitry Chestnykh 90 Jul 11, 2022
Go implementation of SipHash-2-4, a fast short-input PRF created by Jean-Philippe Aumasson and Daniel J. Bernstein.

SipHash (Go) Go implementation of SipHash-2-4, a fast short-input PRF created by Jean-Philippe Aumasson and Daniel J. Bernstein (

Dmitry Chestnykh 248 Dec 25, 2022
A simplified blockchain implementation in Golang

A simplified blockchain implementation in Golang

Ivan Kuznetsov 3.7k Dec 31, 2022
A full node Bitcoin (BSV) implementation written in Go

bsvd bsvd is a full node Bitcoin (BSV) implementation written in Go (golang). This project is a port of the bchd codebase to Bitcoin (BSV). It provide

null 42 Dec 25, 2022
Merchant API reference implementation

mAPI More details available in the BRFC Spec for Merchant API. The old golang (v1.1) implementation is no longer being maintained and has been moved t

Bitcoin SV 21 Dec 14, 2022
`age-plugin-yubikey` implementation, encrypt things with a Yubikey/any PIV card

This is an age plugin for PIV cards/Yubikey. Your secret is kept safe on the tamperproof hardware, while letting you use the age command-line.

Tv 22 Aug 10, 2022
Interblockchain communication protocol (IBC) implementation in Golang.

ibc-go Interblockchain communication protocol (IBC) implementation in Golang built as a SDK module. Components Core The core/ directory contains the S

COSMOS 310 Jan 7, 2023
Implementation of the Filecoin protocol, written in Go

Project Lotus - 莲 Lotus is an implementation of the Filecoin Distributed Storage Network. For more details about Filecoin, check out the Filecoin Spec

Filecoin 2.5k Jan 9, 2023
Go implementation of Ethereum proof of stake

Prysm: An Ethereum Consensus Implementation Written in Go This is the core repository for Prysm, a Golang implementation of the Ethereum Consensus spe

Prysmatic Labs 2.9k Jan 1, 2023
Pure Go implementation of the NaCL set of API's

go-nacl This is a pure Go implementation of the API's available in NaCL: Compared with the implementation in

Kevin Burke 531 Dec 16, 2022
Go implementation of the Data At Rest Encryption (DARE) format.

Secure IO Go implementation of the Data At Rest Encryption (DARE) format. Introduction It is a common problem to store data securely - especially on u

Object Storage for the Era of the Hybrid Cloud 309 Dec 18, 2022
Celer cBridge relay node implementation in Golang

cBridge Relay Node Official implementation of cBridge relay node in Golang. Prerequisites Prepare Machine To run a cBridge relay node, it is recommend

Celer Network 62 Sep 27, 2022
A simple implementation of SHA-256 Algorith in Go Language

SHA-256 in Go This is not a serious/efficient implementation of SHA-256 in Go. You can use the official package for that. This is just for learning pu

Krona Emmanuel 6 Sep 22, 2022
Go Implementation of the Spacemesh protocol full node. 💾⏰💪

A Programmable Cryptocurrency go-spacemesh ?? ⏰ ?? Thanks for your interest in this open source project. This repo is the go implementation of the Spa

Spacemesh 590 Dec 29, 2022
A Commander for Go implementation of official Ethereum Client

Young A Commander for Go implementation of official Ethereum Client by zhong-my. Overview Young Dependencies Young stands on the shoulder of many grea

Zhong MingYang 1 Oct 14, 2021
An implementation of the Filecoin Distributed Storage Network

Project Lotus - 莲 Lotus is an implementation of the Filecoin Distributed Storage Network. For more details about Filecoin, check out the Filecoin Spec

null 0 Oct 27, 2021
Official Go implementation of the Catcoin project

Go Ethereum Official Golang implementation of the Ethereum protocol. Automated builds are available for stable releases and the unstable master branch

null 1 Jan 7, 2022
Official Golang implementation of the Ethereum protocol

Go Ethereum Official Golang implementation of the Ethereum protocol. Automated builds are available for stable releases and the unstable master branch

StarWORKS Global 0 Nov 24, 2021
A Go Implementation of ECDH-PSI

A Go Implementation of ECDH-PSI This is a Go implementation of elliptic curve diffie hellman private set intersection (ECDH-PSI) with only standard li

Zilin Zhu 1 Dec 16, 2021