Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • L libotr
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 50
    • Issues 50
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Libraries
  • libotr
  • Issues
  • #135

Closed
Open
Created Apr 01, 2016 by IsisLovecruft@isis

Raw bytes from randomness source should be hashed before usage in keys

My friend Jakob Bleier, a Master's student at Raboud Universiteit, discovered that libotr uses raw bytes directly from its source of randomness (some garbled libgcrypt function) for the DH signing key, which is ultimately revealed in the Reveal Signature Message upon session completion. This is arguably not a bug, however, Jakob argues (and I would agree with him) that the OTR protocol should be specified and implemented in a way which does not leave ambiguities allowing implementers to shoot themselves and users in the foot. The idea is that, for example, on a system where the RNG is backdoored, or whatever library is used to retrieve randomness (e.g. libcrypt, or javac/bouncycastle in the case of otr4j) giving away the state of the RNG could allow an attacker to derive state at another point in time, compromising keys which may still be in use. Implementers shouldn't need to be familiar with the intricacies of the RNG in order to implement OTR safely.

The fix is quite simple, obviously, just hash the randomness before using it. (Tor does this as well.)

Jakob expressed interest in submitting a patch… I'll poke him and his advisors (Ruben Niederhagen and Peter Schwabe) and point them at this ticket.

(from redmine: created on 2016-03-01)

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking