Disclaimer: I'm not as interested in practical applications of this as much as I just want to know if it is possible or not.

The situation: multiple people are connected and exchanging data over cloud variables in a scratch multiplayer game.
The problem: how to tell apart data sent by different players?
The common solution: send encoded player's username or some numeric identifier within the data.
The flaw: While scratch servers know what connection each cloud variable update comes from, and even shows the username in the cloud log, the project itself doesn't have access to any reliable source of this information. It has to rely on and trust what is sent within value of cloud variable. People can use external tools to send whatever data they want through cloud variables, allowing them to detect who is currently connected and start sending fake data on behalf of other players who are currently connected.
Solution (turn based games): use asymmetric encryption like RSA for digitally signing each piece of data. Though assuming the use of 2048-bit RSA, which is currently considered secure enough amount of bits, the signature will take up 617 digits, meaning that with current 256 digit limit, every piece of information will need to be send in 4 chunks (1 for data, 3 for the signature).
Solution (real-time games): on TurboWarp with it's generous cloud variable limit, RSA may also be viable (but slow). But I don't know if there is any way to do it on vanilla Scratch.

The question is: Is it even theoretically possible to solve the impersonation issue for real-time games in any proper cryptographic way (like it is possible for turn based games) (not security through obscurity), or are all games made in scratch forever destined to be vulnerable to this type of attack?
Note: I don't mean verifying usernames, I just mean telling apart data sent from each instance of the same project running in a non-spoofable way. So that bad actors cannot send data on behalf of someone who is already playing.

You don't have to use 2048 bit RSA. Every message has to have a signature, which is generally made by hashing the message and encrypting it with a private key. You verify it by hashing the message, decrypt the signature, and if they're the same the message is valid. You can make the hash/keys whatever length you want. Considering the hackers are mostly children who don't have access to supercomputers, and the keys aren't in use for very long, we could get away with some pretty low key sizes. 330 bit RSA takes around an hour to break on modern hardware, which is usually longer than someone is playing a game for. We can also shorten the time a key is in use by re-authenticating every few minutes.
Another thing to consider is that any level of RSA is already a large barrier, since the hackers have to implement something to break it into their program.

i misread your post and thought you were interested in scratch usernames. I left it here though:

if you had an external server connected to scratch’s cloud websocket server, and you validated all claimed usernames against the real username data, you could do something (maybe even with cryptographically signing things there).

otherwise even if you had fancy cryptography and no external validation, at the end of the day you’re trusting the user to self report their username (which is trivial to change in scratch’s vm state).

in other words, I think this is unsolvable neatly within scratch alone. (specifically in relation to scratch usernames, if your game has an internal identifier maybe?)