Chapel Hill Computational Linguists Crack Skype Calls

mikejuk writes "You might think of linguistics as being interesting but not really useful. Now computational linguistics [PDF of original paper] has been used to crack Skype encryption and reconstruct what is being said in a VoIP call. What is surprising is that though they are encrypted, the frames that make up a Skype call contain clues about what phonemes are being spoken."

Comments

Speach recognition

[city]

My Google Voice voicemail transcription gets about 1 out of 4 words correct. Can Google please buy this company already.

Re:Speach recognition

[Anonymous Coward]

Do you speak as well as you spell?

Re:Speach recognition

[bhcompy]

Vonage gets about 75%. Not bad. I think, secretly, that they hire people in India to do it.

Re:Speach recognition

[city]

or hire these researchers I should say.

Re:Speach recognition

[fragfoo]

Vonage gets about 75%. Not bad. I think, secretly, that they hire people in India to do it.

I should have guessed when the robotic voice sounded like Apoo! Vonaaage!

Re:Speach recognition

[newcastlejon]

I hope so; city's spelling was flawless.

You'd best learn what grammar is before you try to be a grammar nazi.

Re:Speach recognition

[Anonymous Coward]

Ze cow goes ... 'Shazzoooouuu'

Re:Speach recognition

[Eponymous Coward]

Speach?

Re:Speach recognition

[somersault]

"Speach"?

Re:Speach recognition

[Anonymous Coward]

I hope so; city's spelling was flawless.

I assume you're being sarcastic since we are discussing this in a thread titled "Speach recognition".

Re:Speach recognition

[Anonymous Coward]

Do you consider "speach" to be proper spelling? That's the way city spelled it.

Perhaps YOU'D better learn proper spelling before you falsely call someone else a grammar nazi.

Re:Speach recognition

[drb226]

speach

Scottish Gaelic. Noun speach f (genitive speacha, plural speachan)
1. wasp

Like newcastlejon said, his Scottish Gaelic spelling was flawless. I always hate it when Google doesn't recognize my wasps.

Re:Speach recognition

[gandhi_2]

Amazing.

This has so little to do with the article, you might as well have said that your cats breath smells like cat food.
Also off topic:
My droid's voice recognition gets Australopithecus afarensis right every time.

Re:Speach recognition

[Anonymous Coward]

Moving to the country, I'm gonna eat a lot of speaches.

Speaches come from a can, they were put there by a man, in a factory downtown.

Re:Speach recognition

[city]

Sorry im new here, there are articles?

Re:Speach recognition

[Anonymous Coward]

Like newcastlejon said, his Scottish Gaelic spelling was flawless. I always hate it when Google doesn't recognize my wasps.

Or he's blind and using TTS, you (possibly) insensitive clods!. Not you drb226, that was very amusing.

Could Google Speech google a googol of speach?

Re:Speach recognition

[johanatan]

His punctuation left a little to be desired though.

Re:Speach recognition

[AK Marc]

I read his damn post 4 times, slowly, and didn't notice any spelling errors. I never read TFA, and I never read subject lines. I was considering posting something like you did, until I scrolled down and read all the replies that pointed out the error wasn't within the post body...

Re:Speach recognition

[jdpars]

I applaud your use of the semicolon, good sir!

Re:Speach recognition

[vegiVamp]

Right now that would probably entail buying Microsoft. What could possibly go wrong?

Re:Speach recognition

[creat3d]

Is YOUR speech as pointless as your comment?

Re:Speach recognition

[Anonymous Coward]

Perhops you should find something else to argues aboot then a fucking typo. Hows old are you?

Re:Speach recognition

[kmoser]

That should be "Nazi" with a capital "N".

Side channel attack

[betterunixthanunix]

The wording in TFS is a little misleading; they did not "crack Skype encryption," they found an exploitable side channel in Skype. The crypto itself has not been cracked, but it was being used in a way that leaked lots of information.

Re:Side channel attack

[Anonymous Coward]

It's time for yet another layer of encryption.

Re:Side channel attack

[Anonymous Coward]

The simple description is: By looking at the size of the encrypted data packets you can guess what phonemes were spoken. Yes, that's all there is to it. They are just looking at how much data is sent and guessing what might be said that reasonably fits in that size.

