Music file corruption without a change in checksum

[Paul R]

One post is missing - disappeared after I got the email. I'll address it since others no doubt read it too. Shamir didn't factor anything - he broke the govt.'s strongest encryption with a laptop, sound card, and an analog microphone. Such things are possible because of the inherent nature of encryption. That's why banks and other sites have to pay attention to the *implementation*, so they don't get stung by things like Differential Fault Analysis, or by Shamir's latest brainchild.

 

BTW, he didn't break just one message or transaction - he was able to grab the passcodes so he could access the day's cache.

 

BTW #2 - my own code has to implement a form of transaction serializing, to guard against clever plaintext or ciphertext attacks. That's something every installation has to deal with.

 

[Hi folks - that is a reply to a message I pulled when I replied to one I didn't intend to reply to. Apparently, when he is talking about "Shamir" he is talking about Adi Shamir - who is the "S" in RSA the encryption algorithm. And more disinformation above - I am very sure indeed that nobody has sat down with a microphone and a laptop and hacked 512bit or better RSA encryption. Even if that someone is supposed to be Dr. Shamir.

 

Dr. Shamir did think up a super fast factoring engine, named Twinkle. Twirl was it's successor, and would be even faster. Neither device, so far as I know, has ever been built. But they would sure look cool if they ever were... Twirl, if it were built would be able to factor a 1024bit number in about a year. That's a reasonable time and a reasonable cost.

 

If that happens, people would need to move to 2048bit or higher encryption (slower and much more computationally intensive) or to a different algorithm that does not depend upon the difficulty of factoring very large numbers.

 

-Paul ]

[wgscott]

[dalethorn]

[Hi folks - that is a reply to a message I pulled when I replied to one I didn't intend to reply to. Apparently, when he is talking about "Shamir" he is talking about Adi Shamir - who is the "S" in RSA the encryption algorithm. And more disinformation above - I am very sure indeed that nobody has sat down with a microphone and a laptop and hacked 512bit or better RSA encryption. Even if that someone is supposed to be Dr. Shamir.

 

Dr. Shamir did think up a super fast factoring engine, named Twinkle. Twirl was it's successor, and would be even faster. Neither device, so far as I know, has ever been built. But they would sure look cool if they ever were... Twirl, if it were built would be able to factor a 1024bit number in about a year. That's a reasonable time and a reasonable cost.

 

If that happens, people would need to move to 2048bit or higher encryption (slower and much more computationally intensive) or to a different algorithm that does not depend upon the difficulty of factoring very large numbers.

-Paul ]

 

Read it and weep: Researchers crack the world’s toughest encryption by listening to the tiny sounds made by your computer’s CPU | ExtremeTech

[mansr]

Apparently, when he is talking about "Shamir" he is talking about Adi Shamir - who is the "S" in RSA the encryption algorithm. And more disinformation above - I am very sure indeed that nobody has sat down with a microphone and a laptop and hacked 512bit or better RSA encryption. Even if that someone is supposed to be Dr. Shamir.

 

I'm not familiar with that particular anecdote, but many crypto implementations have fallen victim to side-channel attacks for key extraction. The scenario described would be possible if running the code modulates the power consumption of the CPU in a pattern correlated with the key bits. Many electronic components, especially (cheap) capacitors, act as little speakers under a varying current, and the resulting sound can be picked up by a nearby microphone. A correct extraction probably requires combining the sound recorded from many passes, but it has been demonstrated to work. The success of such an attack does not in any way invalidate the algorithms involved, only the particular implementation. Deriving random numbers from external, non-computer sources is also no defence; it is typically in the subsequent processing that information is leaked.

[YashN]

I'm not familiar with that particular anecdote, but many crypto implementations have fallen victim to side-channel attacks for key extraction.

 

There's even much worse than that.

[Paul R]

Read it and weep: Researchers crack the world’s toughest encryption by listening to the tiny sounds made by your computer’s CPU | ExtremeTech

 

Please shed your own crocodile tears.

 

Nothing all that spectacular there - been doing that kind of stuff since encryption began. They simply stole the encryption key, but to do so required physical proximity to the machine that already held the key. They did not crack the encryption key, they managed to steal it in a very clever way though.

 

Would not work on most machines though.

 

To rephrase in very simplemgerma - they did not crack the code, they stole the key. There is a significant difference.

[Paul R]

