Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Trac Trac
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Legacy
  • TracTrac
  • Issues
  • #32830

Closed (moved)
(moved)
Open
Created Dec 20, 2019 by Aymeric@Aymeric

Relay_extended - hash and padding - specs are wrong or unclear

I noticed recently plenty of 'unrecognized' relay_extended messages for node-Tor project while everything was working fine in the past after I updated the code and made it modular (and some abnormal delays to establish circuits), see also http://peersm.com/peersm2 this is temporary but I had to put a lot of debug stuff to find out what was going on

Finally I figured out why: unlike what is writen in the main Tor specs the hash is calculated not only with the real payload of the relay_extended messages but includes also the padding (apparently starting with 00000000, not sure where it comes from neither where it is specified)

This looks quite strange, what is the rationale for this, is it a bug, why is it not documented and does it impact other types of messages?

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