An obvious simple fix would be to vary the length of the packets with random padding (using a cryptographically secure random algorithm to determine the length). It would add overhead but probably not that much considering how small these packets are in the first place (they typically don't use the full allotted bandwidth).

Re:Side channel attack

[blair1q]

if your encryption leaves the message where it can be read without decrypting it, then it was never actually encrypted

skype is using a lot more bandwidth than they need to. like single-sideband radio, they can drop at least half the channels they're sending and the information will still be perfectly intelligible on the other end. they've effectively done that by sending superfluous encrypted gibberish on their "main" channel.

the bonus is, their method of sending the message in the side channel is probably patentable.

Re:Side channel attack

[betterunixthanunix]

if your encryption leaves the message where it can be read without decrypting it, then it was never actually encrypted

While you are technically correct, you are not really contradicting what I said.

The encryption algorithm itself does not allow you to obtain the plaintext without decrypting it (as far as we know); the problem is that the protocol requires many encrypted messages to be sent in a particular sequence, and the size and sequence of those messages leaks information about the plaintext. This is a side channel, not a break of the encryption algorithm itself, and the problem is solved without any change to the encryption algorithm: use a different kind of compression (or no compression at all, but there are compression techniques that would not create this sort of side channel).

There is a relevant anecdote: some time ago, an ambassador used an encryption machine to communicate with his home country electronically. The host country was eavesdropping on his communication, and discovered that the plaintext was being transmitted along with the ciphertext (apparently this was due to some wire crosstalk). They had not cracked his encryption algorithm, they simply exploited the fact that the machine he was running the algorithm on was poorly designed.

Re:Side channel attack

[betterunixthanunix]

A simpler fix would be to use a different method of compression, which does not vary the length of its output frames.

Re:Side channel attack

[thePowerOfGrayskull]

There's a reason that SSH has inserted random padding into its packets since its inception. You would think that the folks at Skype might've done just a a bit more research...

Re:Side channel attack

[Anonymous Coward]

I believe that if the original message can be reconstructed, it's fair to say it's cracked. This is not unlike an age- old frequency analysis.

Re:Side channel attack

[gatkinso]

Is that really side channel - by that I mean it seems to me like block cipher mode crypto on a per packet basis is being employed... which would make it akin to a watermarking attack.

Re:Side channel attack

[NoSig]

If the padding is random you'll decrease the amount of information leaked, but there may still be enough information leaked to reconstruct some conversations. What you really need for total security from this attack is to eliminate the side-channel completely, such as by sending packets of the same size and with the same frequency no matter how much data you've actually got that needs sending. That is a form of padding too, but it is better than random.

Re:Side channel attack

[blair1q]

The Cone of Silence was never really all that soundproof, either. Nor was it at all cone-like.

Re:Side channel attack

[Anonymous Coward]

Here's another anecdote: early digital encrypted mobile phones would have difficulty driving the powerful RF system from the phone's small battery, especially when the battery level was low. And so the power drain from the audio system (powering the speaker) would modulate the RF signal at audio frequencies.

So you might not be able to break the encryption, but that's ok, because you could pick up what was being said using an AM radio!

Oops...

Re:Side channel attack

[AK Marc]

You are right and wrong at the same time. If the encryption still allows information to be accurately pulled from it after encryption, then the encryption is broken. The person that pointed out this flaw and exploited it is termed the person who broke it. So you are correcting someone that was actually correct. And you are correct as well. They aren't unencrypting the encrypted packet and extracting the information. But the encryption is broken because it allows information to be gained from the encrypted packets.

There is a relevant anecdote: some time ago, an ambassador used an encryption machine to communicate with his home country electronically. The host country was eavesdropping on his communication, and discovered that the plaintext was being transmitted along with the ciphertext (apparently this was due to some wire crosstalk). They had not cracked his encryption algorithm, they simply exploited the fact that the machine he was running the algorithm on was poorly designed.

Then to put it in the terms of your anecdote, they were able to compromise his secure communications link, thus the "secure link" was broken. That they didn't ever decrypt the encrypted communications is irrelevant to whether they were able to decode the communications that were encrypted. It doesn't matter if the failure was bad equipment, or, in this case, a poor encryption algorithm. It was broken. Arguing about whether they broke "the encryption" or "the secure channel" or "the encryption machine" is a worthless rhetorical exercise.

Re:Side channel attack

[betterunixthanunix]

Arguing about whether they broke "the encryption" or "the secure channel" or "the encryption machine" is a worthless rhetorical exercise.

Except that it is not just rhetoric. Suppose I use PGP to encrypt all of my email, but then save copies of the plaintext on a "cloud system" and someone comes along and reads the plaintext. What was broken? It was not PGP; PGP, when used correctly is secure.

Yes, if you use a cryptographic algorithm incorrectly, your security may be compromised. That does not mean the cryptographic algorithm was broken, it means your specific way of using it was bad. Just because someone managed to compute Sony's PS3 signing key does not mean that ECDSA has been cracked, and the same method they used would fail against a proper implementation. Likewise, the cipher being used by Skype has not been broken, and if it were used properly there would not be a problem (assuming the cipher itself is secure).

Re:Side channel attack

[AK Marc]

Are you being deliberately obtuse? The actual encryption method resulted in the vulnerability that resulted in the attack. That's completely unlike emailing a copy of your plaintext emails to the New York Post for safekeeping and then claiming that your disk encryption was broken. Now, if PGP, or your disk encryption were to email a copy of the key to a central server for safe keeping, then that would be similar to the situation described. However, your inability to form a related analogy indicates that you've made up your mind and then turned it off.

If you are willing to actually think about the subject at hand, let me know. Otherwise you are just making a fool of yourself.

Likewise, the cipher being used by Skype has not been broken, and if it were used properly there would not be a problem (assuming the cipher itself is secure).

Woah, I thought you were being obtuse, then I see this. It's not just obtuse, it's essentially a lie. No one claimed the cipher was broken, but that the encryption was broken. Since you speak like you consider yourself an expert, we have to assume you know the difference. Since you know the difference and are purposefully pushing something that's deliberately misleading, then you are not just an obtuse ass making a fool of yourself, but you are deliberately lying.

No one claimed the mechanics of the cypher were broken. The claim was that "Skype's encryption" was broken. To claim otherwise at this point is a plain lie, backed by all the previous posts showing that no one claimed what you are now lying to claim was claimed.

So, quite being obtuse. Quite lying. And you'll see that the encryption was broken. It was encrypted. And, like the "relevant anecdote" you included, it was broken by a part integral and necessary for that encryption. That's completely unlike sharing the unencrypted data out a different path. It's an in-line path that was required as part of the encryption (not by design, by by implementation) for both Skype and your anecdote. You might as well claim that someone performing a MITM attack on a VPN didn't break the encryption because they were given the key. But one of the points of a VPN is endpoint authentication. So even if you don't crack the cypher, you did break the encryption. So give up the "I'm never wrong" attitude. Read the words written, not what you wish they'd be so that you'd be right. Quit lying to us. And read the thread again, slowly.

But then, every time I've pointed out someone was a liar, they've always become more belligerent and more certain they were right, even when presented with proof they were wrong. So I don't expect this to go any differently. So long as everyone else reading this knows you are wrong, that's enough for me.

Just because someone managed to compute Sony's PS3 signing key does not mean that ECDSA has been cracked,

But it does mean that Sony's encryption was cracked. We aren't talking about the cypher. We are talking about Skype's encryption. Under every definition of "cracked" I've heard, Skype's encryption is now cracked. You can extract data from an encrypted Skype call. Cracked.

Re:Side channel attack

[Anonymous Coward]

I wasn't talking about making the padding itself random, but the length of the padding. That would not leak anything, it's the same technique SSH uses for its compressed mode and SSH is pretty damn secure.

Re:Side channel attack

[Anonymous Coward]

SSH didn't always do that. It was added (well, probably something like ten years ago now) after SSH had been in use for a while, and there were people trying out those timing attacks. You know, recovering a transcript from an inter-keystroke-interval pattern seems like a harder problem than the Skype crack, although the Skype crack was basically application of a speech recognition algorithm to the packet stream.

Re:Side channel attack

[betterunixthanunix]

Then I guess by your definition, all encryption everywhere is "cracked," since there is always a way to get the plaintext without attacking the cipher itself. There are easy to implement side channel attacks on a common software implementation of AES, which is used in both OpenSSL and NSS, but nobody is claiming that AES, OpenSSL, or NSS have been "cracked." There are side channel attacks on pretty much every encryption system out there, which is why in places where security really matters you see a lot of effort put into preventing people from exploiting those side channels.

The point of my original post was that claiming that these researchers "cracked Skype's encryption" was misleading. Yes, under an ambiguous definition of "cracked encryption" it might make sense, but at first glance it looks like TFS claims the researchers did something that they did not do. This is a side channel attack, not a cryptographic break, and claiming that the "encryption was cracked" is a very poor way to phrase things.

Finally, if you are going to claim that people get "belligerent" when you call them liars, maybe you should first examine the tone of your own post, which is needlessly hostile.

Re:Side channel attack

[bluemonq]

I think the sticking point here is the word "broken". It can be used in an adjective sense (there is something wrong with it) and an adverb sense (someone broke it). I think the other guy keeps reading it as the latter, aka mechanics were broken.

Re:Side channel attack

[AK Marc]

Then I guess by your definition, all encryption everywhere is "cracked,"

No. It requires actual judgment of whether the flaw is in the standard as expected to be applied. You are apparently purposefully ignoring judgment in order to defend your pet idea. There exists no implementation of Skype's encryption (not talking about the cypher it's based on) which you couldn't "break" in this method. Thus, there is no Skype conversation free from this attack, regardless of platform, implementation, or anything else. I'd call that "cracked." You call that "secure." That's where our opinion differs.

