# Randomness and authentication on short value outputs (48 bits)

I want to implement a client that generates random 48-bit values and send them as broadcast messages. We assume also there is a legitimate receiver getting those values (so, there is some sort of pre-authentication that has already happened but it is not of importance here. We can also assume the client/receiver share a common key $$K$$). Since these are broadcast messages it means also that anyone can intercept those values. I would like those values to have two properties:

1. It is difficult for an attacker to guess the next random value in the sequence
2. The receiver should be able to verify that these values are indeed coming from the specific client

I was thinking of a simple scheme that does the following:

## Client

1. $$t$$ = AES-CTR($$K$$, nonce||counter, random_plaintext)​

2. $$r = t ⊕ K$$ (keep last 48 bits)

3. Broadcast $$t, r$$

I use AES-CTR to generate a temporary random looking string $$t$$ and then XOR it with the key once again to generate my random value. I then keep the last 48 bits and broadcast both $$t$$ and $$r$$. Then the receiver can simply:

1. $$r' = t ⊕ K$$ (keep last 48 bits)
2. Verify $$r' == r$$

If the check succeeds then he authenticates the client because only he knows the same key $$K$$. Also the value being an output of AES-CTR should be fairly random meaning it is very difficult for someone to guess the next one.

Does this scheme achieve my requirements? Does the truncation of the last 48 bits pose a security risk?

• 1) Why not use standard protocols for authentication e.g. RSA, HMAC? 2) How does (K, nonce||counter, random_plaintext) survive reboots? 3) Is a TRNG/urandom thingie out of the question? 4) An attacker will probably collide your numbers within $2^{24}$ attempts. Does that matter? 5) Why only 48 bits? May 11, 2022 at 8:38

Does this scheme achieve my requirements? Does the truncation of the last 48 bits pose a security risk?

The scheme is broken by a passive adversary who gets a single pair $$(t,r)$$. Observe that the last 48 bits of the key can be recovered as $$K[:48] = t \oplus r$$. Therefore, the attacker can now send arbitrary $$(t^*, r^*)$$ values that the receiver will accept. Recalling that the verifier does the following

$$r' = t' \oplus K$$ (only keep last 48 bits); verify $$r = r'$$

We see that knowledge of the rest of the key is not needed.

Besides, 48 bits values offer low collision protection, but that may be fine for your application...

Replay: a more straightforward attack is to replay the pair $$(r, t)$$. The description doesn't say how the receiver checks for this.

Potential solution: From the initial description, it seems as if the receiver is fairly limited computationally speaking, and they can only compute xors are most and not the AES-CTR, for example. Which would be odd with the following

so, there is some sort of pre-authentication that has already happened but it is not of importance here

Anyway, a possible solution is using two pseudo-random functions if the receiver can do more than xors. ( I doubt it is secure...). Initially, expand $$K$$ into $$K_1, K_2, K_3$$ of appropriate length.

The sender does the following

1. $$r =$$ AES-CTR$$(K_1, counter)$$ (keep last 48 bits)
2. send $$counter, r, \tau = HMAC(K_2, counter,r)$$

1. Upon receiving $$r, \tau$$, verify $$\tau$$
2. Check counter has increased
3. Rederive $$r$$.

Some remarks:

• Broadcasting here is not even necessary if the sender and receiver are someone sharing a clock.
• The alternative has a few problems when it comes to robustness in case of a reboot, as pointed out in a comment by Paul.
• Let me clarify. Both end-points have sufficient capabilities to perform diffie-hellman operations to derive this common key $K$. Also both of them can support AES-CTR and AEC-CCMP for authenticated encryption. The 48 bits is a requirement of the protocol, so we have to live with that. I don't know if TRNG is possible in these devices, so I want to stick to cryptographically secure RNGs. May 11, 2022 at 11:55
• Another solution I was looking at is this: Generate: m=AES-CTR(randValue, K)​ Compute::​ r, T = AES-CCMP(K, m)​ Send:: r, T​ . Would that be more secure? Still though at the end r needs to be 48 bits. May 11, 2022 at 11:57
• Another explanation I might owe, is that (a) broadcasting is by design from the protocol (b) the two end points share some sort of timing counter value which is common to both ends May 11, 2022 at 12:39
• @Jimakos, tx for the added info. I would say, if both end points can do similar computation, then it’s easier to use a proven PRF to derive the randomness based on some unique values like a unique time stamp. And broadcast a beacon or said time stamp(this authentically) if mandated by the protocol May 12, 2022 at 8:27
• I didn’t analyze the second proposal in depth but it seems more complex than needed. The reuse of $K$ seems odd but may be totally fine here. If the sent values should be $(r,T)$. Then the could be use for the unique nonce and an authentication tag for $r$. As discussed: this provides functionality however you may want to consider robustness as well May 12, 2022 at 8:36