3 ms·

There are many issues with this article. First of all the fact that the hashes are truncated does not matter, collision attacks are not an issue in this case, p

There are many issues with this article. First of all the fact that the hashes are truncated does not matter, collision attacks are not an issue in this case, preimage attacks are. Secondly, in recent linux kernel versions /dev/random is basically the same as urandom but better as it blocks at boot until enough entropy has been collected, although i can see this being an issue in older android devices. There is also a lot of nip-picking which is sadly common in soatok articles, but I will agree with the conclusion, there are better meesagers out there.

some_furry 5y ago
> First of all the fact that the hashes are truncated does not matter, collision attacks are not an issue in this case, preimage attacks are. Incorrect. Preimage resistance would matter if you needed to produce the plaintext, not just collide a fingerprint. If you're trying to swap out public keys while deceiving the user into thinking it's the same, a collision suffices. > Secondly, in recent linux kernel versions /dev/random is basically the same as urandom but better as it blocks at boot until enough entropy has been collected, although i can see this being an issue in older android devices. Correct, but the Android versions that have the SecureRandom bug are also overwhelmingly likely to have such an old version of Linux. :)
- ttybird 5y ago
  You are correct in a very technical sense. However this is only applicable if your friend is the one that is attacking... themselves. All that a collision attack can do in this case is to get you to think that the public key that your friend generated is the same as another key that they generated. This is really a non-issue. The only thing that matters here is 2nd preimage resistance, which still has 128 bits of security. As for /dev/random, I only mentioned it because your advice is outdated. Some other comments: yes, if you do not provide a password then your key won't be encrypted and anyone in possesion of your phone will be able to extract it. Seems normal to me. As for pbkdf/sha, meh, nothing can replace a good password, but sure, argon2 would be better but this seems like an extremely minor issue, kinda like complaining about how signal uses aes128 instead of 256.
  - some_furry 5y ago
    > However this is only applicable if your friend is the one that is attacking... themselves. > The only thing that matters here is 2nd preimage resistance, which still has 128 bits of security. Nope. Let's assume I have root on the Threema servers and have fully pwned their infrastructure, and want to substitute someone's public key to attack the app. (Remember: The minimum threat model for end-to-end encryption is that the server is evil.) Alice pushes (3ma_id, pk) to the server, and chats with Bob legitimately. Bob suggests Alice talk to his drug dealer, Dave. When Alice goes to talk to Dave, instead of (3ma_id, pk) the compromised server sends Dave (3ma_id, pk') where (SHA256-128(pk) == SHA256-128(pk')) and the sk that corresponds to pk' is known to the attacker. In this situation, a visual inspection of the fingerprint will reveal nothing amiss. The QR code will still validate. This attack can be leveraged in both directions to make Man-in-the-Middle possible, and the fingerprint mechanism will fail. The full set of keys and substitutions here looks like this: Alice -> Bob: (A_id, A_pk) Alice -> Dave: (A_id, M_pk1) Bob -> Alice: (B_id, B_pk) Bob -> Dave: (B_id, D_pk) Dave -> Bob: (D_id, D_pk) Dave -> Alice: (D_id, M_pk2) SHA256-128(A_pk) == SHA256-128(M_pk1), A_pk != M_pk1 SHA256-128(D_pk) == SHA256-128(M_pk2), D_pk != M_pk2 Now Alice's communications with Dave are tapped by a MitM (the attacker) and the fingerprint fails to stop it. And you only need a collision of a partial SHA-256 hash to pull the attack off. You don't need a preimage attack.
    - ttybird 5y ago
      instead of (3ma_id, pk) the compromised server sends Dave (3ma_id, pk') where (SHA256-128(pk) == SHA256-128(pk')) I can't see how the server can create pk' just with a collision attack in this case if pk is not controlled by them. Looks to me like they need a 2nd preimage attack. But maybe I am just stupid.
      - some_furry 5y ago
        I updated the article to describe it: https://soatok.blog/2021/11/05/threema-three-strikes-youre-out/#impact-of-the-peer-fingerprint-bypass https://soatok.blog/2021/11/05/threema-three-strikes-youre-o... The attacker knows (pk, SHA256-128(pk)). They can generate another (sk', pk') where SHA256-128(pk') == SHA256-128(pk), but pk' != pk. This will cost an average of 2^64 key generations. Expensive, but feasible. If you're law enforcement trying to catch international arms/drugs traffickers, and your suspects are using Threema, it's a valid attack strategy.