Since you assert 100% vulnerable to be "secure" then I can't see what value can be had in further communication. You've made up your mind and closed it, excluding all reason. I'd have better luck arguing with a brick wall.

Re:Side channel attack

[NoSig]

We agree on what you meant. To see the problem, imagine that you are sending the same message over and over again. I know that that is not what is going on here, it is only an analogy. The message you are sending has length L, while your noise has some distribution X. Then the message lengths that an attacker is going to see is going to come from the distribution L+X. The mean of L+X is going to be L plus the mean of X. The attacker already knows the mean of X from the source code. So if he can determine the mean of the distribution of the packet lengths then he can just subtract the mean of X from that to get L. Now the higher the variance of X is, the more samples the attacker will have to get to be confident that he has the right number, but that will also make some packets very long. This isn't a rigorous argument, but I hope it's clear that sending enough packets is going to reveal L, and then sending just 1 packet does reveal something about L also, even if you can make the amount of information revealed small by increasing the variance (and hence average packet length). There is a difference between secure and having side channels. E.g. SSH reveals at what time you are sending information, so SSH doesn't keep ALL of your information safe. That doesn't mean that SSH is insecure, it just means cryptography is tricky.

Re:Side channel attack

[betterunixthanunix]

Thus, there is no Skype conversation free from this attack, regardless of platform, implementation, or anything else. I'd call that "cracked." You call that "secure." That's where our opinion differs.

Except that is not what I said. I said that the encryption algorithm has not been cracked, because it has not. The attack is a side channel attack. This does not mean that Skype calls are secure, it means that an otherwise secure algorithm was applied in a way that undermined the security of the system.

There is a difference between the encryption algorithm, and the system that uses that algorithm. This same attack would have worked if a different encryption algorithm had been used, even one as widely evaluated as AES. The encryption algorithm is not what was cracked here.

Re:Side channel attack

[AK Marc]

There is a difference between the encryption algorithm, and the system that uses that algorithm. This same attack would have worked if a different encryption algorithm had been used, even one as widely evaluated as AES. The encryption algorithm is not what was cracked here.

