XMPP Service Operators - 2018-09-25

  1. Maranda

    SamWhited, erm lol now it works, I'm not sure what shenanigan was it in Conversations.

  2. Maranda


  3. Maranda

    but it fixed itself

  4. SamWhited

    Maranda: the lengths you gave were correct for SCRAM-SHA-1, maybe you were loading that instead

  5. Maranda

    SamWhited, hm nope

  6. Maranda

    SamWhited, and sha1 is 20 bytes if I understood correctly, sha256 is 32

  7. SamWhited

    20 is what you said before, I think

  8. Maranda

    SamWhited, no I said it mixed a 32 bytes signature with 20 bytes proof

  9. Maranda

    which is what cause the mega massive mayhem that broke XOR and all the rest hehe

  10. Maranda

    I was about to pull my hair out haha

  11. SamWhited

    Oh I see, that's *really* bad if that's happening somehow. I'll go double check, are you sure you didn't modify anything in the Java?

  12. SamWhited

    In Conversations, I mean

  13. Maranda

    SamWhited, I'm not sure how it happened but it looks like some bug in Conversations.

  14. Maranda

    Nope stock playstore Conversations

  15. SamWhited

    What signature in particular did you observe that length on? The client or server one?

  16. Maranda


  17. SamWhited

    The client signature comes directly from the hmac function, and the buffer is sized exactly so I don't see how that could change. Maybe it printed with some padding or something

  18. Maranda

    Server started tracing when attempting to run XOR to generate the Client Key out the challenge

  19. Maranda

    (so XOR'ing Signature and decoded Proof)

  20. SamWhited

    You'll want to account for malformed data on the server anyways, so probably best to just bail out if the lengths aren't what you're expecting

  21. SamWhited

    How were you getting the length from conversations, a debugger?

  22. Maranda

    SamWhited, no I added logging on the server then started testing on a lua interpreter :P

  23. Maranda

    https://github.com/maranda/metronome/blob/master/util/sasl/scram.lua#L215 ---> and that's solved

  24. Maranda

    XOR function is safed, so if there's a missing byte it'll break loop and abort.

  25. SamWhited

    What did your logging look like? I'm trying to rule out some sort of uninitialized buffer printing random garbage or something in lua land

  26. Maranda

    I just added logging in scram.lua with log() and tostring()

  27. Maranda

    to get values

  28. Maranda

    and then wen't looking for data in flat files as well

  29. SamWhited

    Ah wait, I'm being dumb and debugging the client signature, but it's the proof that you said was the wrong length for SCRAM-SHA-2

  30. SamWhited

    Checking the clientProof now

  31. SamWhited

    no, this appears right. The proof is setup to be the same sizes as the clientKey which is the same size as the hmac size, so that should be correct

  32. SamWhited

    I'll write some tests and see if I can't reproduce the issue

  33. Maranda

    SamWhited, I'm not sure if it was because of some messing up while I was tinkering with SASL to get it to work on the server, but that shouldn't have happened anyways

  34. Maranda

    *I think* in any case

  35. SamWhited

    If it gave bad output after giving bad input that would still potentially be a serious bug

  36. SamWhited

    Oooh, I have an idea. I wonder if it somehow mixed up the clientKey cache for the SHA-1 and SHA-256 variants. That would be a bad bug, but could cause this behavior.

  37. SamWhited

    I don't *think* it would be fatal or affect security though, it would just always cause validation to fail. I suppose technically it could let the server fetch scram info from another account, but that's not really a problem

  38. SamWhited

    Aha! That's it; thanks for spotting a bug!

  39. Maranda

    SamWhited, np yw

  40. Maranda

    ‎[16:55:25] ‎error: not-acceptable ‎[16:55:26] ‎ ha impostato l'argomento a XMPP Operators Room | http://mail.jabber.org/mailman/listinfo/operators

  41. Maranda