Skip to content

Bad MAC when receiving malformed PreKeyMessage #743

Description

@chrisballinger

I finally was able to see this happening locally, but I really have no idea how to fix it yet.

2017-04-22 20:58:03.413 ChatSecure[94540:3354743] SignalProtocol (2): Bad MAC
2017-04-22 20:58:35.536 ChatSecure[94540:3354743] SignalProtocol (1): Message mac not verified
2017-04-22 20:58:55.878 ChatSecure[94540:3354743] SignalProtocol (1): No valid sessions

These are spit out by libsignal-protocol-c when receiving bad prekey messages. Possibly this is related to the bundle corruption issue?

Activity

  1. added this to the 4.1 milestone on Apr 23, 2017
  2. chrisballinger commented on Apr 23, 2017

    @chrisballinger
    MemberAuthor

    I have an idea that this is caused by having multiple local accounts that share buddies w/ the same JID. The SignalAddress and storage stuff is keyed by JID, so sessions could get messed up. We should probably use the uniqueId property of the buddy for the address name instead.

  3. afriedmanGlacier commented on Apr 24, 2017

    @afriedmanGlacier
    Contributor

    I am seeing this every time, even if I remove users, delete the app, re-add users with a different JID and start over. In other words, I don't have multiple local accounts.

  4. afriedmanGlacier commented on Apr 24, 2017

    @afriedmanGlacier
    Contributor

    @chrisballinger did you happen to look at the change in signalapp/libsignal-protocol-c#52? That code change occurs in the method that now gives the error.

    In looking at what they did, it seems to be an innocuous change, but this wasn't happening in the last version of ChatSecure before the updated libsignal-protocol-c library was used. I tried to build a latest version of ChatSecure with the older libsignal, but had trouble doing so (I think because of SignalProtocol-ObjC) and didn't have a lot of time to mess with it.

  5. chrisballinger commented on Apr 24, 2017

    @chrisballinger
    MemberAuthor

    I can't really see how this diff could result in a change in behavior, but it does seem to have changed after updating the library.

  6. afriedmanGlacier commented on Apr 24, 2017

    @afriedmanGlacier
    Contributor

    Agreed.

  7. chrisballinger commented on Apr 25, 2017

    @chrisballinger
    MemberAuthor

    Tracking upstream here: signalapp/libsignal-protocol-c#65

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions