glome-login test vector 2 does not use top 7 bits of key ID about glome HOT 3 CLOSED

An alternative we discussed is updating the protocol to remove this option and thus making it simpler. This was a "you would not need configuration" attempt, but one that would rely on smart key (re)generation, requiring knowledge of all prior public keys.

from glome.

The more I think about this, the more I come to the conclusion that the implementation is correct. The protocol specifies

7-bit service key prefix and message tag prefix (of any length, including 0)
[...]
if no index found [the service key prefix] will be matched with the public key

which is, granted, not very precise. But the 7 least significant bits of a value stored in little-endian format can ostensibly be called a prefix. More elegant would have been to take the 7 least significant bits of the most significant byte (exploiting the reserved high-bit of x25519 public keys), but I don't think we'd gain much from changing the implementation that way. If you agree, I'd say we adjust the protocol spec to say what the implementation does and close this issue.

from glome.

I think you are correct. In retrospect I confused myself. Because the top bit is always zero in the public key anyway, I think this actually makes more sense than a bit shift.

from glome.