"They broke Skype's encryption" is a true statement. The encryption package Skype uses is broken. Whether they did that from breaking the algorithm (I see after I spend a post proving "cypher" to be a pointless red herring, you've swapped to a new red herring in substituting "encryption algorithm" for cypher without changing your statements at all), or by some other attack that compromised the security of the encrypted calls is irrelevant to the truth. "Skype's call encryption has been broken." Again, that's a true statement that you don't like because you incorrectly infer that it means that the cypher, excuse me, it's "algorithm" this post, that the algorithm was broken. No one ever said that. You are arguing with nobody, and making incorrect statements along the way.

There is a difference between the encryption algorithm, and the system that uses that algorithm. This same attack would have worked if a different encryption algorithm had been used, even one as widely evaluated as AES. The encryption algorithm is not what was cracked here.

They broke through the algorithm without decrypting the algorithm. I'm not familiar enough with all of them, but it seems most other variable length crypto implementations of cyphers will pad in some manner variable length data to conceal the length of that data to help protect it from such attacks. Thus, the encryption was broken. Whether via decrypting the cypher or by a side channel attack, the encryption (system) is broken. This does not depend on the encryption (algorithm) being broken. You are stating that all values of "encryption" require "algorithm" added as a silent modifier. But that is just not the case. "The encryption was broken by a side channel attack" is a true statement and does not in any way imply that the cypher was broken. In fact, by definition of a side channel attack, it requires that the cypher was not broken.

I don't care how someone broke the encryption such that they gain access to my stuff. I just care that they broke it. As long as I didn't do something wrong (mail out my private key rather than public by mistake), if they broke the system, then the encryption is broken. Complaining about whether the cypher is secure while they are reading your data is fiddling while Rome burns. Or closing the gate after the horses have left. I couldn't care less whether the cypher is or isn't secure if I send encrypted data and it is intercepted and decoded. That's "broken encryption" by every definition on the planet. Well, apparently other than yours...

Re:Side channel attack

[AK Marc]

There is a difference between the encryption algorithm, and the system that uses that algorithm. The encryption algorithm is not what was cracked here.

"They broke Skype's encryption" is a true statement. The encryption package Skype uses is broken. Whether they did that from breaking the algorithm (I see after I spend a post proving "cypher" to be a pointless red herring, you've swapped to a new red herring in substituting "encryption algorithm" for cypher without changing your statements at all), or by some other attack that compromised the security of the encrypted calls is irrelevant to the truth. "Skype's call encryption has been broken." Again, that's a true statement that you don't like because you incorrectly infer that it means that the cypher, excuse me, it's "algorithm" this post, that the algorithm was broken. No one ever said that. You are arguing with nobody, and making incorrect statements along the way.

This same attack would have worked if a different encryption algorithm had been used, even one as widely evaluated as AES.

They broke through the algorithm without decrypting the algorithm. I'm not familiar enough with all of them, but it seems most other variable length crypto implementations of cyphers will pad in some manner variable length data to conceal the length of that data to help protect it from such attacks. Thus, the encryption was broken. Whether via decrypting the cypher or by a side channel attack, the encryption (system) is broken. This does not depend on the encryption (algorithm) being broken. You are stating that all values of "encryption" require "algorithm" added as a silent modifier. But that is just not the case. "The encryption was broken by a side channel attack" is a true statement and does not in any way imply that the cypher was broken. In fact, by definition of a side channel attack, it requires that the cypher was not broken.

I don't care how someone broke the encryption such that they gain access to my stuff. I just care that they broke it. As long as I didn't do something wrong (mail out my private key rather than public by mistake), if they broke the system, then the encryption is broken. Complaining about whether the cypher is secure while they are reading your data is fiddling while Rome burns. Or closing the gate after the horses have left. I couldn't care less whether the cypher is or isn't secure if I send encrypted data and it is intercepted and decoded. That's "broken encryption" by every definition on the planet. Well, apparently other than yours...

Re:Side channel attack

[Eivind]

Yeah. Furthermore, this is a *really* old and *really* well-known side-channel. Everyone knows, and has known for many decades, that crypto by itself is no defence against traffic-analysis, that is, you still know what size the packets are, and who the sender and recipient is, and the frequency they're sent with.

The only way to thwart that completely, would be to send a constant stream of constant-size packages regardless of if anything is being said or not, this is an easy fix, but it conflicts with the goal of saving bandwith.

Re:Side channel attack

[mgbastard]

um, this counts as cracking their encryption. Just because you can't efficiently perform a "cleartext" digital translation (it is analog sound...) doesn't mean you can't read the message.

And now that Microsoft has bought them for 8.5 billion: LMAO.

Fuck you Ballmer.

Re:Side channel attack

[nahdude812]

You could still save a lot of bandwidth, and protect against phoneme exposure by having fixed packet size transmission happen for a short interval after speaking occurred (perhaps randomly between 0.5 and 2 seconds). You'd be able to tell when people were speaking, but lose visibility into the cadence of the words. That shouldn't be that large an impact on the overall bandwidth consumption but should pretty much shut down this side channel.

Re:Side channel attack

[luis_a_espinal]

If the padding is random you'll decrease the amount of information leaked, but there may still be enough information leaked to reconstruct some conversations. What you really need for total security from this attack is to eliminate the side-channel completely, such as by sending packets of the same size and with the same frequency no matter how much data you've actually got that needs sending. That is a form of padding too, but it is better than random.

^^ This. I'm actually surprised to hear that with Skype the packets are of variable length and (somewhat) a function of the contents. I would have imagined that, after encryption, the communication protocol would split the content into packets of either random or same size.

But OTH, there might have been performance implications that forced Skype to not do just that. After all, there are legit reasons to not do super encryptions (as with the Predator's unencrypted download links.)

Re:Side channel attack

[betterunixthanunix]

"They broke Skype's encryption" is a true statement.

My point from the beginning is that that state is ambiguous. It is not clear from that statement that the researchers did not crack the actual encryption algorithm. It does not make it clear that the problem has more to do with the compression than with cryptography.

Whether they did that from breaking the algorithm (I see after I spend a post proving "cypher" to be a pointless red herring, you've swapped to a new red herring in substituting "encryption algorithm" for cypher without changing your statements at all), or by some other attack that compromised the security of the encrypted calls is irrelevant to the truth.

It is relevant to whether or not the statement is clear about what the attack actually constitutes. Again, my point from the beginning was that TFS is ambiguous.

Re:Side channel attack

[thePowerOfGrayskull]

You're right, I should have been clearer - meant SSHv2

Re:Side channel attack

[AK Marc]

Again, my point from the beginning was that TFS is ambiguous.

No, your point from the beginning was that it was "misleading." Misleading is an opinion that, based on other comments and what's actually broken in the wild, false. If you had asserted facts (ambiguous is a fact, misleading is an opinion), then there would have been no room for discussion.

When you hear that an application is broken, is it mostly because the underlying cypher was broken? I've never heard it that way. Because when someone broke the cypher, the statements were naming the cypher, not common applications using that cypher. As such, when hearing "application XXX encryption was broken" most people assume that the break is for that application only, which in almost all cases indicates that the cypher is still secure. So it seems to me that the overwhelming majority of application encryption being broken is something related to that application, and not the cypher.

That you assume the opposite of reality and then post your incorrect opinion as fact (especially when a simple word exchange that you yourself acknowledge is acceptable would have made it correct fact) isn't my fault.

Very....

[Anonymous Coward]

cunning!

Re:Very....

[jgtg32a]

You might say he's a cunning linguist

Re:Very....

[Anonymous Coward]

You should have said:

Oh! Those cunning linguists.

Re:Very....

[Nadaka]

And you sir are a master debater.

eww it's not Skype's day...

[Azmodan]

Looks like their karma isnt so good these days!

Ouch..

[SuperCharlie]

Seems like the Skype buy wasnt such a good thing for MS... its been what..a week or two and already its been down and compromised?

Re:Ouch..

[Lunix Nutcase]

Microsoft hasn't even bought it yet. Secondly, Skype has already had 2 major outages in the last 4 years.

Encrypting a wave

[Anonymous Coward]

Of course, since the data basically represents sound waves, there is a certain level of predictability and pattern on the data unlike normal data which is much more random.

It would have to be a special encryption to get rid of this pattern using a more dynamic algorithm that changes as it progress (which can make it annoying to decrypt or simpler to detect) or disjoint the data over a greater amount of data (making it somewhat harder to find the patterns though still might be possible) of the encryption though that is difficult in a time sensitive app like Skype which encrypts and sends as it receives the data.

Re:Encrypting a wave

[betterunixthanunix]

normal data...is much more random.

Actually, most data used in practice is not uniformly random. Text, images, and even computer programs tend to have significant biases.

It would have to be a special encryption to get rid of this pattern using a more dynamic algorithm that changes as it progress

http://en.wikipedia.org/wiki/Stream_cipher

We know how to get these things right, and the problem with Skype was not the type of data, but rather the way in which that data was compressed.

Re:Encrypting a wave

[Anonymous Coward]

What's normal data? If you're encrypting instant messages or text files or pdfs or jpgs or database backups they all have similar amounts of predictability such as file format markers or text containing written language.

In the case of text messages, the length of the ciphertext may leak information, i.e. the fact that a message sent was long or short. Terribly naive text message encrypters might even use ECB mode to encrypt, so the same messages sent multiple times would be obvious to a researcher (e.g. "lol" sent multiple times during a session would have the same ciphertext.)

From the article it looks like the leaked data (message length) exposed possible phonemes, which can be used to recreate phrases that possibly match the original spoken message.

Re:Encrypting a wave

[Ksevio]

What they need to do is add appropriate padding so the software just detects the people saying "Skype Skype Skype!" "Skype Skype?" "Skype Skype Skype Skype Skype!"

Re:Encrypting a wave

[Jonner]

Of course, since the data basically represents sound waves, there is a certain level of predictability and pattern on the data unlike normal data which is much more random.

It would have to be a special encryption to get rid of this pattern using a more dynamic algorithm that changes as it progress (which can make it annoying to decrypt or simpler to detect) or disjoint the data over a greater amount of data (making it somewhat harder to find the patterns though still might be possible) of the encryption though that is difficult in a time sensitive app like Skype which encrypts and sends as it receives the data.

It does not follow that encrypting sound waveforms leaks information just because they are predictable. If that were the case, encryption wouldn't be very useful in general. There is no such thing as "normal data" and most data people need to encrypt does have strong patterns. The entire purpose of encryption is to make non-random data look random.

The method for guessing what people are saying described in TFA exploits specific properties of the most efficient voice compression algorithms coupled with timing and size information that can be gleaned from capturing all datagrams. This method could be easily rendered useless by using a less efficient compression algorithm which uses a fixed bit rate or by simply adding padding to datagrams to hide the true size of the encoded audio frames.

overheard in a private jet hanger

[Anonymous Coward]

"8.5 billion USD doesn't buy you as much as it used to"

Re:overheard in a private jet hanger

[MightyMartian]

Indeed. In a few years it will probably buy you a frozen pizza... or Kansas.

Re:overheard in a private jet hanger

[BLToday]

It's how you spent it not how much you can buy with it. Skype was probably only worth $3B. Microsoft is acting like a newly rich basketball player by overpaying for needless stuff. Just because you can pay for something doesn't mean you should.

Re:overheard in a private jet hanger

[somersault]

It's hardly "newly rich" - it's been rich for quite some time. I'd call this more a "desperate grab for relevance".

Re:overheard in a private jet hanger

[blair1q]

it's a large multiple of what you need to buy a presidential election

Re:overheard in a private jet hanger

[NemosomeN]

You forgot to point out that microsoft isn't. a basketball player, either.

Re:overheard in a private jet hanger

[somersault]

Touche.

plague of any compressed voip conversation

[youn]

I remember reading something similar with sip over encrypted channel... I guess it is the plague of all compressed communication even if encrypted... the only way to bypass that is use an uncompressed protocol and not blank out the silence. I guess what's new is they've done it with skype.

Re:plague of any compressed voip conversation

[afidel]

I believe if you use a CBR codec like G.711 without VAD or CNG you should be ok.

Re:plague of any compressed voip conversation

[19thNervousBreakdown]

Or make it a constant bitrate.

Re:plague of any compressed voip conversation

[NemosomeN]

Or a constant packet size.

Re:plague of any compressed voip conversation

[swalve]

Then you can use the variability of the packet rate to deduce [something]. AM versus FM.

Re:plague of any compressed voip conversation

[Anonymous Coward]

Yes. constant noise (encrypted stream) is solution to this problem. Or bigger buffers with randomly distributed data and an index to sort it back.
My guess is that this technique is already used by professional equipment sold to governments, just it was kept secret.

Re:plague of any compressed voip conversation

[Anonymous Coward]

You either need to use a compression method which outputs constant bitrate, or pad a variable bitrate prior to encryption. Either way you'll need an encryption method which outputs a cyphertext of predictable length. This is because the goal is to produce a packet stream which is of uniform size and frequency.
The drawbacks are that you now are using your max bandwidth all the time instead of in surges, which exposes your stream to a higher chance of packet loss and jitter. Plus you're probably going to need more CPU and RAM resources to add the extra layer.

Now the other possible method is much trickier, but doesn't require maxing your packet stream all the time.
And that method is to use selective cryptographic padding to obfuscate the Semaphore information that is leaking through the current method.

Re:plague of any compressed voip conversation

[Jonner]

I remember reading something similar with sip over encrypted channel... I guess it is the plague of all compressed communication even if encrypted... the only way to bypass that is use an uncompressed protocol and not blank out the silence. I guess what's new is they've done it with skype.

It's only a problem for variable bitrate compression algorithms, not less efficient fixed bitrate ones like the venerable G.722. It may only be a problem for voice-specific variable bitrate codecs, not general ones like MP3 or Vorbis. This risk from this type of attack may also be greatly mitigated by decoupling datagram size and timing from the output of the encoder, which would probably increase latency but still allow use of efficient codecs.

Skype's encryption sucks

[HBI]

The reason why is that any serious encryption attempt of IP traffic would make all packets a constant size, significantly below expected MTU size (taking into account tunnels). This attack would not exist in that scenario. They are measuring the payload size of IP packets and matching it to phonemes spoken.

I probably shouldn't blame them for this, but it's barely worth the effort of encrypting the traffic if it is this easy to sniff out the words being spoken.

Re:Skype's encryption sucks

[Anonymous Coward]

The reason why is that any serious encryption attempt of IP traffic would make all packets a constant size

From TFA: A solution might be to break the data up into fixed sized frames but this would make it more difficult to reconstruct the data if there was packet loss.

Re:Skype's encryption sucks

[subreality]

The reason why is that any serious encryption attempt of IP traffic would make all packets a constant size, significantly below expected MTU size (taking into account tunnels). This attack would not exist in that scenario.

It's actually harder than that. You also have to generate the packets at an even rate as well, or you'll still have some leakage.

Even after you do that, the presence or absence of a stream of packets will at the very least indicate if a call is in progress; to defend against that, you have to *always* transmit the stream.

Even then you're leaking information about the maximum amount of data you could be communicating.

The goalposts keep moving right on down the field when you're talking about side channels. You just have to pick the point where you're comfortable.

Re:Skype's encryption sucks

[HBI]

Yeah, more difficult but not impossible. You just need a larger window and more buffers.

Re:Skype's encryption sucks

[indeterminator]

From TFA: A solution might be to break the data up into fixed sized frames but this would make it more difficult to reconstruct the data if there was packet loss.

And even then, the data rate would leak some information about the content.

The only trivial solution for zero leakage is to either use constant rate encoding, or use some kind of padding to make the data rate constant. Non-trivial solutions would include some random data rate variations to obfuscate the data rate of actual payload content. Unfortunately, all these methods will waste bandwidth.

Re:Skype's encryption sucks

[HBI]

"Somebody's talking" is information that it'll be hard to conceal without the measures you cite. I'd be ok with that, generally. Having 60% of what I say easily ferreted out is not ok, however.

Re:Skype's encryption sucks

[swalve]

You don't want buffers in voip. And its UDP, so I don't think there is a window.

Re:Skype's encryption sucks

[HBI]

I was mostly entertaining the thought. The truth is that in VoIP, RTP and RTCP are UDP-based and connectionless. There is no retransmission anyway. Either your link is solid or it isn't. Anything above about 3% packet loss will result in essentially unusable comms anyway. That is even very liberal.

You're right that there are no windows, as there is no retransmission.

Re:Skype's encryption sucks

[petermgreen]

Depends how well the VOIP system is designed, you could build a VOIP system to handle high rates of random packet loss. You would just need to

1: keep the buffers relatively big relative to the size of the packets (this means either smaller packets or bigger buffers)
2: use forward error correction techniques and/or information spreading techniques so that a lost packet can be reconstructed from others in the buffer

Probablly you would want to go into this mode in an adaptive manner if the channel was detected as being shit to avoid degrading performance for people on good channels.

What is harder is to deal with is block dumps of packets. If your buffer is 200ms long and something drops half a second worth of packets then the user is going to experiance a dropout whatever you do.

Re:Skype's encryption sucks

[Anonymous Coward]

"Somebody's talking" may be a lot of info, given that we're talking about natural speech. "Somebody's talking at the beginnging of a call for 0.8 seconds" is "hello" or "$caller_name" with a reasonable probability. You can take it from there.

I read it as...

[Anonymous Coward]

Cypress Hill Computational Linguistics

Re:I read it as...

[snookerhog]

insane in the membrane. so did I.

Re:I read it as...

[Anonymous Coward]

Insane in the Skype fraaames

Codec as the weak point

[hackertourist]

TFA states that this is possible due to the codec that is used:

the best...compression for voice data makes use of the structure of speech

So using a not-optimized-for-speech codec (e.g. mp3 or wav) would defeat this.

Re:Codec as the weak point

[blair1q]

it could have been defeated by encrypting the entire data stream instead of just part of it.

Re:Codec as the weak point

[profplump]

No, it really can't. Essentially this same paper, but as an analysis of SIP-IPSec/SIP-TLS, was published not long ago. Any real-time, size-efficient voice codec leaks a ton of information about the underlying speech just in the rate and size of its packets, so any encryption system that is real-time and length-preserving (i.e. any system that would be considered suitable to be paired with the underlying codec) leaks the same information. You can add padding to hide this, but A) that defeats the purpose of your size-efficient codec and B) while I haven't read any papers specifically analyzing padding techniques in voice comm, the papers analyzing padding in general packet comm suggest it's hard to come up with a padding system that provides an effective screen without adding a significant amount of latency or wasting more bandwidth than you're actually using.

The easiest workaround is really to just use uLaw encoding (or any other CBR codec) so that the packet size and rate doesn't reveal anything about the content of the audio stream. As hacktour suggests, even using a VBR but general-purpose audio codec instead of a voice-specific one would help, though if you're worried about security I wouldn't take the risk (unless you really can't run CBR due to low available throughput).

Re:Codec as the weak point

[blair1q]

Okay, so, then, what are the teachers in the Charlie Brown specials saying?

Huh? Mr. Smarty-pants?

Re:Codec as the weak point

[Anonymous Coward]

waa waa waa waa...

Language?

[Kamiza Ikioi]

TFA was TLDR, but a quick question to those of you with knowledge to understand this... Did a particular language help? Does this work on all languages? Are some languages more secure than others?

IE - Esperanto - Easy to break, but languages with Click Consonants are harder?

Re:Language?

[Anonymous Coward]

The methodology described is language agnostic, but requires access to a corpus from the target language. Theoretically languages with larger phoneme inventories would be more secure, but since English has a fairly large phoneme inventory, 99% of the world's languages are going to be even more vulnerable.

Huh?

[tthomas48]

No, I find linguistics pretty useful. Especially since it has some pretty 1:1 relationships with computer programming. And Larry Wall was a linguist. And what kind of lead in is that?

Re:Huh?

[blair1q]

i find linguistics pretty useful, too, since it's how translation of all kinds works (including code compilation). in fact, it's pretty silly to say anyone doesn't find it useful. maybe they meant studying linguistics is pretty useless, if you're not going to work in the construction of translators. but that could be said of any subject, and the continued propagation of that attitude across all subjects and throughout the population, in a nation operating democratically under the principle of majority rule, would result in the ending of public education.

and i'm pretty sure nobody wants that (except those who prefer an ignorant, easily-defrauded public).

Re:Huh?

[Anonymous Coward]

"You might think $THING_THAT_ONLY_A_DROOLING_IDIOT_WOULD_THINK but actually, ..."

Speculatively insulting readers is fun, I guess.

Re:Huh?

[Anonymous Coward]

Especially since it has some pretty 1:1 relationships with computer programming.

bullshit

And Larry Wall was a linguist.

would prefer he'd stuck to linguistics.

Re:Huh?

[Anonymous Coward]

@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f^ord
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&&
close$_}%p;wait until$?;map{/^r/&&}%p;$_=$d[$q];sleep rand(2)if/\S/;print

Clearly.

Similar work in a December 2010 paper

[guusbosman]

A December 2010 paper, "Uncovering Spoken Phrases in Encrypted Voice over IP Conversations", takes a similar approach.

The article was published in ACM Transactions on Information and System Security, PDF version.

The paper details a gap in the security of VBR compressed encrypted VoIP streams. The authors had earlier found that it is possible to determine the language that is spoken on such a VoIP call, based on packet lengths. Now they have expanded their research and show that itâ(TM)s possible to detect entire spoken phrases during a VoIP call. On average, their method achieved recall of 50% and precision of 51% for a wide variety of phrases spoken by a diverse collection of speakers (some phrases are easier to detect than others; the recall various from 0% to 98%, depending on length of the phrase and the speaker). In other words: they can detect fairly well if a certain phrase is being used in a conversation, even though the VoIP conversation is encrypted.

Encryption...

[theamarand]

Not sure how it works with voice, but I know with text, if you have a part of the message, it's a lot easier to break the encryption method - assuming it's breakable. Security is just a cat and mouse game, anyway. Someone finds a hole, someone plugs the hole, then someone finds another hole...etc. Fun stuff though!

Re:Encryption...

[betterunixthanunix]

with text, if you have a part of the message, it's a lot easier to break the encryption method

This is called a known plaintext attack, and any decent modern cipher should be secure against it (that is, you should learn very little even if I give you plaintext/ciphertext pairs). Modern ciphers are generally designed to be secure against this type of attack, as well as stronger attacks:

• Chosen plaintext attacks -- the attacker is allowed to request ciphertexts for plaintexts of his choosing.
• Chosen ciphertext attacks -- the attacker is allowed to request decryptions of ciphertexts of his choosing prior to observing the challenge ciphertext.
• Adaptive chosen ciphertext attacks -- the attacker is allowed to request decryptions of ciphertexts before and after observing the challenge ciphertexts, but cannot request a decryption of the challenge itself (he can, however, request a decryption of the challenge with a bit flipped or any other modification).

Original Slashdot Story

[SJ2000]

Encrypted VoIP Meets Traffic Analysis

Re:Original Slashdot Story

[nickersonm]

Yes; this is follow-up work to the paper in that earlier article.

Also important to note, neither paper is specific to Skype; their work is on encrypted VoIP in general. But apparently /. prefers things having to do with Skype for some reason.

side channel exploits latency constraint

[epine]

If you can compress the data stream from the packet contents to just the lengths of the packets and still recover the word stream, that suggests two things: A) vocal inflection is worth 100 words per syllable, and B) you're not compressing enough in the first place. Yet there's a reason why compression sucks: the low latency requirement. Compression over 5 minute speech blocks would blow this side channel away.

