Disclaimer: I never worked with the sound side-channel, so maybe what I'm going to say is not entirely true, but the general idea should be right.
Actually I think the job of the other core would be more difficult than just doing random noises to mask the noise from the actual secret computation.
Simply doing random computations (and thus, random noises) of the other core is not effective since random noise would "easily" be canceled using statistical tools (for instance, looking at the variance of the data instead of looking at it directly will already reduce some type of noises).
What would be more effective would be to balance the noise for instance, maybe running the same computation with opposite data would balance it more effectively. To picture what I'm saying better, here is a completely fanciful example (just to provide an idea). Imagine that during the RSA exponentiation (where the private key is exposed), the operation that is done when the bit of the secret key is 1 makes the sound "s_s_" and when it is 0 the sound is "_p_k". If you do the the same computation as the secret one on the other core exactly at the same time, but with the opposite secret key, then whatever the key is the attacker will always ear "spsk" at each clock cycle. And that will be harder to attack than random noises (but is also more difficult to achieve, of course).
That said, I don't know why the use of multiple cores would help the attack (but I didn't read the paper, just a few sample of the linked web page).
Actually I think the job of the other core would be more difficult than just doing random noises to mask the noise from the actual secret computation. Simply doing random computations (and thus, random noises) of the other core is not effective since random noise would "easily" be canceled using statistical tools (for instance, looking at the variance of the data instead of looking at it directly will already reduce some type of noises).
What would be more effective would be to balance the noise for instance, maybe running the same computation with opposite data would balance it more effectively. To picture what I'm saying better, here is a completely fanciful example (just to provide an idea). Imagine that during the RSA exponentiation (where the private key is exposed), the operation that is done when the bit of the secret key is 1 makes the sound "s_s_" and when it is 0 the sound is "_p_k". If you do the the same computation as the secret one on the other core exactly at the same time, but with the opposite secret key, then whatever the key is the attacker will always ear "spsk" at each clock cycle. And that will be harder to attack than random noises (but is also more difficult to achieve, of course).
That said, I don't know why the use of multiple cores would help the attack (but I didn't read the paper, just a few sample of the linked web page).