-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
unpackedmessage.as_value() does not provide decrypted version of the message #94
Comments
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. |
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.
|
Ok, so this is awkward. Its very easily solvable with adding an unpack option of
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 |
@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
|
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()
messageWhy
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?
Success Criteria
encrypt and pack a message, and un pack and decrypt the same message with the same library
The text was updated successfully, but these errors were encountered: