jdev - 2024-02-06


  1. debacle hates forward secrecy passionately

  2. blue

    Hello everyone! May I ask for an account for wiki.xmpp.org ?

  3. Guus

    Blue's wiki account has now been created.

  4. blue

    Thank you, got an email

  5. moparisthebest

    > debacle hates forward secrecy passionately debacle: why?

  6. jonas’

    because it's a pain when you lose your device

  7. MattJ

    Because most people don't need or want the properties it has

  8. moparisthebest

    > because it's a pain when you lose your device I'm under the impression most people are fine with this

  9. moparisthebest

    For the rest: backups

  10. jonas’

    bubbles

  11. jonas’

    backups are hard

  12. moparisthebest

    So nothing to do with forward secrecy

  13. jonas’

    it does

  14. singpolyma

    >> because it's a pain when you lose your device > I'm under the impression most people are fine with this I have met zero customers who are ok with this

  15. MattJ

    Yep, the expectation from pretty much everyone except those that got swayed by Signal's marketing is that your account and messages are recoverable if you lose your device

  16. singpolyma

    Techies who value forward secrecy and understand the trade off are ok with this. To everyone else it looks broken

  17. moparisthebest

    The people that I know what always lose/break/destroy their phones are using SMS and lose everything every time anyway

  18. moparisthebest

    It's not a trade-off for techies, they have backups

  19. MattJ

    Don't Google/Apple back those up these days? (personally, I decline that)

  20. jonas’

    I don't have backups of my phone.

  21. jonas’

    I wouldn't even know how to

  22. singpolyma

    My backup of my messages is the one on my server, heh

  23. moparisthebest

    jonas’: I'd wager you have other devices with your chat history though

  24. jonas’

    moparisthebest, I do, yeah. for most. not for (all of my) snikket history

  25. moparisthebest

    How does WhatsApp work when you lose your phone?

  26. singpolyma

    I'm sure they restore from server like other Facebook products

  27. moparisthebest

    Anyway the point I was planning to make is forward secrecy does not prevent history from being sync'd between your devices, we just haven't implemented it yet

  28. jonas’

    so it effectively *does* prevent it

  29. singpolyma

    Sure, if you have multiple devices

  30. jonas’

    the magical secure history sync hasn't manifested itself in the half decade this has been talked about

  31. jonas’

    and that, yeah

  32. singpolyma

    I'm not against forward secrecy for people who want that, per se, but I've always avoided it for myself

  33. moparisthebest

    It does prevent you from recovering history if you lose all devices and have no backups, but that doesn't apply to techies (who have multiple devices and usually backups) and people who have neither are used to this and don't care

  34. singpolyma

    I get support inquiries all the time from customers who do care and are sad

  35. moparisthebest

    > the magical secure history sync hasn't manifested itself in the half decade this has been talked about Right, which leads me to believe no one actually wants it bad enough yet

  36. jonas’

    or maybe that it's a hard problem?

  37. moparisthebest

    singpolyma: your customers are highly skewed towards techies though

  38. MattJ

    > How does WhatsApp work when you lose your phone? WhatsApp does a daily backup to Google Drive (and I assume on iOS it uses iCloud). If you don't have a backup, you effectively create a new account, and in group chats at least it can request history and the other participants are able to re-encrypt messages to the new account.

  39. singpolyma

    moparisthebest: true. And even they run into dhis issue

  40. singpolyma

    MattJ: interesting

  41. singpolyma

    Backup encrypted or unencrypted?

  42. debacle

    moparisthebest jonas’ Fortunately, so far, I never lost a device, but sometimes I use a new client anyway. And then I can't read my messages. That's why I don't use OMEMO most of the time. However, I'ld prefer e.g. OX or whatever allows me to read my old messages, when I start with a new client.

  43. singpolyma

    debacle: yeah, ox also gives you encryption at rest, which is nice

  44. MattJ

    singpolyma, good question, I *think* unencrypted, as I don't think any password or recovery key is involved, so I think it just relies on the security of your Google/Apple account.

  45. singpolyma

    If anyone steals my messages it'll be y stealing my phone

  46. MattJ

    Which completely undoes the forward secrecy, but they still get to keep "supports E2EE via the Signal protocol" in their marketing

  47. moparisthebest

    debacle: yes and the "new client" case is just a gap in XMPP and nothing to do with forward secrecy, good

  48. jonas’

    it doesn't hurt at all when you don't have forward secrecy

  49. jonas’

    so it does have to do with forward secrey, stop lying yourself into your pocket (as we say in german)

  50. MSavoritias (fae,ve)

    does omemo/mls give anything else than forward secrecy?

  51. singpolyma

    MSavoritias (fae,ve): vs ox? No

  52. moparisthebest

    > or maybe that it's a hard problem? jonas’: what's hard? We have everything that's needed, all major clients have the capability to establish p20 webrtc data streams between themselves and just do mam over it?

  53. MattJ

    MSavoritias (fae,ve), I don't think so, but now I'm curious what (if anything) MLS has to solve this

  54. debacle

    moparisthebest, I'm not an expert on that matter, but doesn't forward secrecy prevent a new client decrypting my MAM messages?

  55. MSavoritias (fae,ve)

    > MSavoritias (fae,ve): vs ox? No does actually ox specify any cyphers?

  56. MSavoritias (fae,ve)

    from what i know gnupg has horrible cyphers by default for keys

  57. singpolyma

    debacle: moparisthebest is saying one could build a protocol to fetch messages from your old client instead, to paper over this

  58. MSavoritias (fae,ve)

    which tbh is the main reason i was thinking about mls/omemo

  59. MSavoritias (fae,ve)

    forward secrecy is interesting but if you want to have history syncing there is no point anyway

  60. MSavoritias (fae,ve)

    to have it that is

  61. singpolyma

    MSavoritias (fae,ve): which ciphers do you want? It's all going to be aes except the pubkey part

  62. singpolyma

    ECC is an option, probably what I would use for something new

  63. debacle

    singpolyma OK, got it. But then my old client needs to be online, which might be the case or not, right?

  64. singpolyma

    debacle: correct

  65. moparisthebest

    > forward secrecy is interesting but if you want to have history syncing there is no point anyway nah still a major advantage that you can't get anything to decrypt the server archive

  66. MattJ

    Why is that useful if you support any kind of history sync?

  67. MSavoritias (fae,ve)

    singpolyma, i wasnt thinking anything in particular. probably just get whatever sequia considers most secure

  68. MSavoritias (fae,ve)

    gnupg is a dumpster fire in that

  69. MSavoritias (fae,ve)

    i will look into it then

  70. MSavoritias (fae,ve)

    because i imagine its also vastly simpler to write an ox implementation than mls

  71. MSavoritias (fae,ve)

    or even implement a client with syncing of history

  72. singpolyma

    MSavoritias (fae,ve): gnupg support most common ciphers, I dunno. The default might still be cast5 if you don't do anything but that's easy to change if you hate it. And not really relevant to any new tools

  73. moparisthebest

    > Why is that useful if you support any kind of history sync? Because no one (like the NSA) can use anything that was transmitted over the wire to decrypt it later

  74. MSavoritias (fae,ve)

    makes sene

  75. wgreenhouse

    gnupg won't present you with elliptic curve keys unless you choose an "expert" option

  76. debacle

    But over-the-wire we (can) have TLS with PFS, or not?

  77. wgreenhouse

    but they do make the most sense for something like OX

  78. wgreenhouse

    debacle: yes that's unrelated

  79. wgreenhouse

    (most sense due to tiny key size)

  80. singpolyma

    Right. Forward secrecy can help in some narrow cases, but if they get my phone they get my message history either way unless you do special handling that few do

  81. singpolyma

    wgreenhouse: yes, I would use ECC for a new ox thing probably. Probably still v4 keys for now but that may change in another year or two

  82. singpolyma

    And aes128 or 256 for cipher

  83. singpolyma

    Just to be boring and normal

  84. moparisthebest

    > But over-the-wire we (can) have TLS with PFS, or not? Yes but that's only in between hops, not PFS through the servers

  85. debacle

    moparisthebest Sure!

  86. moparisthebest

    Hopefully all TLS is PFS nowadays, pretty sure with TLS 1.3 this is guaranteed?

  87. singpolyma

    MSavoritias (fae,ve): the biggest ux obstacle for ox is you need a flow to get the key when enrolling a new device. Can be as simple as scan a QR code from the old device or similar but you do need something

  88. MSavoritias (fae,ve)

    yeah makes sense

  89. moparisthebest

    singpolyma: woah I thought having an old device wasn't allowed :P

  90. singpolyma

    Or seed phrase style

  91. MSavoritias (fae,ve)

    but still seems easier than handling prekeys

  92. MSavoritias (fae,ve)

    or whatever

  93. MSavoritias (fae,ve)

    for reference what i am thinking has no servers and supports multiple clients/devices by design

  94. singpolyma

    With ECC can probably put the whole key in a "recivery phrase" easily

  95. wgreenhouse

    unpopular opinion maybe but PFS at the message as opposed to transport level matters most when servers are on silos or on commercial hosting subject to unwanted access (and isn't enough in those cases, because the adversary still gets a full take of who you're talking to and when)

  96. MSavoritias (fae,ve)

    i see that there is also guile bindings to gnupg so i wouldnt have to write anything

  97. MSavoritias (fae,ve)

    thats a nice bonus

  98. singpolyma

    wgreenhouse: imo if you don't have seperate encrypt at rest on your device then they'll pick your pocket to get your messages long before they break your servers

  99. moparisthebest

    OX PGP has roughly all the downsides of PFS but also let's people store their key on the server protected by a 4 digit PIN signal-style making it useless

  100. MSavoritias (fae,ve)

    if its really only the pfs that is different between mls and ox i dont see why i would go with mls tbh

  101. MattJ

    moparisthebest, my family really do not care about the scenario where they are targeted by the NSA or equivalent. This applies to most people (but sure, not all)

  102. moparisthebest

    ugh missing commas in there... The storing key on server with 4 digit PIN is what makes it useless, the rest is fine

  103. debacle

    4 digit PIN is fun, indeed. Even by bank requests now 8 digit TANs.

  104. wgreenhouse

    singpolyma: I'm talking even about so-called "lawful" access; warrant request would almost always ask for the who as well as the what

  105. singpolyma

    wgreenhouse: right, bud PFS makes no difference in that case

  106. singpolyma

    they don't have your key either way

  107. singpolyma

    For that they need to get your device or similar

  108. moparisthebest

    > wgreenhouse: imo if you don't have seperate encrypt at rest on your device then they'll pick your pocket to get your messages long before they break your servers They don't need to break your servers, they can just ask the host for access without any lawful reason at all, it's perfectly legal

  109. singpolyma

    Just like with pfs

  110. wgreenhouse

    singpolyma: yes, that was my point

  111. wgreenhouse

    pfs is inadequate to the harms of letting someone else host your server

  112. moparisthebest

    That's why it's important that the key, not even encrypted, is stored on the server or has ever crossed it

  113. singpolyma

    PFS only helps if they have the encrypted log *and* your device but your device doesn't have unencrypted logs

  114. singpolyma

    moparisthebest: correct

  115. debacle

    moparisthebest The current implementation of OX (Gajim, Profanity) do not upload the private key to the server at all, only the public key. But they are also pretty bad in letting users copy their private key from one device to another.

  116. debacle

    AFAIK and TTBOMK.

  117. debacle

    Need to try OX with libervia and xmppc.

  118. singpolyma

    Storing key on server but encrypted means you need a strong passphrase. Better to just encode the key itself as a recovery phrase or use a seed phrase. Then there's nothing on the server

  119. moparisthebest

    Normal users aren't going to be copying their key between devices either

  120. moparisthebest

    And so message loss when losing all devices is the same vs PFS I guess

  121. MSavoritias (fae,ve)

    what i would like to see personally for backup of data is https://darkcrystal.pw/

  122. MSavoritias (fae,ve)

    which briar also implements

  123. MSavoritias (fae,ve)

    and doesnt need servers

  124. singpolyma

    It's similar yes, base changes what you need to back up (a phrase of 20 words on paper vs a gb digital archive)

  125. moparisthebest

    > Storing key on server but encrypted means you need a strong passphrase. Better to just encode the key itself as a recovery phrase or use a seed phrase. Then there's nothing on the server Yes users never forget seed phrases (I have to wipe my daughter's phone tonight because she set a new lock screen pattern she can't remember 😓)

  126. moparisthebest

    > what i would like to see personally for backup of data is https://darkcrystal.pw/ MSavoritias (fae,ve): having just read the first page, is that just shamir's secret sharing ?

  127. MSavoritias (fae,ve)

    yeah and it mentions it specifically https://darkcrystal.pw/protocol-specification/#8-shamirs-secret-sharing

  128. moparisthebest

    Old tech (which is good) and useful, but not so sure about for backups in general, this roughly means you pick N people to send your backups to and if a smaller number get together they can recover your backups

  129. moparisthebest

    Thanks for sharing it's nice to see an attempt to standardize it!

  130. MSavoritias (fae,ve)

    i was thinking it only for the key and contacts personally

  131. MSavoritias (fae,ve)

    it doesnt make sense to have everything in there

  132. MSavoritias (fae,ve)

    as in messages/media

  133. MSavoritias (fae,ve)

    but yeah i agree that is about a f2f network. (which is what i am targetting either way) public free for all networks require completely different considerations

  134. Schimon

    What does this stanza mean? ``` <iq id="0175d858c45c40d6a9c34efc379947e7" xml:lang="en" to="slixfeed@canchat.org/jtQR-u7ud__u" type="error" from="person@some.server"><error type="cancel"><service-unavailable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" /></error></iq> ```

  135. wgreenhouse

    Schimon: looks like whoever slixfeed was messaging with sent back a service-unavailable error, meaning the other party doesn't exist (or was blocking slixfeed)

  136. Schimon

    The other party is me

  137. Schimon

    Slixfeed is a Slixmpp bot

  138. Schimon

    I made some changes and found errors handling of subscriptions and I commited some actions to test the new code.

  139. Link Mauve

    Schimon, when you send an iq to someone, you generally want to target a specific resource and use the full JID, the bare JID will instead get answered by the server and that doesn’t sound like what you want.

  140. Schimon

    Then I have corrected the problem, but then found out some issues against contacts which I texted Slixfeed against.

  141. Schimon

    Link Mauve, I guess I did something that caused hthis due to wrong manner of handling subscriptions.

  142. Schimon

    Because what I do with Gajim is just the same as always.

  143. Link Mauve

    What is the iq you are replying to?

  144. Schimon

    I do not know

  145. Schimon

    It happened when I oressed on the "show presence" switch of Gajim

  146. Schimon

    It happened when I oressed on the "show presence" switch of a profile in Gajim

  147. Link Mauve

    You can enable debug logging in either of these clients.

  148. Schimon

    And also, this malformed way - I suppose - of handling subscriptions is no more, and I did not even save the code.

  149. Schimon

    I need to handle logging of Slithe bot. I did not take care of it. The only things I see are errors, warnings and "print"