JWS proof least significant bit change

[mkhraisha]

Running into a rather confusing issue, hope someone hear can shed some light.
If you create a VC that outputs a proof that is a jws such as Ed25519Signature2018, and verify it then you get a correct response.
If you take the same VC then increment the last bit in the signature to a character that is within 15 characters ahead, it still returns "verified". i.e. in the case of the character g you can change it to v but not w
If you take the same VC then decrement the last bit in the signature, it fails.

    "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://w3id.org/vc-revocation-list-2020/v1"
    ],
    "id": "urn:uuid:d1155a37-7931-4828-a819-cf0a55c57226",
    "type": [
        "VerifiableCredential"
    ],
    "issuer": "did:key:z6MktiSzqF9kqwdU8VkdBKx56EYzXfpgnNPUAGznpicNiWfn",
    "issuanceDate": "2010-01-01T19:23:24Z",
    "credentialStatus": {
        "id": "https://api.did.actor/revocation-lists/1.json#0",
        "type": "RevocationList2020Status",
        "revocationListIndex": 0,
        "revocationListCredential": "https://api.did.actor/revocation-lists/1.json"
    },
    "credentialSubject": {
        "id": "did:example:123"
    },
    "proof": {
        "type": "Ed25519Signature2018",
        "created": "2022-11-03T20:29:58Z",
        "verificationMethod": "did:key:z6MktiSzqF9kqwdU8VkdBKx56EYzXfpgnNPUAGznpicNiWfn#z6MktiSzqF9kqwdU8VkdBKx56EYzXfpgnNPUAGznpicNiWfn",
        "proofPurpose": "assertionMethod",
        "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..W288kEF5Zqvk9QSz_nznlIIHVEAWRDbosjngjUBppJRZ76E7kaTpljnh5SHzhXlS9zUgdv3HnpOHyv7iZeQaCg"
    }
}

After talking to @msporny it appears this is due to base64url encoding.

1. would this allow me to modify the data and still get a matching signature? (current assumption is no because this is just the padding)
2. what are the security implications?

[mkhraisha]

@msporny @dlongley

[dlongley]

@mkhraisha,

would this allow me to modify the data and still get a matching signature? (current assumption is no because this is just the padding)

No, because, like you said, it's just the padding. When you decode the signature value (whether it's modified in the way you described or not), you get the same raw signature bytes.

what are the security implications?

The same as for any other signature scheme that uses base64 encoding (like everything in JOSE).

Changing the value should not affect the integrity of the data that the signature is over (as the signature is itself separate from that and, as mentioned above, decoding the value produces the same signature bytes). However, if someone were to hash the data (including the signature value), of course the hashes would be different. Whether that is a problem for someone depends on their use of such hashes, etc.

[msporny]

@mkhraisha it seems like your question has been answered. Is there anything further that we need to do wrt. changes to the specification or specification text? If there is a change that is needed to the specification, I expect it would be editorial in nature (like something put in the Security Considerations section) and could be done after the specification enters the Candidate Recommendation phase.

[mkhraisha]

The question has been answered, but I think it is important to note in the security considerations post candidate rec .

[msporny]

The question has been answered, but I think it is important to note in the security considerations post candidate Rex.

Ok, can do. There's got to be some text out there in an IETF RFC on this given that it's a general issue w/ JOSE and its use of base64url encoding. We might just point to whatever that RFC says on the matter from our security considerations section.

[msporny]

None of the current cryptosuites that the VCWG is standardizing use JWS encoding. All JWS cryptosuites have been abandoned by the group, so there is nothing left to say on this issue.

Marking this issue as pending close.

[mkhraisha]

I believe this can be closed.