An issue was discovered in Croc through 9.6.5. When a custom shared secret is used, the sender and receiver may divulge parts of this secret to an untrusted Relay, as part of composing a room name.
The leading three characters of the shared secret are implicitly used to select a common "room name" at the relay so that sender and receiver can find each other (croc.go:827, croc.go:769, croc.go:572, croc.go:483).

When using shared secrets generated by Croc this is fine, because they are formatted just so that the leading part of the secret will make up the room name, like in "1355-sunday-yoga-africa". The leading number is completely unrelated to the rest of the shared secret. For some reason only the leading three digits will be used for the room name, in this case "135", while the final "5" will remain unused.

If a sender is selecting a custom shared secret then things can look different, though. Imagine selecting a secret like "MySecretPass". Now the relay will get "MyS" as room name. The relay is a possibly untrusted party that is not verified in the Croc protocol scheme (except if a relay password (`--pass`) is explicitly used). The room name is visible in cleartext to the relay, though. In the example of this custom secret, the room name reveals information about the rest of the shared secret used by sender and receiver. A malicious relay might thus be able to guess the shared secret or the cryptography may be otherwise weakened, allowing the relay to eavesdrop on the ongoing communication, or to impersonate the receiver.

For the parallel file chunk transfer further room names of the form `<digest>-<port>` (croc.go:1174) are used for setting up connections on the relay transfer ports (`--ports` option). Here `<digest>` is the SHA256 digest of the five leading characters of the shared secret. So it would be the SHA256 digest of "1355-" or "MySec" in the examples above. Of the resulting digest only the leading six characters will be used for the room name. The relay might be able to make deductions about the relatively short five character input for the hash e.g. by building rainbow tables. Although there will be a lot of collisions that likely make a practical attack difficult, this feels risky overall.

To fix this sender and receiver could always use a (sufficiently cryptographically secure) digest of the shared secret as room name. Adding a salt to the digest would be a good idea, but the salt cannot be exchanged since this mechanism is used by sender and receiver to find each other in the first place. Maybe using modern password hashing methods like bcrypt is a better approach here.

Generally I would try to avoid using the shared secret for anything else than setting up the cryptography - any use beyond that should be carefully considered and a safely derived value should be created.
Use of Parts of the Shared Secret as Room Name
This is a GitHub Issue
repo:croc
owner:schollz
Title : Use of Parts of the Shared Secret as Room Name
Issue date:

--- start body ---
The leading three characters of the shared secret are implicitly used to select a common "room name" at the relay so that sender and receiver can find each other (croc.go:827, croc.go:769, croc.go:572, croc.go:483).

When using shared secrets generated by Croc this is fine, because they are formatted just so that the leading part of the secret will make up the room name, like in "1355-sunday-yoga-africa". The leading number is completely unrelated to the rest of the shared secret. For some reason only the leading three digits will be used for the room name, in this case "135", while the final "5" will remain unused.

If a sender is selecting a custom shared secret then things can look different, though. Imagine selecting a secret like "MySecretPass". Now the relay will get "MyS" as room name. The relay is a possibly untrusted party that is not verified in the Croc protocol scheme (except if a relay password (`--pass`) is explicitly used). The room name is visible in cleartext to the relay, though. In the example of this custom secret, the room name reveals information about the rest of the shared secret used by sender and receiver. A malicious relay might thus be able to guess the shared secret or the cryptography may be otherwise weakened, allowing the relay to eavesdrop on the ongoing communication, or to impersonate the receiver.

For the parallel file chunk transfer further room names of the form `<digest>-<port>` (croc.go:1174) are used for setting up connections on the relay transfer ports (`--ports` option). Here `<digest>` is the SHA256 digest of the five leading characters of the shared secret. So it would be the SHA256 digest of "1355-" or "MySec" in the examples above. Of the resulting digest only the leading six characters will be used for the room name. The relay might be able to make deductions about the relatively short five character input for the hash e.g. by building rainbow tables. Although there will be a lot of collisions that likely make a practical attack difficult, this feels risky overall.

To fix this sender and receiver could always use a (sufficiently cryptographically secure) digest of the shared secret as room name. Adding a salt to the digest would be a good idea, but the salt cannot be exchanged since this mechanism is used by sender and receiver to find each other in the first place. Maybe using modern password hashing methods like bcrypt is a better approach here.

Generally I would try to avoid using the shared secret for anything else than setting up the cryptography - any use beyond that should be carefully considered and a safely derived value should be created.
--- end body ---
