didcomm-rust
didcomm-rust copied to clipboard
sicpa-dlab
unpackedmessage.as_value() does not provide decrypted version of the message
What
When I receive a message that is encrypted, and run it through unpack with the right secrets and resolvers. I expect that I get an object I can work with that is decrypted and possible to read the datat itself.
But the object that is provided is an object with a ciphertext. Since I was not the one encrypting the initial ciphertext, I expect that the library will provide me with a way to get the clear text message out.
Here is an example of the unpacked.as_value() message
{
"id": "36f2a86e-5b25-4baf-9f7f-40d978590316",
"typ": "application/didcomm-plain+json",
"type": "https://didcomm.org/routing/2.0/forward",
"body": {
"next": "did:peer:2.Vz6MkhMTSwCfytUNmrEQ4We5i6B2ywM8hAcHvRDD293QGrqSS.Ez6LSm3LPosAtT2qUtFNU9Y2y9P9wQUfJjGgs98uchVJtZjfS.SeyJpZCI6IiNkaWRjb21tIiwidCI6ImRtIiwicyI6Imh0dHBzOi8vZGV2LW9wZW4tbWVzc2FnZXMtYXBpLWx0aDRnb3dkeXEtZXcuYS5ydW4uYXBwL21lc3NhZ2VzIiwiYSI6WyJkaWRjb21tL3YyIl19"
},
"attachments": [
{
"data": {
"json": {
"ciphertext": "EvyxDoHnIYCc0iFhenovIaiJfnIDWlE1brmoqLlNaVoHJ6oGuSWp_UaiqT2yGCZiKKP4E0mptTM14TD9dYpiAKajcjhIKFIeDCMyyaKdusdd6V6C7On98D9uEW9vqW6VDn-EygIv1ZTQInJ3P0ec_my-x1L2G6CReM7p5uDyfI0xIYzr_Lv8cTNRJIna5HOXEPq04fSf-BQZDX3DiL-wcdO-HCy4qL_udevp9hUla7Xam1xhnU_7pttu7ygHnSrtjJMyzNymNSsb1mNgz3qio-_d_MW2xyhoMtQzig7TVnB9CIYpvMRg-HSwMLwkxGDHxwBZIH_EaYxOcmZIA6QoJ6gljRIyVB_4AbAiJuzMEZpRbcdtg0kgpY632Rs8jloHkf_RS3AY3ZaatOl6x1JbI9JgFpprow2L5rwnvMOxU3i3sV_jwKtEccxcS2oVxYOFBIAei2kw6Bk3Oz-sCmCwYMdy23F95WYo_1Ma16-i-I3JQpkHUvlmwnDOOc-0Qz245SxohM9Fqg1bmBpEMvSoYi93gnBexthUV89K7KJT_ja1ed_ZZsoChMS3U3E1nfge9SY6uRs4JRKdDT0kfzu3Wb-fXQJtdNcnvqN_fT29a59SiQv9vm8J2iw6pVw3E_9msEHCFeEc-d1A01J-yllqHU8pjljrK11dHDSqyUfHCEsd0vsZuxJjN3Q042SwfSduGL8puxz3hNed8d2PnkLr-6i0LLrvYU5mnddlsZt-xqq22RLxN08NauBdyOSzykTRUUx8ClqyzuAwVY9RjOybagIiJpnlEbieYXbSP2ruu0F6sytArC0ZSEMl5jLNAGq0I9FjrcS7Mqv_E76s2qOSEUPcHnw8hHd7gcryjEgjxntUtAB53JhgEJNkQifFABXg01mu8k-rPIpVtGIOhqG_rEIePbKALk25aX4uMoGHHcsAAGfwgDGM_LsHl35zpGtjDB3yON3toB2UpMShKYdJH9FBijA-BhUEEutJjqxxMcbouGTcD9gl7PxYCdEq4oPAo74kND4WquixiRyKjiOsSEADNbzyISl40USMXNskUfokZHIDwqu224SjjH7lcu6nz0vz85ku1cuOMXNVv4GHbX8-P9dii65Iwn7F_QVb_-i50BTVpYvDUt1F4AUbvbu0mIypyTyX4Emp5XaLFtRvukilAEn6EhfT4oZPveKon3DnnimerdDm-ebarvO04LjnAF5NBNomocCb4-Ep-6uWdljxJDrVYNFo-GqWvUYRhlbVg3aTwOGs0v_6Mah4iKhLA7i4UOb6doF5D6DLnjr3Fz7_XOcqebmPb7ExeOdcBvMWRuDHKfmPLlcp__rDOCLZ2KXvI6HBnWZ3NVbMTYn512PsXGaJ0N64UVCiW6piiTPKBdpfPEPgnOM70xVdfMpax9ZtihXvxPjxZ1dOVYhIsIv9_b0kpcUtbV13bReKks_1mVp1LOyHN75DyUvsq0CRgT6-NNnYod0tLFsd8uYaXtGF44qvwj6WlGDW8g1lcB6UroSAcSnfoCu5LWDKOdiWfnR2QZD0mrNv0YAGr63BFo7hUFX2f3a9XX60aDL0IumkcJ5FLCYMjkRUkL7AglNw707SdAKmE1mnEz2TfnYpvEY9NzYgpoOL_sXissf-HS41JYppcuCusdomUiUMrQXPSbXOZ2HNRJrvrP0DGix56bmsL315njkFZ3SxUcczaCbPUzT8YBD475GWnaPDwDiVUUf7NnK7flNVshviMZK_8JMOH0EvDnzIm_hfeTTO3SxQxshFb7XqmYVolXs73HdaWXG44jrK__F6SSzr3h-ZzChBEaz8cnC037Jr2P0PoOPExaZIkJgTXRMtDGT0hrm6X8__xQZtWRVeeG14p4c3hIaBSbiofOjZdLgfBKw4Vz2etH3QNC8DupqGDQ2HoGivbsPvpgF2CpDSdlq1oOJMW3NFvUxizVN6mju8edXKCoj8RCmEhzpvBAqB1_Ir6gPPr7p_z3r1_QN0GNW9rKqSiBfFBmc2y3fuWxYrsL-vrJDwfTOGv9cEwboOeUArG501iObfaKKEZBtZzJIj-WLBGgsSsjrbkvqUDnb763y07ym7pZhKQaYmx2INKwPu0sdBPJYpE8ChuQGbpK9iclhx7bXpejvbRltyxHPdWAJlLFgbb4xvcxM6igseZ1wNqxo_DaNjyxTcVsIVa8BkKVj6jnHsMciqkbbQ78uLQBaUTVwWak6blr4oFbH79fWOPzN4qxp9AakhQRJR3EJfovw1R6lO9WOa38wKljvVkd_Zah_0RPRNZpuKrxylEFgAVUKh3JdUwD6zREvLw39ahj3b7LbajYdvFgLeMuRhkkLrY89LS54JHrovpgNvb_NBWGT8F2MNzRF7Ty-UJFeyfHdKRl0O9gOog189Ogqg_VuWesWftomkaj-YHqsYw4SeS7SBSg4zu6C7P-CirM0LPMvGK6AaGfmsL2Q7Vrsph56UD2FvRi8VAPbTivbcN3rJeotZ57S3sETFEXp_o9SwvlNRgpxHyJvadlad9KVAVhBihir-elrsfZTLomwsX55Ruj5GjGZsAr6sLmVLI9zxqgA9b_fxSiBg08IjVE4wn7_0KtFA8eafqDeXJREFQTooD6-GucrNeXN6yzZamJiyyBWx_tui2W6UCs554VW8Z3n2JtJNZDAazEQlB8JhfyUeYIbOsYWfOfx0hHMxYbaD30lp_q4r9KBYqYviX6ign8Bk9mllqeXV4Af30TSzcj5mFuumdL8ZedErMvyKBlU36p6NyyZs2c5phtTNLbPy-WgdblyvdDBFaxT5BLyJjZxzFVy5TlRLgOV7mBBxVY9ScP2z638J4hFqA6_-EuPBjPw4jOLOAmzHly85hyIC0zA8pSwrPaFqg3GYAoph-A25RjPTPtykbUrC2OgXM9GtJAQTrT4RTvYPLKSo3nINwoAp8845e0BbNUfp6-odCQaHVtm35rFezOBdqe0tsZlrCnA6m-fBs-3sOJObjhW-JrteHofmxQTDpxF5PZLYXTffBajbPeB_gbCsvd0VZ5KiXlCCLPyrE7VnTnbF023gzob8xGfYp1E4tv3OvVXRHaE_OCQxA4SsPDj5UVMzQ-4_PK5KziF79qHLot1uUbohSgbJLtie6Qj5hnjQWw-pnkVDVFIhHw3qmu8et4maFauZSEL2jNvwuzSoZAm8dsN6raQniypE_5SPnn0D1QlYBwNy3jeeVJ5G0oruAjPRriGIUGlsEeRPn1cEQfouCzxF5frw-w5SkCtpUFqiy9ZNKsjtGkQBDPq8P1iOlfoYGfTyfxYwJOsb3aQoqZoynITY0kDSY1b1HrxTpJY0YTpVLLBR_nvpsMjezEXeQVuCmJDBbRvy36x2D3JH-dIu0QHTGlIR1FuBJsaPb2qZLf7wEcPZ8ELO2yGpn27JooeNEsDM_vf8mIvd3D-W4CyKs77J32hH8Dx_il70E-mybyBLyO8sWRRnVioHTcs55STTTUpFPYHDQPlLpyetMx9Vz19Sl0ZoS1jXDxJq3yua3t19d0upPETpE7zTUnTsimdjaMXWDpDdALFObO_85zLXbpRcyM8705J3JPcHbez1IiPfwAk5Tcq-zS2Ejed5wXU23_xt36BPTJBsdKkXhQToN9SrxK7ac586y4Lzncj44SSFReUSw1pf7G3z67dudC6T84lL6vcYYbGLGgvKZHlvnZ2MHkPRoYFImYZ03GWYQ_xC9Fk2DRm4VqB3QqJBBslHyIne3xeGp3aq-_dzL3CepaCRXLcsFl1Qh1e_riaVf2zrkq3oXEUKAWErD1muairiR7jT-2MFesSciy4IFLlsBTj2hsPYhPmRR6SCyCt-E3-gWXTSUyRFgj2G2WtceT44DGz37aCT5_BOsPXlOBeolqTWCFgrKbwX1tFSa1nYrO-Xx8hu73XuczilXdN-c7Lb8WxTk7QvWE37tEM3O_y-IFurMob4xSo9AhXTvS2nQ9PmWiedq8jLjFr2SNjA6iPE7lTxx69uO4S-jwW_WAN7r56Z062EiwkOwjtex2ykW2SbpkmyY6tX5wlnMZenJo22a52jIrbMABVbRk_xfAgDXMhPtctX8dgobDM2G273LDdCet0Rzcs8QvEN0e1zfcRAGawF2_EZ5dDdd2rpVk3vep_NUOY03qONZcHFfMzl2O39D9QaEcdS7Xt-BUTuMJlZYAZG2K1tfSTlyvw89ceDnEqvxrI9PfhQM9uoZ5FrBY2x9aN0-U4O2YKr_nlL6wyGgbExmzFBmuRcRJvLnii6Maet-IEt4B5F5Say6biJvPWIXT3JJkbq39lQDMVCjWiXllSVv90tmOZoeQX4W59q5UYMqvZp3-l9KXgS6szd95e904GU1X3xFd6NNiU_Na83t1gMJ-c2x6UIp9CF2p77MjesybVelV5VLxYfk2C8gFEduJjH9WsF0bMfa-gYtdaRfycpNf_RL9l76jckm4p18qrbpm0d1pdhRqVhJmLxh5I-x4Do3QTv2QHt5M6v8849Y5h-V-wm_SK-4snPKL19ZaB-1Q_1flta8UVYfS_kCqrks1zdnbZf6KBz_rXnFe2NmNbIs2WY9JxmS9uvsSda5baOxUnI5yUXD4OuiphSg-sC4-UlWcFa8icJuf4cP9XwGlnIcBz4w-9Ecgiv4eyRpDyDTALkkAbuaiynwpKV44B0JtuyzaCi0zVFzm68-1mVFOHjEkfC2Vtp2DlpLdNW0pHof5_LlaUk--XdUM88XchSK-dcrck1kq1AE3HxMVcLNm9QKoga3f8EcgfQiD2B4230nutEcUP2dRXaC9rfTHC7cuzQmtMb1_ktLutM8f7U0bce4SJyenxYCaqduxhzwylJBo5e2kDWTJqK0NUUF47yYDD9ybroyWvfY_cjuUNbqMxVEerz5ZtSO9sqBE6TeHWPDsSJVjr73vQb5YEUWSba0u_irqBls_sgha7e3MP9NXp6SSO1xf9uNgct7CJVgNvYgQDZNdQgpDx-iTBDLeCkhapB3XNJFMpdzdrdJqxu6-oW8qpKrP6NlGuNSl7G3LwIfhFTV9auFOGRkDCzUC4RJ8e8Do-2DNJCBY_fbclxnLD3y2SZLI5bfH3yHQhN_Ayfn0uePVA2m-pbK6QafohqtdngFn63NrS19QIfw29py2LTP4iVEspzIfDhwJnSgIdk_jS9FbMbDvjLTrrPmvUf5If3cCTeHgH-lZmlruIqhhASgNpjLppHrjwg-1S0KxuoWJxSpdHvQ36G2_hFM8z5jrbow4h9X6QDq8wNV-cT6GS5zJGaQRO61nHOg-0XpRUHUYpxukIHritIjTIqiF_VgSq0X7COodZeM1h54rb37FS7i-v337r5slBUl9x8D7EXraGuu6xPuDG6fMmefYiMfNmwY07l8gR6fWdSLj_vTdPlxIMaAXYdjppaNVqPyYa2DvV4gu_Mk9rhzbB0rw3sx5a9SNOPEHvXinc-5U2RSMrivo8OM7FcM3jZw__gkgCsRgCqy8PXrkwg5wmPJU9vQRhf_VPvArRPfPjhTzJsu-9prZILnnMkvBQx8K-4yD8-Co9jCbhBXSTjyPDeGF59Yr_Qum5yxfBVcrF2nquTvi4FzRd_ehXbIeSAT3Ue9IzBt96xHl4giVTW_yrda_1efCAURDc",
"iv": "ppQiLheseVBGRfdsXVxnhQzQF1kavfZF",
"protected": "eyJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIiwiYWxnIjoiRUNESC1FUytBMjU2S1ciLCJlbmMiOiJYQzIwUCIsImFwdiI6IkJCLW9GVjBKemZoQWFFNjlQS3VaRmQ4dDhWZ19hQzhfTlpUNTM3NkxCOFEiLCJlcGsiOnsiY3J2IjoiWDI1NTE5Iiwia3R5IjoiT0tQIiwieCI6IkdmYUhrbHFUdWk3VUhSTXJIYms2Y0llNjFkbDhkd2tqQUZCcTI2aGMzUjgifX0",
"recipients": [
{
"encrypted_key": "QlQcNWkAUKbmOhDagbX5Vo9w1BzowrwfIrDtPxkpFXjtzwyq0tYiGA",
"header": {
"kid": "did:peer:2.Vz6MkhMTSwCfytUNmrEQ4We5i6B2ywM8hAcHvRDD293QGrqSS.Ez6LSm3LPosAtT2qUtFNU9Y2y9P9wQUfJjGgs98uchVJtZjfS.SeyJpZCI6IiNkaWRjb21tIiwidCI6ImRtIiwicyI6Imh0dHBzOi8vZGV2LW9wZW4tbWVzc2FnZXMtYXBpLWx0aDRnb3dkeXEtZXcuYS5ydW4uYXBwL21lc3NhZ2VzIiwiYSI6WyJkaWRjb21tL3YyIl19#6LSm3LPo"
}
}
],
"tag": "Ba3PnsIur7cgeLxSSH_CNw"
}
}
}
]
}
Why
Because its not usable to actually consume the message itself that was sent.
The message below was the original message going through the encrypt message function.
And I want to see that after I unpack with the right secrets.
What am i missing?
{
"id": "1234567890",
"typ": "application/didcomm-plain+json",
"type": "http://example.com/protocols/lets_do_lunch/1.0/proposal",
"body": {
"messagespecificattribute": "and its value"
},
"from": "did:peer:2.Vz6MkkkhBpeffjdyRCpyv1h17ZH4fJ6amEu2cujuaBcf2bmor.Ez6LScPkBqUGgUnFdxEPviCBAhdeKrhrHidLCyrcjq6SdvSj6.SeyJpZCI6IiNkaWRjb21tIiwidCI6ImRtIiwicyI6Imh0dHBzOi8vZGV2LW9wZW4tbWVzc2FnZXMtYXBpLWx0aDRnb3dkeXEtZXcuYS5ydW4uYXBwL21lc3NhZ2VzIiwiYSI6WyJkaWRjb21tL3YyIl19",
"to": [
"did:peer:2.Vz6MkhMTSwCfytUNmrEQ4We5i6B2ywM8hAcHvRDD293QGrqSS.Ez6LSm3LPosAtT2qUtFNU9Y2y9P9wQUfJjGgs98uchVJtZjfS.SeyJpZCI6IiNkaWRjb21tIiwidCI6ImRtIiwicyI6Imh0dHBzOi8vZGV2LW9wZW4tbWVzc2FnZXMtYXBpLWx0aDRnb3dkeXEtZXcuYS5ydW4uYXBwL21lc3NhZ2VzIiwiYSI6WyJkaWRjb21tL3YyIl19"
],
"created_time": 1516269022,
"expires_time": 1516385931
}
Success Criteria
encrypt and pack a message, and un pack and decrypt the same message with the same library
I believe what you are decrypting and seeing here is the "forward" message for the routing protocol. Your encryption is wrapping the message with 2 layers and you are unwrapping 1 layer and expecting to see the inner envelope. The "next" property in the body tells you to now send that message to that did
@brianorwhatever thanks for your suggestion, but im just following the demos. But based on what you say do you suggest that i send the unpacked message through the unpack again? Ref the attached image. This is SICPAs suggestion of what is common case: https://github.com/sicpa-dlab/didcomm-rust/blob/main/wasm/README.md#1-build-an-encrypted-didcomm-message-for-the-given-recipient. Very similar
hmm yeah, and looking closer your did:peer doesn't have routingKeys in it as I had assumed. Not sure what else to suggest.. will need feedback from sicpa folks
@brianorwhatever yeah I was hoping I could avoid routing keys, as I dont see the need as of now? I will push hardman on discord and see if there is anything he can push
The problem at hand is that I expect to be able to read decrypted data when I unpack
Adding code so its easier to copy paste. But its really just the example code.
const to = "did:peer:2.Vz6MkhMTSwCfytUNmrEQ4We5i6B2ywM8hAcHvRDD293QGrqSS.Ez6LSm3LPosAtT2qUtFNU9Y2y9P9wQUfJjGgs98uchVJtZjfS.SeyJpZCI6IiNkaWRjb21tIiwidCI6ImRtIiwicyI6Imh0dHBzOi8vZGV2LW9wZW4tbWVzc2FnZXMtYXBpLWx0aDRnb3dkeXEtZXcuYS5ydW4uYXBwL21lc3NhZ2VzIiwiYSI6WyJkaWRjb21tL3YyIl19"
const from = "did:peer:2.Vz6MkkkhBpeffjdyRCpyv1h17ZH4fJ6amEu2cujuaBcf2bmor.Ez6LScPkBqUGgUnFdxEPviCBAhdeKrhrHidLCyrcjq6SdvSj6.SeyJpZCI6IiNkaWRjb21tIiwidCI6ImRtIiwicyI6Imh0dHBzOi8vZGV2LW9wZW4tbWVzc2FnZXMtYXBpLWx0aDRnb3dkeXEtZXcuYS5ydW4uYXBwL21lc3NhZ2VzIiwiYSI6WyJkaWRjb21tL3YyIl19"
const msg = new Message({
id: "1234567890",
typ: "application/didcomm-plain+json",
type: "http://example.com/protocols/lets_do_lunch/1.0/proposal",
from: from,
to: [to],
created_time: 1516269022,
expires_time: 1516385931,
body: { messagespecificattribute: "and its value" },
});
// This resolver just resolves as expected and modifys data objects to fit the code. Lots of transformations
const resolver = new DiwalaDIDResolver();
// This resolver just calls the nessecary methods and NRIS reads out the key values nessecary to do this secret action. It succeeds so I think it is not relevant.
const secrets_resolver = new DiwalaSecretsResolver(nris);
try {
const [encryptedMsg, encryptMetadata] = await msg.pack_encrypted(to,from,from,resolver, secrets_resolver, {})
console.log("Metadata of message", encryptMetadata)
console.log(`Sending message: ${encryptedMsg}`)
const [unpackedMsg, unpackMetadata] = await Message.unpack(
encryptedMsg,
resolver,
secrets_resolver,
{}
);
console.log("Reveived message is\n", JSON.stringify(unpackedMsg.as_value()));
console.log("Reveived message unpack metadata is\n", unpackMetadata);
} catch (error) {
console.log(error)
throw new Error('faild encryption and decryption')
}
Ok, so this is awkward. Its very easily solvable with adding an unpack option of
{unwrap_re_wrapping_forward: true}
This is default false according to their inline comments.
Adding this, I got the original plain text message and Im able to continue onwards.
It would be great with some clearer documentation, or tests around this so it is clear to how this works
I think I have discovered that this only happens on signed messages. I haven't yet been able to reproduce though as I can't successfully create a signed message. It throws Unsupported signature alg which looks to be coming from here
@brianorwhatever i tried not to sign it, leaving the sign option to null. And it did not make a difference.
Your unsupported alg, i traversed as well. I dont remember what the solution was. I jsut know that I generate did:peer methods with the following logic:
Meaning im able to use the 2020 keys and sign and create. As you mention in #95.
But when it comes to unsupported alg, I needed to have a key that also had keyAgreement. Both sides of the message senders had to have key agreements og the right keytype.
Just important transformation for secrets to work
getSecretFormat(type: string) {
if(type='X25519KeyAgreementKey2020') return 'Multibase'
if(type='Ed25519VerificationKey2020') return 'Multibase'
if(type='JsonWebKey2020') return 'JWK'
throw new Error('Unsupported secret format');
}
getSecretValue(secret, format) {
const valueAttribute = formatMap[format]
const secretValue = secret[valueAttribute]
if(secretValue) return secretValue
throw new Error('Unsupported secret value')
}
findAndTransformSecret(secrets:DecryptedKMSObject, id: string, did: string) {
const thisSecret = secrets.keys.find(k=>k.keyId===`#${id}`)
const type = thisSecret.decrypted.type
const format = this.getSecretFormat(type)
const value = this.getSecretValue(thisSecret.decrypted, format)
const obj = {
id: `${did}#${id}`,
type: type,
secret_material: {
format,
value
}
}
return obj
}