I'm not familiar with that particular anecdote, but many crypto implementations have fallen victim to side-channel attacks for key extraction. The scenario described would be possible if running the code modulates the power consumption of the CPU in a pattern correlated with the key bits. Many electronic components, especially (cheap) capacitors, act as little speakers under a varying current, and the resulting sound can be picked up by a nearby microphone. A correct extraction probably requires combining the sound recorded from many passes, but it has been demonstrated to work. The success of such an attack does not in any way invalidate the algorithms involved, only the particular implementation. Deriving random numbers from external, non-computer sources is also no defence; it is typically in the subsequent processing that information is leaked.

 

Yep. That and physical proximity to the computer itself.

 

Also, it would not work on a large computer with many many tasks running at the same time. A simple PC running DOS, yeah easy peasy.

 

One VM among a couple hundred? Not so much.

[mansr]

Yep. That and physical proximity to the computer itself.

 

Also, it would not work on a large computer with many many tasks running at the same time. A simple PC running DOS, yeah easy peasy.

 

One VM among a couple hundred? Not so much.

 

You'd need many more captures to separate the signal from the noise, and you'd probably need, or at least be hugely aided by, a way to trigger the relevant activity (could be as easy as starting a TLS session). A signal buried in noise is still a signal, and if it repeats, it can be isolated. For something running on a server, the difficulty of obtaining the required physical access is probably sufficient protection, but cryptography is used in many other places. Consider, for example, all the smartcards used for various security purposes.

 

BTW, to counter such attacks, it is often necessary to write a few core functions in assembly. It's the only way to ensure constant timing and flat power profile independent of the key or data.

[Paul R]

You'd need many more captures to separate the signal from the noise, and you'd probably need, or at least be hugely aided by, a way to trigger the relevant activity (could be as easy as starting a TLS session). A signal buried in noise is still a signal, and if it repeats, it can be isolated. For something running on a server, the difficulty of obtaining the required physical access is probably sufficient protection, but cryptography is used in many other places. Consider, for example, all the smartcards used for various security purposes.

 

BTW, to counter such attacks, it is often necessary to write a few core functions in assembly. It's the only way to ensure constant timing and flat power profile independent of the key or data.

 

True, but even then, separating our the noise is going to be a heck of a task on a typical server today, as the processing signature is, or at least is likely to be, wildly different even when a particular activity is triggered.

 

Credit Card chips are certainly not invulnerable, but they do add a nice layer of security to the business. When Chip and PIN is fully implemented, even more so. The PIN will be required before the terminal can initiate communications to the server. Still vulnerable, but fast less so that a mag stripe.

[Audio_ELF]

Credit Card chips are certainly not invulnerable, but they do add a nice layer of security to the business. When Chip and PIN is fully implemented, even more so. The PIN will be required before the terminal can initiate communications to the server. Still vulnerable, but fast less so that a mag stripe.

Wow ... you lot still don't have universal chip and pin in USA?

[Paul R]

Wow ... you lot still don't have universal chip and pin in USA?

 

No- just went to CHIP and sign on October 15 of this year in fact. They are trying to move it in as an evolutionary process, and force more of the liability onto the merchants. Gas stations still only take swipes, so far as I have seen, but I think they have an extra year or two to replace the readers on the pump.

 

CHIP and PIN is still very very rare here, I think that Barclays is the only card issuer supporting C&P right now.

 

-Paul

[wgscott]

Wow ... you lot still don't have universal chip and pin in USA?

 

Just got my first one. Given how far behind UK banks were 20 years ago, this is an even bigger travesty than you are inferring.

[dalethorn]

Please shed your own crocodile tears. Nothing all that spectacular there - been doing that kind of stuff since encryption began. They simply stole the encryption key, but to do so required physical proximity to the machine that already held the key. They did not crack the encryption key, they managed to steal it in a very clever way though. Would not work on most machines though. To rephrase in very simplemgerma - they did not crack the code, they stole the key. There is a significant difference.

 

That's a very comforting theory (not!), but anyway the principle (or fact as the case may be) does not require proximity to the bank's machine. It may be that the secret encryption is being performed on one's own personal laptop running the bank's code remotely. As is the case with all Internet transactions.

[dalethorn]

Just got my first one. Given how far behind UK banks were 20 years ago, this is an even bigger travesty than you are inferring.

 

Universal chips? What a crock! Just take the "technical stuff" out of the hands of the users, pat them on the head so to speak, and tell them "just trust us". How many times has that exposed users to loss? Answer: A lot.