Were it not for the human tension of a conversation amounting to a group of people mutually waiting to speak (sometimes not so well), this wouldn't be so much of a problem in the first place.

Skeptic: My, what short packets you have!
Skype: All the better to interrupt you with.
Skeptic: What a juicy side-channel that makes.
Skype: Facebook rocks. Shut up and keep talking. I know it's you Alice, under that Hood.

Obligatory XKCD

[Anonymous Coward]

http://xkcd.com/114/

Linguistics not really useful. The ignorance

[jmcbain]

The ignorance of the statement "You might think of linguistics as being interesting but not really useful" is simply astounding. Linguistics provides the foundation and formal frameworks for grammar, syntax, morphology, phonetics, and semantics that allows us to better understand language. From that basis, computational linguistics is seen simply as an application of linguistics, and computational linguistics of course leads to information retrieval, automatic speech recognition, text classification, and other fields that are among the most important computing topics of the 21st century. Ignorantly saying linguistics is interesting but not useful is like saying physics and chemistry are interesting but not useful.

Re:Linguistics not really useful. The ignorance

[moogaloonie]

Yet it is no less true that someone reading that statement may indeed hold that opinion. I've always found it very interesting... How else might we ever develop human/animal translators?

Re:Linguistics not really useful. The ignorance

[sgt scrub]

