The send-many command caused "nameplate unclaimed"

[yarray]

Operation

On one machine (A):

wormhole-rs send-many <file>

It can successfully yield a code, such as 49-armistice-select. Then on the other machine (B):

wormhole-rs receive 49-armistice-select

Expected behavior

Machine B will download the file and exit. Machine A will keep hanging and wait for more receivers or user interactions.

Actual Behavior

Machine A's command crashed with an error Sending file to peer Error: 0: Nameplate is unclaimed: 49

Extra Information

I tried self-hosted relay with no luck.

The backtrace:

Location:
   cli/src/main.rs:904

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                                ⋮ 2 frames hidden ⋮
   3: <core::pin::Pin<P> as core::future::future::Future>::poll::h94846a2aa0a739d9
      at <unknown source file>:<unknown line>
   4: wormhole_rs::main::main::{{closure}}::h088aaa126086e025
      at <unknown source file>:<unknown line>
   5: std::thread::local::LocalKey<T>::with::hd469501c1b7561b3
      at <unknown source file>:<unknown line>
   6: <futures_lite::future::Or<F1,F2> as core::future::future::Future>::poll::h3df943656c87ea93
      at <unknown source file>:<unknown line>
   7: std::thread::local::LocalKey<T>::with::h7745c3fd8a7a2fd5
      at <unknown source file>:<unknown line>
   8: async_io::driver::block_on::h70ead178c9c2e9d9
      at <unknown source file>:<unknown line>
   9: std::thread::local::LocalKey<T>::with::h90f2304925c2e120
      at <unknown source file>:<unknown line>
  10: async_std::task::builder::Builder::blocking::h5e5f206d4d8db4b7
      at <unknown source file>:<unknown line>
  11: wormhole_rs::main::hff37f4a039de6830
      at <unknown source file>:<unknown line>
  12: std::sys::backtrace::__rust_begin_short_backtrace::hc86f095394455293
      at <unknown source file>:<unknown line>
  13: std::rt::lang_start::{{closure}}::he06cd52265ccc783
      at <unknown source file>:<unknown line>
  14: std::rt::lang_start_internal::h15895544e2012228
      at <unknown source file>:<unknown line>
  15: main<unknown>
      at <unknown source file>:<unknown line>
  16: __libc_start_call_main<unknown>
      at ./csu/../sysdeps/nptl/libc_start_call_main.h:58
  17: __libc_start_main_impl<unknown>
      at ./csu/../csu/libc-start.c:392
  18: _start<unknown>
      at <unknown source file>:<unknown line>

[meejah]

After a quick look, the "send-many" subcommand seems dangerous, as it's re-using the nameplate and code. Re-using codes isn't considered in the security analysis AFAIK, and shouldn't be done.

I didn't fully trace the code, but it seems like there's also a race here: someone may claim the nameplate before the "do it again with the same code" runs -- that's maybe what hit here? In the normal flow, the nameplate is de-allocated once it has served its purpose: getting two peers on the same mailbox-id with a share PAKE secret. There is then a period of time before this "send-many" code tries to claim that nameplate again, during which it may be allocated/claimed by a different client.

That said, given that you repeated on a private / self-hosted server, it may be a simpler bug than a race.

Regardless, I do not believe re-using the same code + nameplate combination multiple times is ever a good idea.

[felinira]

I've honestly not looked into send-many at all since taking over maintenance here. From what I remember though it has always been quite buggy. It is actually marked as "experimental" in the README. If there aren't any serious objections, I will remove the command in the future (contributions welcome, as always). This library is difficult enough to maintain already, and reducing the number of half-working features is a good thing in that regard. It might also prevent people to accidentally run into them :)

[piegamesde]

send-many absolutely is a hack, however people using it shows that it does have its merits as a feature. Ideally, this could be re-implemented more properly with first-class support of the protocol.

[meejah]

Can you outline more generally what the use-case is, and how this might work?

Useful features are great, but not at the cost of security.

I'm not sure that this "only" reduces security by a factor of "number-of-attempts" (e.g. it might be worse than that). Best case scenario is that it reduces security by a factor of "max number of attempts". Short-term I also support removing this (and e.g. putting it on a branch or something else far more clearly "experimental, do not use").

[piegamesde]

Use cases are primarily of the sort "I have this thing which I want to send to a group of friends", where one code can serve as broadcast for everyone to download.

Best case scenario is that it reduces security by a factor of "max number of attempts".

That was my security model, yes, though due to the nature of the UI a brute force attack would not go unnoticed

[meejah]

Could that use-case be served by e.g. creating N codes for the same file, along with a similar mode on the client (e.g. it can be given N codes and tries them one-at-a-time until one succeeds)? This would not require re-analyzing the security of SPAKE2 (in the face of "multiple code re-use" versus single-use codes).

[piegamesde]

Theoretically yes, however I fail to see how to build a good UX around that. If this is only about code reuse, then adding a counter to the code and trying out different counters, or making a time-based derivation function from the code would serve the same security purpose, correct?

[meejah]

adding a counter to the code and trying out different counters, or making a time-based derivation function from the code would serve the same security purpose, correct?

I don't see how that would change anything; an attacker could also make use of a counter or time-based code in the same way as any other client, no? (i.e. that doesn't add entropy)

[yarray]

I agree that send-many may not be as secure as a standard send. However, I have yet to find any safer alternatives in other products that surpass the conceptual model of send-many, which at least imposes limits on retry attempts and allows the code to be released at any time easily. Therefore, if possible, I strongly advocate for the re-implementation of this feature—perhaps with a warning and forcing a significantly longer code to reduce risk.

[piegamesde]

I don't see how that would change anything; an attacker could also make use of a counter or time-based code in the same way as any other client, no? (i.e. that doesn't add entropy)

You said the issue is that SPAKE security is unclear when reusing the code, so my proposal is to derive many codes from the user-facing code to avoid this. All other restrictions about retry limits apply. Indeed it doesn't add entropy, but part we can already solve by simply using a longer code if necessary

[meejah]

Can you describe what you mean by the counter thing then please? Perhaps I don't understand it.

[piegamesde]

Similar to your idea of having many valid codes and trying out several ones until one works that hasn't been used yet, one could do this with one code and have each client append some numbers to it to try out

[meejah]

My scheme means one nameplate+mailbox per code .. I don't see how "appending numbers" fits into this? (i.e. how to avoid over-subscribed mailbox?)

Really, though, PAKEs aren't (or at least SPAKE2 isn't) designed to be used this way. I can understand users might desire different UX or coverage of different use-cases -- but that probably wants a different cryptographic construct than a PAKE.