[Paul R]

That's a very comforting theory (not!), but anyway the principle (or fact as the case may be) does not require proximity to the bank's machine. It may be that the secret encryption is being performed on one's own personal laptop running the bank's code remotely. As is the case with all Internet transactions.

 

The private encryption keys are never - ever - stored on remote computers like your laptop. Only the public keys, which are public in the first place. Great for encrypting information you are going to send to someone.

 

But of course, you cannot *decrypt* the information using the public keys. For that, you need the private keys. The ones that are stored only on the bank's computers...

 

They were talking about the private encryption keys, and that side crack absolutely requires proximity to the computer holding the private keys. Gaining access to which is very unlikely for anyone armed with a laptop and directional microphone.

[dalethorn]

The private encryption keys are never - ever - stored on remote computers like your laptop. Only the public keys, which are public in the first place. Great for encrypting information you are going to send to someone.

But of course, you cannot *decrypt* the information using the public keys. For that, you need the private keys. The ones that are stored only on the bank's computers...

They were talking about the private encryption keys, and that side crack absolutely requires proximity to the computer holding the private keys. Gaining access to which is very unlikely for anyone armed with a laptop and directional microphone.

 

Non-sequitur. Shamir obtained the private key not because it was stored locally, but because he derived it. It's a laptop, remember?

[mansr]

The private encryption keys are never - ever - stored on remote computers like your laptop. Only the public keys, which are public in the first place. Great for encrypting information you are going to send to someone.

 

But of course, you cannot *decrypt* the information using the public keys. For that, you need the private keys. The ones that are stored only on the bank's computers...

 

They were talking about the private encryption keys, and that side crack absolutely requires proximity to the computer holding the private keys. Gaining access to which is very unlikely for anyone armed with a laptop and directional microphone.

 

You might succeed in stealing a session key (AES or whatever), which will allow you to eavesdrop and potentially pick up a password. Banks usually use one-time pads (physical or electronic) for authentication, but other sites are often less secure. Lately it's become popular to use one-time codes sent by SMS as an additional security measure. It's also good practice to avoid doing banking in public places, just in case.

[mansr]

Non-sequitur. Shamir obtained the private key not because it was stored locally, but because he derived it. It's a laptop, remember?

 

A private RSA key can be obtained by factoring the public key. The hard part here is the factoring, not obtaining the public key. You do not factor 4096-bit numbers on a laptop, with or without a microphone.

[sandyk]

A signal buried in noise is still a signal, and if it repeats, it can be isolated.

 

Paul has had plenty of practice doing that. Underwater ! (grin)

[dalethorn]

You might succeed in stealing a session key (AES or whatever), which will allow you to eavesdrop and potentially pick up a password. Banks usually use one-time pads (physical or electronic) for authentication, but other sites are often less secure. Lately it's become popular to use one-time codes sent by SMS as an additional security measure. It's also good practice to avoid doing banking in public places, just in case.

 

"....but other sites are often less secure...."

 

Something not just to keep in the back of one's mind, but at the very front.

[dalethorn]

A private RSA key can be obtained by factoring the public key. The hard part here is the factoring, not obtaining the public key. You do not factor 4096-bit numbers on a laptop, with or without a microphone.

 

Are you suggesting that public keys are involved for the average Joe doing bank or other transactions?

[kumakuma]

Are you suggesting that public keys are involved for the average Joe doing bank or other transactions?

 

They are using public keys if their browser is using TLS to communicate securely with the bank's server.

[mansr]

Are you suggesting that public keys are involved for the average Joe doing bank or other transactions?

 

Why don't you tell us how it works, Mr Expert?

[dalethorn]

They are using public keys if their browser is using TLS to communicate securely with the bank's server.

 

So what Shamir did was just an anomaly, and public keys (not really known to be secure, in spite of the math) are the norm?

 

The reason I say "in spite of the math" is quite simple - people have been promising security for ages with these things, and there's always a leak somewhere. Does that mean that we ignore security? No - it means (in the words of Ronald Reagan) that if we trust, we "trust and verify". Unfortunately, the little guy doesn't have the means to verify very effectively, so that's where I come in.

[Audio_ELF]

So what Shamir did was just an anomaly, and public keys (not really known to be secure, in spite of the math) are the norm?

I may be wrong here... But didn't he "listen" to the computer doing the decryption, which therefore has the private key, and by listening to the CPU emissions was able to extrapolate the private (decoding) key?