Linguistics provides the foundation and formal frameworks for...

Agreed. mikejuk was obviously feeling dyslexic. In point of fact, nobody likes to discuss linguistics. It is boring as hell. :p

Re:Linguistics not really useful. The ignorance

[formfeed]

The ignorance of the statement "You might think of linguistics as being interesting but not really useful" is simply astounding.

Right. Would they have a linguist on basically every interplanetary mission, if they were just a bunch of useless bookish nerds ?!!

Re:Linguistics not really useful. The ignorance

[Anonymous Coward]

Also linguistics is important to attract the fairer sex. Ladies like a cunning linguist.

Re:Linguistics not really useful. The ignorance

[qc_dk]

The ignorance of the statement "You might think of linguistics as being interesting but not really useful" is simply astounding.

What ignorance would that be. I read that as a statement as a hypothesis that the common man might hold linguistics to be not really useful. The statement makes no claim whatsoever that linguistics is in fact not useful. In fact it makes the exact opposite claim.

Do you believe that the commonly held opinion is that linguistics is useful? or simply some academic pursuit for bearded people with leather patches on their elbows. I think you can easily get a feeling by looking at research grants to linguistics and compare them to those for generally perceived as useful areas like chemistry. I would not be surprised if linguistics get a lot less funding.

Re:Linguistics not really useful. The ignorance