some_furry 5y ago

> First of all the fact that the hashes are truncated does not matter, collision attacks are not an issue in this case, preimage attacks are. Incorrect. Preimage resistance would matter if you needed to produce the plaintext, not just collide a fingerprint. If you're trying to swap out public keys while deceiving the user into thinking it's the same, a collision suffices. > Secondly, in recent linux kernel versions /dev/random is basically the same as urandom but better as it blocks at boot until enough entropy has been collected, although i can see this being an issue in older android devices. Correct, but the Android versions that have the SecureRandom bug are also overwhelmingly likely to have such an old version of Linux. :)

ttybird 5y ago
You are correct in a very technical sense. However this is only applicable if your friend is the one that is attacking... themselves. All that a collision attack can do in this case is to get you to think that the public key that your friend generated is the same as another key that they generated. This is really a non-issue. The only thing that matters here is 2nd preimage resistance, which still has 128 bits of security. As for /dev/random, I only mentioned it because your advice is outdated. Some other comments: yes, if you do not provide a password then your key won't be encrypted and anyone in possesion of your phone will be able to extract it. Seems normal to me. As for pbkdf/sha, meh, nothing can replace a good password, but sure, argon2 would be better but this seems like an extremely minor issue, kinda like complaining about how signal uses aes128 instead of 256.
- some_furry 5y ago
  > However this is only applicable if your friend is the one that is attacking... themselves. > The only thing that matters here is 2nd preimage resistance, which still has 128 bits of security. Nope. Let's assume I have root on the Threema servers and have fully pwned their infrastructure, and want to substitute someone's public key to attack the app. (Remember: The minimum threat model for end-to-end encryption is that the server is evil.) Alice pushes (3ma_id, pk) to the server, and chats with Bob legitimately. Bob suggests Alice talk to his drug dealer, Dave. When Alice goes to talk to Dave, instead of (3ma_id, pk) the compromised server sends Dave (3ma_id, pk') where (SHA256-128(pk) == SHA256-128(pk')) and the sk that corresponds to pk' is known to the attacker. In this situation, a visual inspection of the fingerprint will reveal nothing amiss. The QR code will still validate. This attack can be leveraged in both directions to make Man-in-the-Middle possible, and the fingerprint mechanism will fail. The full set of keys and substitutions here looks like this: Alice -> Bob: (A_id, A_pk) Alice -> Dave: (A_id, M_pk1) Bob -> Alice: (B_id, B_pk) Bob -> Dave: (B_id, D_pk) Dave -> Bob: (D_id, D_pk) Dave -> Alice: (D_id, M_pk2) SHA256-128(A_pk) == SHA256-128(M_pk1), A_pk != M_pk1 SHA256-128(D_pk) == SHA256-128(M_pk2), D_pk != M_pk2 Now Alice's communications with Dave are tapped by a MitM (the attacker) and the fingerprint fails to stop it. And you only need a collision of a partial SHA-256 hash to pull the attack off. You don't need a preimage attack.
  - ttybird 5y ago
    instead of (3ma_id, pk) the compromised server sends Dave (3ma_id, pk') where (SHA256-128(pk) == SHA256-128(pk')) I can't see how the server can create pk' just with a collision attack in this case if pk is not controlled by them. Looks to me like they need a 2nd preimage attack. But maybe I am just stupid.
    - some_furry 5y ago
      I updated the article to describe it: https://soatok.blog/2021/11/05/threema-three-strikes-youre-out/#impact-of-the-peer-fingerprint-bypass https://soatok.blog/2021/11/05/threema-three-strikes-youre-o... The attacker knows (pk, SHA256-128(pk)). They can generate another (sk', pk') where SHA256-128(pk') == SHA256-128(pk), but pk' != pk. This will cost an average of 2^64 key generations. Expensive, but feasible. If you're law enforcement trying to catch international arms/drugs traffickers, and your suspects are using Threema, it's a valid attack strategy.