1. 14

  2. 3

    That signal doesn’t warn the user about relying on a prekey that’s been used by other clients is less than ideal, in my opinion.

    What would a message warning about this say, and what would the user do about it? Other than call whichever relative told them to use Signal and ask them what it means, to which the response would likely be “it doesn’t really matter, don’t worry about it”.

    Are there any possible attacks against this? I guess sending lots of messages to the same user to exhaust the prekeys to force messages to use the last-resort key, although if you’re in a position to compromise the corresponding private key anyway I’m not sure that would help any (and it would make a lot of noise, potentially tipping off the target that something is up).

    Leaking the password is then enough to allow someone to both send messages and upload keys on behalf of a user.

    The password alone isn’t enough to do this silently, right? Anyone on the other end would have Signal complain that there is a key mismatch (I hope).

    Deniability is much shaker. […] The TextSecure server authenticates and forwards messages, and may log them.

    Couldn’t a forged message be made to appear it was sent/received at the same time as a real message? That way the server knows a message was relayed at a specific time and the forged message looks like it was received at that same time, therefore you can claim the message you sent said something different (while you’re being hit with a $5 wrench).

    Also, I found responses from Moxie and Trevor Perrin about the Unknown Key Share Attack (while searching for a copy of the How Secure Is TextSecure Paper, it’s here (pdf)).