[rk]

The common man might think this, but this is slashdot, where I hope the level of computer science and software engineering clue is still a bit higher than the background levels. Such people should already be aware of the close linkages between linguistics and computer programs and systems.

But maybe I'm just engaging in wishful thinking now.

Re:Linguistics not really useful. The ignorance

[Eponymous Hero]

mikejuk must have forgotten where he was posting. this is slashdot, however normal people do think that linguistics, physics and chemistry are not really useful. after all, it doesn't directly help them get laid, surf facebook, or masturbate on their ipad.

Obligatory

[Anonymous Coward]

Fuck Computational Linguists!

http://xkcd.com/114/

And here

[MonsterTrimble]

I was hoping that Skype had been cracked so we can start using 3rd party messengers!

Fsck You, Slashdot

[theshibboleth]

"You might think of linguistics as being interesting but not really useful" Way to go Slashdot, insult one of the most important fields in existence. Do the editors and readers really not realize how closely comp ling is related to AI? I have confidence that eventually computational linguistics will crack speech/language in general and lead to computers that can learn languages as readily as human infants. This will be momentous because it would allow communication between computers and humans. Now it wouldn't solve the consciousness problem, but it would be a step in the right direction.

Re:Fsck You, Slashdot

[TeethWhitener]

I noticed that too. Replace "linguistics" with "the space program" and watch how many slashdotters go supercritical.

Re:Fsck You, Slashdot

[xyourfacekillerx]

Haha that was about my reaction, and I agree with you entirely. The majority of my off-work hobby time involves something relating to THIS field. 60% of my personal notebooks are dedicated to it.

In particular, I am not so much interested in the models of physical intelligent machines (ANN's and so on) so much as the kind of abstract features of intelligence these capture (language, reasoning, decision making, etc.) I don't think there's a one-to-one mapping between the ability to use, computationally at least, a language - and the physical features of the machine that achieves that "behavior". I mean, I don't think the AI you mentioned depends on those physical details, much like our automobiles do the same things but don't all have internal combustion engines.

I think comp ling, and a few others fields (like those pertaining purely to natural deduction), these are the best approaches to get what you said.

Though let us be responsible as programmers and dispense with the notion of "consciousness" problem. We all know that the machine does what it's told. We will have machines that do very well to understand language in general, but map out its physical implementations, the spaces of RAM the "information" occupies, you see a bunch of disjointed, disconnected, random bits of meaningless data, whose only meaning is determined by the constraints provided by the programmer. This is quite different from the brain, where pieces of matter assert their own relationships. Machines won't be conscious, they need not be.

Re:Fsck You, Slashdot

[Anonymous Coward]

There's another way I, as a human being can communicate with my computer. It's called a SCREEN and KEYBOARD.

Re:Fsck You, Slashdot

[phantomfive]

I have confidence that eventually computational linguistics will crack speech/language in general and lead to computers that can learn languages as readily as human infants.

Why do you think this? Really, I want to know, because it is quite a claim.

Actually, two claims:
A) That computational linguistics will crack speech/language and
B) That this will lead to computers that can learn languages as readily as human infants.

Re:Fsck You, Slashdot

[theshibboleth]

