Try FFmpeg, a project that includes a server that does just that and some more. It can encode to many formats. Last time I used it though not every media player worked with its streams.
The PKCS specification does not say it is OK to apply a RSA transform directly, however, in section 7.1 it does say what the OAEP padding scheme tries to prevent,
and none of it is necessary for tinc.
Mallory creates a new connection (as Mallory) to Alice and sends METAKEY E_a(S2) to Alice, as his challenge to Alice. Alice replies with METAKEY E_m(S3) to Mallory.
Very creative! But, since when did Alice have Mallory's public key? Alice does not know Mallory's public key, unless tinc has been configured to trust Mallory in the first place. If not, then the connection would've been dropped right after the ID request. If they did already trust Mallory in the first place, then yes, you can save some CPU cycles doing the SHA1 hash by forwarding the challenge from Alice to Bob and vice versa, but that doesn't compromise anything!
The key exchange will be improved to make sure we have really perfect forward secrecy.
This is simple to fix, just fix it.
We won't, because it is not a problem. Many parts of the packets that are sent are predictable, because there is a lot of redundancy in them (think MAC, IP and TCP headers and trailers). That doesn't matter for the rest of the packet, or symmetric ciphers in general would be pretty worthless. You send many predictable things via SSL as well (think HTTP requests).
Sigh. Why do you think that? RSA should not be used "raw" -- that is without padding for either encryption or signing.
Again, padding is necessary when sending short messages, where improper termination might compromise RSA. We don't encrypt messages shorter that the key with RSA. In fact what we send using RSA has more entropy than any padded message encrypted with the same key could ever have.
I'm not going to "fix" this, not even if someone with more experience in this field only says: "I don't think you should do that", unless I get a decent explaination why it is bad.
As a matter of fact, we're doing this on purpose, and searches about this matter have not revealed any document claiming that what we do is bad, just that sending shorter, unpadded messages is bad.
Mallory created the session key, so of course he can decrypt using it, hash the challenge and send the hashed challenge back to Bob.
Mallory only created the key that is used to encrypt traffic TO Bob. He can't use it to decrypt the challenge he gets FROM Bob. The key Bob uses to send messages to Mallory is sent to Mallory encrypted with Alices public key.
Mallory could forward the challenge from Bob to Alice, and she would send a correct reply back to Mallory, but Mallory cannot decrypt that one either (because the key used to encrypt the challenge is sent encrypted with Bob's public RSA key), so he cannot forward it to Bob.
There is also no way for Mallory to make sure the same key is used for traffic from A to M and from M to B, unless he does not create the key used to encrypt traffic M to B himself, but forwards the encrypted key (which M can't decrypt) from A to B.
But then he can't send anything to B anymore himself. The same goes for the traffic from B through M to A. So, he can splice the two channels together, but only if he does not create the keys himself. If he doesn't create them himself, he cannot know them.
Alice encrypts the session key with Bob's public key, and sends it across the network. Mallory takes the packets and deletes it. Mallory encrypts his own session key with Bob's public key, and sends it to Bob. Mallory then creates a second (possibly different) session key and encrypts it with Alice's public key and sends it to Alice. Mallory sends Bob a encrypted challenge string, and Bob replies with hashed results. Mallory repeats this with Alice.
Sure. But Bob also sends an encrytped challenge string to Mallory, which he has to decrypt, hash, and send it back to Bob. He can't do that because he doesn't know the right key. He can't forward it to Alice and forward Alice's reply back to Bob, because he can't decrypt and reencrypt it. So, because he cannot answer either challenge, Bob and Alice will both cut the connection.
If you have any facts to back up your assertions that his claims are flaws, please feel free to share them with us.
Sure. Each side sends the key used for encryption of the TCP connection to the other side, encrypted using the public RSA key (which is known beforehand) of the other side.
Noone except the owners of the private part of the RSA keys can decrypt this. So there is no way to determine the keys used to encrypt the rest of the TCP connection for a man in the middle.
Show me the protocol design, and how is resists the attacks Peter mentions.
The protocol design has been part of the documentation for a long time.
[Tell me how tinc resists every attack we know of!]
Although it would be very nice to prove and document this, we do this in our spare time, for free. We want to create perfect software, but it won't happen tomorrow. At the moment we're just dealing with the things Peter mentioned.
To make it clear: Security software is assumed insecure by default.
Of course, we have never mentioned otherwise (see the README of tinc).
You, with no real security experience, seem to think you know more than Peter Gutmann, who has been working on cryptography and computer security since the mid-1990s. That's rich.
So, I'm not allowed to take a defensive stance if I believe he claims it's worse than it is? I should readily accept everything someone with has been working longer with encryption than I did?
He has no obligation to convince people who are ignorant of security that there software is flawed.
Of course it has to be convincing in order to be taken seriously.
Wow, I'm now inspired to never to use your software.
You are free to let Peter's analysis weigh more than everything we say. It just seems to me you are overreacting if you dismiss our work outright when we merily take some of his remarks in question.
We don't dismiss Peter's analysis, we just want to make sure what is right and what is wrong.
Peter Gutmann contacted us (the tinc developers) on September 15th, quoting the part of his writeup relevant to tinc. We exchanged a few emails since then. There are some points where tinc could certainly be improved (some of it already planned for 2.0), but we don't believe the "real problem" he mentions actually exists. We have told him our objections to his writeup, and asked if he could prove or make it more plausible that an attack on the authentication protocol is possible. He still hasn't convinced us.
In some more detail: the 32 bit predictable IV might make the other 32 bits of the first encrypted block more vulnerable, but the other 32 bits of that block only contain part of a MAC address which does not reveal any important information. It does not compromise the other blocks AFAIK, and in fact a sequence number instead of an unpredictable random number is more secure according to Jerome Etienne, who has done a much more detailed security analysis of tinc in the past.
The messages encrypted with RSA are indeed not padded, but padding is, AFAIK, only necessary when the message is shorter than the RSA key. In our case, the message is exactly as long as the RSA key.
Peter Gutmann believes there is a possible MITM attack ("Chess grandmaster attack"), but hasn't shown us how, just that he believes it's there.
Peter Gutmann also believes tinc has to be configured identically on each endpoint, but that is not true at all.
We're still in discussion, and if we believe there is really a problem we will fix it. In his conclusion Peter says that everyone should be using SSL or SSH. We could, but I don't believe SSL is necessarily the be-all and end-all of encryption.
2^96 is not nearly enough for every molecule on earth. Avogadro's number is 6 * 10^23, which is approximately the number of protons that weigh 1 kilogram together. Most molecules weigh less than 100 protons. 2^96 = 8 * 10^28. So at most 10^7 kilogram can be tagged uniquely with ECP. The earth weighs approximately 6 * 10^24 kilograms. Yeah, those "MIT boys" are really smart...
A chain is as strong as its weakest link. This applies to cryptography as well. In the Oppertunistic Encryption scenario, DNS is probably the weakest link. Spoof KEY records and you can launch a man-in-the-middle attack.
Most people forget the fact that total impulse is conserved. Given a matter and antimatter particle in rest, when they annihilate each other the two high energy photons that will be emitted will leave in exactly opposite directions. Those photons will not propel you forward. If you happen to get some pi-mesons out of the reaction, then yes you can use those fields, but then the amount of propulsion you get is equal to the energy you have to put in those fields, so you won't be any more efficient than that ion drive they used. The only way you could get instant propulsion if you could make a barrier that blocked all the photons going into the direction of travel. The photons would then transfer their impulse to that barrier. However, you'd need lots of concrete or lead for a barrier effective against the enormous amounts of energy that are released due to annihilation.
If the editor of news sites would sign news stories with their private PGP or GPG key, which of course should have a passphrase and shouldn't be stored on the web server anyway, then people could actually verify the integrity of the posted articles.
Then again, recent events might prevent a truly secure implementation of that anyway.
Why should I believe this Qualys firm? They do not say where they found this code. They do not even mention that someone else found this trojan. It seems a little unlikely to me that the first appearance of a trojan would be at a security firm, unless it originated there.
Most important though, they do not show an actual binary which allows me to verify their claims. The only thing they give me is a detection program, I would check THAT for trojan code if I were you! Actually the detection and cleaner program come in source code, and appear to be what they claim to be after a quick glance.
Ah you mean you want a bluetooth capable Atari Lynx?
The Atari Lynx was way ahead of time of course, like everything from Atari except the marketing. it had a colour LCD screen, you could flip it and use it left-handedly (try that with any other game console), and was about the size of the original gameboy I think.
If Infogrames would sell Lynx devices, they wouldn't even need to port the games:).
Re:Fundamental flaw...
on
Smart Routers
·
· Score: 2
Very true.
To back this with some numbers and an example:
Today's backbone linespeeds are in the order of 10 Gbit/s
Humans are sensitive to jitter/delay down to the order of 1 ms
How does QoS work? It puts packets in buffers in a smart way and sends them out at other times to make sure jitter and delay are as low as possible.
Since the human resolution is about 1 ms, the buffers need to be able to store roughly 1 ms of network traffic.
10 Gbit/s * 1 ms = 10 Mbit = ~1 Mbyte
So, each port on a QoS router in the backbone should have a buffer of 1 Megabyte behind it? And in 1 ms the logic in the router has to sort and shuffle the contents of that entire buffer?
Let's also calculate the duration of a packet of about 1 kbit big (that's close to the MTU):
1 kbit / 10 Gbit/s = 100 ns
Jitter on the network is in the order of a few packetdurations. Compare this to the resolution of a human. On 10 Gbit/s networks, this really isn't an issue anymore.
Where is the real problem? Where the network is slow. Where is that? Near your own modem: on the edge of the network. QED.
I have "hacked" the computer system of my high school (in the Netherlands) when I was about the same age, 14 I think. I wrote a little.bat script that stopped a computer from booting, displaying some vague message, and then replacing it with something else. Nothing harmful. Why did I do it? For the fun, because I could, something like that. It even displayed my name. I really didn't think I was doing something wrong. I also thought other people would surely recognize the simpleness and harmlessness of it after a few minutes. I didn't really know then that most of the other kids really didn't understand a think about computers. Even worse, I didn't take into account that even the teacher of the CS class hadn't the slightest. He came to fetch me during another course, he wanted to have a talk with me. He was quite reasonable (it wasn't in the USA after all), but still said that this was a Serious Offence, and my punishment was that I was never allowed in the computer room again for the next few years.
I was quite angry afterwards, I did not believe what I did was serious in any way. Perhaps because it wasn't serious? However I did not care much, there were other interesting things in school and I had access to other computers to play with. But I can imagine that if it had been closer to my heart (and I can imagine the boy who committed suicide really wanted to do stuff with computers in his life), I would be hurt a lot. I can even imagine trying to rid myself of this shame and humiliation by exitting life. And I can definitely imagine that I wouldn't tell anybody about how I felt about this.
Whose fault was this? No-ones. Could this have been prevented? Yes, the school board should learn that kids are eager to do this kind of stuff, not out of malevolence. Their 10-day suspension rule should be changed of course. If a kid tries to open a door of a room he shouldn't enter, just tell him why it shouldn't, don't beat the guts out of him.
There is also a card game (well, it starts like a card game anyway) called "Mao". There is a basic set of rules, which is only known to insiders. If you are new and want to join, you have to find out the rules yourself:). The person who wins gets to add a new rule to the game, which he does not tell to others. They have to find it out themselves. Most of the fun ofcourse is turning the rule someone made up against him;). Noone really can win, since winning is only fun if you continue with the game (which means it wasn't over yet and that means there is no definite winner yet)...
Slashdot Mirror
It's called proprioception.
Try FFmpeg, a project that includes a server that does just that and some more. It can encode to many formats. Last time I used it though not every media player worked with its streams.
We just posted a response to Peter Gutmann's security analysis on our website, please read it and feel free to comment (using email). We will update it if necessary.
What I said comes straight from the PKCS #1 v2.1 specifications.
Very creative! But, since when did Alice have Mallory's public key? Alice does not know Mallory's public key, unless tinc has been configured to trust Mallory in the first place. If not, then the connection would've been dropped right after the ID request. If they did already trust Mallory in the first place, then yes, you can save some CPU cycles doing the SHA1 hash by forwarding the challenge from Alice to Bob and vice versa, but that doesn't compromise anything!
Well check again, that is exactly why the attack you describe won't work.
The key exchange will be improved to make sure we have really perfect forward secrecy.
This is simple to fix, just fix it.
We won't, because it is not a problem. Many parts of the packets that are sent are predictable, because there is a lot of redundancy in them (think MAC, IP and TCP headers and trailers). That doesn't matter for the rest of the packet, or symmetric ciphers in general would be pretty worthless. You send many predictable things via SSL as well (think HTTP requests).
Sigh. Why do you think that? RSA should not be used "raw" -- that is without padding for either encryption or signing.
Again, padding is necessary when sending short messages, where improper termination might compromise RSA. We don't encrypt messages shorter that the key with RSA. In fact what we send using RSA has more entropy than any padded message encrypted with the same key could ever have. I'm not going to "fix" this, not even if someone with more experience in this field only says: "I don't think you should do that", unless I get a decent explaination why it is bad.
As a matter of fact, we're doing this on purpose, and searches about this matter have not revealed any document claiming that what we do is bad, just that sending shorter, unpadded messages is bad.
Mallory only created the key that is used to encrypt traffic TO Bob. He can't use it to decrypt the challenge he gets FROM Bob. The key Bob uses to send messages to Mallory is sent to Mallory encrypted with Alices public key.
Mallory could forward the challenge from Bob to Alice, and she would send a correct reply back to Mallory, but Mallory cannot decrypt that one either (because the key used to encrypt the challenge is sent encrypted with Bob's public RSA key), so he cannot forward it to Bob.
There is also no way for Mallory to make sure the same key is used for traffic from A to M and from M to B, unless he does not create the key used to encrypt traffic M to B himself, but forwards the encrypted key (which M can't decrypt) from A to B. But then he can't send anything to B anymore himself. The same goes for the traffic from B through M to A. So, he can splice the two channels together, but only if he does not create the keys himself. If he doesn't create them himself, he cannot know them.
Sure. But Bob also sends an encrytped challenge string to Mallory, which he has to decrypt, hash, and send it back to Bob. He can't do that because he doesn't know the right key. He can't forward it to Alice and forward Alice's reply back to Bob, because he can't decrypt and reencrypt it. So, because he cannot answer either challenge, Bob and Alice will both cut the connection.
Sure. Each side sends the key used for encryption of the TCP connection to the other side, encrypted using the public RSA key (which is known beforehand) of the other side. Noone except the owners of the private part of the RSA keys can decrypt this. So there is no way to determine the keys used to encrypt the rest of the TCP connection for a man in the middle.
Show me the protocol design, and how is resists the attacks Peter mentions.
The protocol design has been part of the documentation for a long time.
[Tell me how tinc resists every attack we know of!]
Although it would be very nice to prove and document this, we do this in our spare time, for free. We want to create perfect software, but it won't happen tomorrow. At the moment we're just dealing with the things Peter mentioned.
To make it clear: Security software is assumed insecure by default.
Of course, we have never mentioned otherwise (see the README of tinc).
So, I'm not allowed to take a defensive stance if I believe he claims it's worse than it is? I should readily accept everything someone with has been working longer with encryption than I did?
He has no obligation to convince people who are ignorant of security that there software is flawed.
Of course it has to be convincing in order to be taken seriously.
Wow, I'm now inspired to never to use your software.
You are free to let Peter's analysis weigh more than everything we say. It just seems to me you are overreacting if you dismiss our work outright when we merily take some of his remarks in question. We don't dismiss Peter's analysis, we just want to make sure what is right and what is wrong.
Peter Gutmann contacted us (the tinc developers) on September 15th, quoting the part of his writeup relevant to tinc. We exchanged a few emails since then. There are some points where tinc could certainly be improved (some of it already planned for 2.0), but we don't believe the "real problem" he mentions actually exists. We have told him our objections to his writeup, and asked if he could prove or make it more plausible that an attack on the authentication protocol is possible. He still hasn't convinced us.
In some more detail: the 32 bit predictable IV might make the other 32 bits of the first encrypted block more vulnerable, but the other 32 bits of that block only contain part of a MAC address which does not reveal any important information. It does not compromise the other blocks AFAIK, and in fact a sequence number instead of an unpredictable random number is more secure according to Jerome Etienne, who has done a much more detailed security analysis of tinc in the past.
The messages encrypted with RSA are indeed not padded, but padding is, AFAIK, only necessary when the message is shorter than the RSA key. In our case, the message is exactly as long as the RSA key.
Peter Gutmann believes there is a possible MITM attack ("Chess grandmaster attack"), but hasn't shown us how, just that he believes it's there.
Peter Gutmann also believes tinc has to be configured identically on each endpoint, but that is not true at all.
We're still in discussion, and if we believe there is really a problem we will fix it. In his conclusion Peter says that everyone should be using SSL or SSH. We could, but I don't believe SSL is necessarily the be-all and end-all of encryption.
2^96 is not nearly enough for every molecule on earth. Avogadro's number is 6 * 10^23, which is approximately the number of protons that weigh 1 kilogram together. Most molecules weigh less than 100 protons. 2^96 = 8 * 10^28. So at most 10^7 kilogram can be tagged uniquely with ECP. The earth weighs approximately 6 * 10^24 kilograms. Yeah, those "MIT boys" are really smart...
A chain is as strong as its weakest link.
This applies to cryptography as well.
In the Oppertunistic Encryption scenario, DNS is probably the weakest link. Spoof KEY records and you can launch a man-in-the-middle attack.
The IETF has already thought of scenarios like the one described (a router in every car). Look at the Mobile Ad-hoc NETwork working group.
I think they mean "Open ICANN". IANA is actually very open, and they have nothing to do with root nameservers management (anymore).
See the IETF Mobile Ad-hoc NETwork working group for work in exactly this area.
Most people forget the fact that total impulse is conserved. Given a matter and antimatter particle in rest, when they annihilate each other the two high energy photons that will be emitted will leave in exactly opposite directions. Those photons will not propel you forward. If you happen to get some pi-mesons out of the reaction, then yes you can use those fields, but then the amount of propulsion you get is equal to the energy you have to put in those fields, so you won't be any more efficient than that ion drive they used. The only way you could get instant propulsion if you could make a barrier that blocked all the photons going into the direction of travel. The photons would then transfer their impulse to that barrier. However, you'd need lots of concrete or lead for a barrier effective against the enormous amounts of energy that are released due to annihilation.
If the editor of news sites would sign news stories with their private PGP or GPG key, which of course should have a passphrase and shouldn't be stored on the web server anyway, then people could actually verify the integrity of the posted articles.
Then again, recent events might prevent a truly secure implementation of that anyway.
Most important though, they do not show an actual binary which allows me to verify their claims. The only thing they give me is a detection program, I would check THAT for trojan code if I were you! Actually the detection and cleaner program come in source code, and appear to be what they claim to be after a quick glance.
The Atari Lynx was way ahead of time of course, like everything from Atari except the marketing. it had a colour LCD screen, you could flip it and use it left-handedly (try that with any other game console), and was about the size of the original gameboy I think.
If Infogrames would sell Lynx devices, they wouldn't even need to port the games :).
To back this with some numbers and an example:
- Today's backbone linespeeds are in the order of 10 Gbit/s
- Humans are sensitive to jitter/delay down to the order of 1 ms
How does QoS work? It puts packets in buffers in a smart way and sends them out at other times to make sure jitter and delay are as low as possible. Since the human resolution is about 1 ms, the buffers need to be able to store roughly 1 ms of network traffic.10 Gbit/s * 1 ms = 10 Mbit = ~1 Mbyte
So, each port on a QoS router in the backbone should have a buffer of 1 Megabyte behind it? And in 1 ms the logic in the router has to sort and shuffle the contents of that entire buffer?
Let's also calculate the duration of a packet of about 1 kbit big (that's close to the MTU):
1 kbit / 10 Gbit/s = 100 ns
Jitter on the network is in the order of a few packetdurations. Compare this to the resolution of a human. On 10 Gbit/s networks, this really isn't an issue anymore.
Where is the real problem? Where the network is slow. Where is that? Near your own modem: on the edge of the network. QED.
I was quite angry afterwards, I did not believe what I did was serious in any way. Perhaps because it wasn't serious? However I did not care much, there were other interesting things in school and I had access to other computers to play with. But I can imagine that if it had been closer to my heart (and I can imagine the boy who committed suicide really wanted to do stuff with computers in his life), I would be hurt a lot. I can even imagine trying to rid myself of this shame and humiliation by exitting life. And I can definitely imagine that I wouldn't tell anybody about how I felt about this.
Whose fault was this? No-ones. Could this have been prevented? Yes, the school board should learn that kids are eager to do this kind of stuff, not out of malevolence. Their 10-day suspension rule should be changed of course. If a kid tries to open a door of a room he shouldn't enter, just tell him why it shouldn't, don't beat the guts out of him.
There is also a card game (well, it starts like a card game anyway) called "Mao". There is a basic set of rules, which is only known to insiders. If you are new and want to join, you have to find out the rules yourself :). The person who wins gets to add a new rule to the game, which he does not tell to others. They have to find it out themselves. Most of the fun ofcourse is turning the rule someone made up against him ;). Noone really can win, since winning is only fun if you continue with the game (which means it wasn't over yet and that means there is no definite winner yet)...