# Is there a way to make a black-box function side-channel attack resistant?

If I have no knowledge of the inner workings of a function, (i.e. a black box function) is there a way to make it side-channel attack resistant? (For reference, I'm working with a JavaScript encryption library)

• If it's a black box, how do you know what side channels it could have? – Squeamish Ossifrage Oct 29 '19 at 17:27
• That's the problem I want to solve. It could be side-channel resistant, but I have no idea. – 09182736471890 Oct 29 '19 at 17:28
• This question is no more answerable than ‘if I have no knowledge of the inner workings of a protocol, is there a way to execute it so that it's secure?’. Nothing can be said in general about this. Maybe the black box leaks secrets out some randomization in the output, encrypted with a public-key so that you can never detect the leakage without knowledge of the adversary's private key. – Squeamish Ossifrage Oct 29 '19 at 17:33
• Then, how would I go about securing an implementation without completely breaking the algorithm? How can I know if some code can cause side-channels? – 09182736471890 Oct 29 '19 at 17:38
• If the black box leaks data other than the expected output then the black box may get an existentialistic crisis. – Maarten Bodewes Oct 29 '19 at 21:09

If I have no knowledge of the inner workings of a function, (i.e. a black box function) is there a way to make it side-channel attack resistant?

No, not really. When we make a cryptographical function 'side-channel' resistant, we generally use one of the following strategies:

• We modify the cryptographical implementation not to leak anything to that specific side-channel. For example, for timing and cache side channels, we can make the algorithm run in constant time and constant memory accesses (or, at least, independent of any secret data).

• We modify the cryptographical implementation to scatter the internal information so that getting information on only part of the cipher state does not divulge any information about what we're actually doing. For example, in a "thresholding" implementation, we might convert each bit on the cipher state into three internal bits (where the state of the logical bit is the exclusive or of the three internal bits). By doing this (and randomizing each individual internal bit), we ensure that the adversary needs to get side-channel information on all three bits simultaneously, rather than any one or two...

• We can exploit the mathematical properties of the cryptographical operation, performing the operation on random data, and then converting that into the result we are interested on. The canonical example of this is RSA ciphertext blocking; when we want to decrypt a ciphertext $$C$$, we select a random value $$R$$ and compute $$R^eC \bmod N$$ (where $$e, N$$ is the RSA public key); as $$R$$ is a random value uncorrelated to $$C$$, this is a random value. We pass this value to the low-level RSA decryptor, which will return $$RC^d \bmod N$$. We then multiply this by $$R^{-1} \bmod N$$, and that gives us the actual plaintext.

Unfortunately, none of the above actually works in your scenario. The first two involves modifying the cryptographical implementation, which you can't do, The last uses mathematical properties of the cryptographical algorithm, which a black box generally will not have.