Well A really entails B as in order to learn language computers would have to be predisposed to human language structures (see generative grammar. Linguistics has led to a number of categories of language (including logic, programming languages, and natural language). Before the 1950s people who applied mathematics to language thought human language might be regular. This was disproved by Chomsky using the hypothetical a^n,b^n language, and for human language examples of recursion (i.e. My wife is going to the show, My wife's sister is going to the show, My wife's sister's friend is going to the show) show that they are outside regular language and then are at a minimum context-free. In the 1980s there was finally good evidence that natural language might be even further out and a lot of grammars based on tree hierarchies with movement (which equates to dependencies between different words or morphemes in the sentence) were developed. This puts English and presumably all other natural languages into the context-sensitive category.

Since the 1980s there has not been a development as significant as either saying that natural language belongs to some other category - if it goes beyond context-sensitive then the calculations become so large that they are virtually impossible. So the question becomes can a computer represent a human brain (actually just the language subsystem).

I believe the answer is yes, partially based on research into so-called learning algorithms.

These usually take the form of given

a b
c b

a and c must be syntactically interchangeable.

You would probably be amazed at how readily a computer can then distinguish between nouns, verbs, etc. based on a simple one-difference algorithm like this. That's what I'm currently working on. Now imagine if that were hooked up to a semantic database (presumably informed by a human) and perhaps some sort of sensory input much like a child is informed by a parent. Then the computer would not only produce grammatical sentences but ones that at least seemed intelligent.

Re:Fsck You, Slashdot

[Anonymous Coward]

Way to go Slashdot, insult one of the most important fields in existence. Do the editors and readers really not realize...

Well, as a /. reader - yes I realize its importance. You insensitive clod!

Re:Fsck You, Slashdot

[Anonymous Coward]

Yes, they don't know. That's because your average reader hasn't really taken the time to think those kinds of connections through, unless it's been thought of for them. And then, when the topic is mentioned, they just recall narrowly related (if you're lucky) things to mind syntactically, and parrot off a few things they thought might be clever to say.

I know this, because I am one of them.

Re:Fsck You, Slashdot

[phantomfive]

ok, so you've found some form of learning algorithm that you think is somehow different than all the algorithms that have come before, and although smart people like Marvin Minsky and Doug Lenat thought their methods were the ones that were correct, let's assume for a moment that you are right, you have found the way the human brain processes input and converts it into memory/understanding.

Now how do you solve the hard problem of AI, which is, how do you give it will? How will it want to do something? How will it decide, based on all the input that it's receiving at every moment, that it should get up out of bed this morning and brush its teeth (or whatever computers do, oil their joints or something)? How do you make it decide that a certain girl is worth chasing after more than his job, or that it should now put one foot in front of another? More importantly, why should it want to put one foot in front of the other?

Crack pipe kills

[Anonymous Coward]

First glance: "Computational linguist's crack pipe kills"

First thought: "I guess you would have to smoke crack to want to spend your life as a computational linguist"

What?!

[erroneus]

You mean Skype wasn't smart enough to mix in other sounds while encrypting the original sound?! That is just retarded. Note that I am not a mathematician or any sort of "really smart guy." But I can definitely picture in my mind why this would be somewhat trivial. Vocal sound is primarily frequency modulated which means that the flow of signal will vary in density on a constant carrier. If you mix up the numbers, you will still see a great deal of fidelity in the variations of the frequencies of data regardless of the accuracy of the "decryption" involved. (a decryption of this sort would only need to be approximate to achieve results.)

And from the very beginning, I saw this possibility and presumed everyone else did as well. But if the signal were combined with another sound pattern which the receiving end would know how to properly remove after decryption, there would be a great deal less likelihood that an audio extraction could be made from the encrypted stream.

I have to wonder why this isn't being done. It is simply too obvious to patent.

Re:What?!

[Em Adespoton]

I have to wonder why this isn't being done. It is simply too obvious to patent.

You may have just answered your own question.

Other than that, the only thing I can think of (I had the same assumption you did) is that they were attempting optimal performance and low latency -- Skype actually works amazingly well over some routes that SIP dies on.

Re:What?!

[LS]

if the signal were combined with another sound pattern which the receiving end would know how to properly remove after decryption ..... I have to wonder why this isn't being done. It is simply too obvious to patent.

You obviously haven't been paying attention to the absolute nonsense that has been successfully receiving patents these days.

Re:What?!

[metacell]

I imagine it went down something like this..

Boss: Is the encryption module finished? We need to get 1.0 out in four days!
Programmer guy: Almost, I just need to find a way to pad the voice data.
Boss: What's that for?
Programmer guy: Well, the data stream's encrypted, but someone could find a way to guess which words are spoken depending on the size of the data stream over time.
Boss: But it's encrypted already, isn't it?
Programmer guy: Yes.
Boss: Just finish the module up and help the guys working on the network protocol. The padding thing will have to wait for version 2.0.
Programmer guy: Ok, boss.

(later...)

Boss: How's the chat protocol going? We need to get 2.0 out in four days!
Programmer: I'm working on the encryption protocol.
Boss: What? Who ordered changes to that?
Programmer: Um, no one, but I feel it isn't completely safe.
Boss: Has someone cracked it?
Programmer guy: No, but someone could crack if they looked closely at the size of the data frames and compared it...
Boss: Sorry, you'll have to fix that later. We promised animated smilies in version 2, and then I need you to help the interface team.
Programmer guy: Ok, boss.

Re:What?!

[Em Adespoton]

You'd almost think you were in the room :D

It takes a computational linguist...

[WaffleMonster]

To demonstrate the obvious. What do you expect when using high complexity VBR codecs with no blinding of any kind. I sincerely hope this was not news to anyone.

Missed opportunity

[essjaytee]

Surely this was the first ever legitimate use of the phrase "cunning linguist"

School or Town?

[methano]

I found it somewhat surprising that the Town name was used to identify the University. Would you say Ann Arbor or Ithaca or New Haven? You might say Berkeley or Princeton. So, I guess you might say Chapel Hill. OK, never mind.

Re:School or Town?

[JSBiff]

That all depends on the name of the School, doesn't it?

Private schools tend not to be named after the town. Public universities very often are named after the town they're in. I live in Ohio, I can name quite a few schools named after towns. . .

U of Toledo, U of Akron, Youngstown State University, Cincinnati State, The U of Cincinnati, Kent State University. Out of state I can think of University of Chicago, UC San Diego, UC Berkeley, (pretty much all the UC schools are named for the towns they are in), University of Miami (not to be confused with Miami University which is actually in Ohio), U of Pittsburgh.

Need more?

Can't be that good.

[Anonymous Coward]

Voice recognition still sucks, and those guys have UNencrypted data. Neat concept, but reliable enough for what?

Visual example

[CODiNE]

This is not the exact same thing, but it's a great example of how encryption alone is not enough and it must be done right.

Block cipher modes of operation

Scroll down til you see the penguins.

Do you have Aspergers?

[Anonymous Coward]

Or maybe narcissistic personality disorder.
How is 'you might think of linguistics as...' an insult?
That's saying *SOME* people may think that, *NOT ALL* people.

Either you're Dr. Sheldon Cooper or you're trolling.

Microsoft bought Skype

[Anonymous Coward]

Well isn't that just a coincidence?!?!! Microsoft goes and buys skype, and all of the sudden the protocol becomes decrypted. Could this because the Americans require these protocols be insecure? The americans sure would like to be able to listen into those terrorist skype calls... I may be paranoid but I think the government and Microsoft work very closely together!

You might think of the article submitter as

[TBBle]

the sort of person who belittles things he or she doesn't really understand or care about.

I know I do, now.

Either that, or it's Michael Larabel from Phoronix... Except the submission didn't actually have a half-dozen links back to previous articles on the same topic. But it's the same "Everyone sensible should be interested in what I'm interested in, and be bored by those things I don't understand" writing style.

Yeah!

[myoparo]

Go Linguists!

the usual

[Anonymous Coward]

oh, them cunning linguists!

Fuck computational linguists

[Anonymous Coward]

One more reason to hate them. Relevant: http://www.xkcd.com/114/

Have I understood it right?

[amn108]

So, as I understand, it may not be the obvious weakest potential link that has been compromised - the cipher itself for example - but rather a detail of implementation that paved way for their successful attack, right? If Skype fragment the encrypted data stream in variable sized frames that have also rather umm unpredictable (bear with me here) sizes, the attack, as stated by researchers themselves I believe, could not be instantiated in its current form? The entire weakness is based around the fact that it was relatively easy - far easier than bruteforcing the cipher - to guess the phonemes even from the encrypted frames.

Am I making sense here? Trying to verify if I have understood the main point of their research paper...

Re:Huh? "You might"

[b4dc0d3r]

"You might", and apparently you're someone who "might not". It's the lead-in for its intended audience, which is non-linguists. And among non-linguists, it is possible that people might find it interesting but not useful. Perfectly accurate, audience specific.

You'd think the linguists complaianing about this would be able to parse out the "...and you might not" which is implied.

old news (olds)

[Anonymous Coward]

http://it.slashdot.org/story/11/03/15/1513257/Encrypted-VoIP-Meets-Traffic-Analysis

The obvious conclusion is. . .

[Hamoohead]

. . .these are very cunning linguists.