Re: packet traffic analysis
I very much doubt it. Where did that factor of half come frome. During lulls, you are constantly sending chaff packets. On average, you're halfway through transmitting a chaff packet when you want to send a real one. The system has to wait for it to finish before sending another. QED. Ah, but if you generate unequal-length packets then they are vulnerable to length-analysis, which is a form of traffic analysis. I'm talking about a stream, with packets embedded in it. For circuit-switched circuits, this is no problem. For a packet-switched network, you must packetize the stream, which is unrelated to the packets embedded in the stream. This is somewhat inefficent, which is why I suggested that it is more applicable ot something like PPP, SSH, or OpenVPN links, which are already virtual circuits. This is a fair criticism, but just think of the number of such circuit/packet conversions when someone uses a TCP virtual circuit over packet-based IP over an analog POTS link, which is itself a virtual circuit that is packetized and sent over a circuit (long-haul wirepair or fiber) in the telco network. If you explain to me how an eavesdropper can tell where plaintext packet begins or ends, then I'll agree with you that it is indeed vulnerable to length analysis. A better solution would be to leave the encryption on and use constants (not PRNG output) for the chaff, as previously discussed. That might or might not be a problem. With ECB, it's vulnerable to analysis (chaff is constant, so encryption of it is constant). With some modes, the amount you can transmit is limited (e.g. CTR mode). Modes that are based on a small window of previous plaintext, such as OFB, would be vulnerable too. It could very well be that it's a bad idea to send a lot of constant plaintext under other modes, as well. For example, if most of the data is constant, then you have a close approximation of known-plaintext. The notion of synchronized PRNGs is IMHO crazy -- complicated as well as utterly unnecessary. It's not necessary to run a PRNG on the receiver. You just have to be able to tell when you're looking at random data, or an encrypted version of an escape sequence and a valid packet, which can be recognized, as per your point 4a. If you find that it's not a legitimate packet, you treat it as PRNG data, and start looking for the encrypted escape sequence. However, with a 32-bit escape sequence, the chances of getting such a false positive are low. I personally think sending encrypted versions of constant data under the same key you use for real data is not crazy, but somewhat imprudent. Do you know what the unicity distance is? Have you read of attacks that require a large amount of ciphertext encrypted under the same key? -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: packet traffic analysis
Modes that are based on a small window of previous plaintext, such as OFB, would be vulnerable too. My mistake, OFB does not have this property. I thought there was a common mode with this property, but it appears that I am mistaken. If it makes you feel any better, you can consider the PRNG the encryption of constant text, perhaps using the real datastream as some kind of IV. The content of the chaff is not relevant; ideally you would use a high-bandwidth HWRNG such as Quantis. -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: packet traffic analysis
I very much doubt it. Where did that factor of half come frome. During lulls, you are constantly sending chaff packets. On average, you're halfway through transmitting a chaff packet when you want to send a real one. The system has to wait for it to finish before sending another. QED. Ah, but if you generate unequal-length packets then they are vulnerable to length-analysis, which is a form of traffic analysis. I'm talking about a stream, with packets embedded in it. For circuit-switched circuits, this is no problem. For a packet-switched network, you must packetize the stream, which is unrelated to the packets embedded in the stream. This is somewhat inefficent, which is why I suggested that it is more applicable ot something like PPP, SSH, or OpenVPN links, which are already virtual circuits. This is a fair criticism, but just think of the number of such circuit/packet conversions when someone uses a TCP virtual circuit over packet-based IP over an analog POTS link, which is itself a virtual circuit that is packetized and sent over a circuit (long-haul wirepair or fiber) in the telco network. If you explain to me how an eavesdropper can tell where plaintext packet begins or ends, then I'll agree with you that it is indeed vulnerable to length analysis. A better solution would be to leave the encryption on and use constants (not PRNG output) for the chaff, as previously discussed. That might or might not be a problem. With ECB, it's vulnerable to analysis (chaff is constant, so encryption of it is constant). With some modes, the amount you can transmit is limited (e.g. CTR mode). Modes that are based on a small window of previous plaintext, such as OFB, would be vulnerable too. It could very well be that it's a bad idea to send a lot of constant plaintext under other modes, as well. For example, if most of the data is constant, then you have a close approximation of known-plaintext. The notion of synchronized PRNGs is IMHO crazy -- complicated as well as utterly unnecessary. It's not necessary to run a PRNG on the receiver. You just have to be able to tell when you're looking at random data, or an encrypted version of an escape sequence and a valid packet, which can be recognized, as per your point 4a. If you find that it's not a legitimate packet, you treat it as PRNG data, and start looking for the encrypted escape sequence. However, with a 32-bit escape sequence, the chances of getting such a false positive are low. I personally think sending encrypted versions of constant data under the same key you use for real data is not crazy, but somewhat imprudent. Do you know what the unicity distance is? Have you read of attacks that require a large amount of ciphertext encrypted under the same key? -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: packet traffic analysis
Modes that are based on a small window of previous plaintext, such as OFB, would be vulnerable too. My mistake, OFB does not have this property. I thought there was a common mode with this property, but it appears that I am mistaken. If it makes you feel any better, you can consider the PRNG the encryption of constant text, perhaps using the real datastream as some kind of IV. The content of the chaff is not relevant; ideally you would use a high-bandwidth HWRNG such as Quantis. -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: packet traffic analysis
I assume that the length is explicitly encoded in the legitimate packet. Then the peer for the link ignores everything until the next escape sequence introducing a legitimate packet. I should point out that encrypting PRNG output may be pointless, and perhaps one optimization is to stop encrypting when switching on the chaff. The peer can then encrypt the escape sequence as it would appear in the encrypted stream, and do a simple string match on that. In this manner the peer does not have to do any decryption until the [encrypted] escape sequence re-appears. Another benefit of this is to limit the amount of material encrypted under the key to legitimate traffic and the escape sequences prefixing them. Some minor details involving resynchronizing when the PRNG happens to produce the same output as the expected encrypted escape sequence is left as an exercise for the reader. -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: packet traffic analysis
Good catch on the encryption. I feel silly for not thinking of it. If your plaintext consists primarily of small packets, you should set the MTU of the transporter to be small. This will cause fragmentation of the large packets, which is the price you have to pay. Conversely, if your plaintext consists primarily of large packets, you should make the MTU large. This means that a lot of bandwidth will be wasted on padding if/when there are small packets (e.g. keystrokes, TCP acks, and voice cells) but that's the price you have to pay to thwart traffic analysis. I'm not so sure. If we're talking about thwarting traffic on the link level (real circuit) or on the virtual-circuit level, then you're adding, on average, a half-packet latency whenever you want to send a real packet. And then there's the bandwidth tradeoff you mention, which is probably of a larger concern (although bandwidth will increase over time, whereas the speed of light will not). I don't see any reason why it's necessary to pay these costs if you abandon the idea of generating only equal-length packets and creating all your chaff as packets. Let's assume the link is encrypted as before. Then you merely introduce your legitimate packets with a certain escape sequence, and pad between these packets with either zeroes, or if you're more paranoid, some kind of PRNG. In this way, if the link is idle, you can stop generating chaff and start generating packets at any time. I assume that the length is explicitly encoded in the legitimate packet. Then the peer for the link ignores everything until the next escape sequence introducing a legitimate packet. This is not a tiny hack, but avoids much of the overhead in your technique. It could easily be applied to something like openvpn, which can operate over a TCP virtual circuit, or ppp. It'd be a nice optimization if you could avoid retransmits of segments that contained only chaff, but that may or may not be possible to do without giving up some TA resistance (esp. in the presence of an attacker who may prevent transmission of segments). -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: packet traffic analysis
Good catch on the encryption. I feel silly for not thinking of it. If your plaintext consists primarily of small packets, you should set the MTU of the transporter to be small. This will cause fragmentation of the large packets, which is the price you have to pay. Conversely, if your plaintext consists primarily of large packets, you should make the MTU large. This means that a lot of bandwidth will be wasted on padding if/when there are small packets (e.g. keystrokes, TCP acks, and voice cells) but that's the price you have to pay to thwart traffic analysis. I'm not so sure. If we're talking about thwarting traffic on the link level (real circuit) or on the virtual-circuit level, then you're adding, on average, a half-packet latency whenever you want to send a real packet. And then there's the bandwidth tradeoff you mention, which is probably of a larger concern (although bandwidth will increase over time, whereas the speed of light will not). I don't see any reason why it's necessary to pay these costs if you abandon the idea of generating only equal-length packets and creating all your chaff as packets. Let's assume the link is encrypted as before. Then you merely introduce your legitimate packets with a certain escape sequence, and pad between these packets with either zeroes, or if you're more paranoid, some kind of PRNG. In this way, if the link is idle, you can stop generating chaff and start generating packets at any time. I assume that the length is explicitly encoded in the legitimate packet. Then the peer for the link ignores everything until the next escape sequence introducing a legitimate packet. This is not a tiny hack, but avoids much of the overhead in your technique. It could easily be applied to something like openvpn, which can operate over a TCP virtual circuit, or ppp. It'd be a nice optimization if you could avoid retransmits of segments that contained only chaff, but that may or may not be possible to do without giving up some TA resistance (esp. in the presence of an attacker who may prevent transmission of segments). -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: packet traffic analysis
I assume that the length is explicitly encoded in the legitimate packet. Then the peer for the link ignores everything until the next escape sequence introducing a legitimate packet. I should point out that encrypting PRNG output may be pointless, and perhaps one optimization is to stop encrypting when switching on the chaff. The peer can then encrypt the escape sequence as it would appear in the encrypted stream, and do a simple string match on that. In this manner the peer does not have to do any decryption until the [encrypted] escape sequence re-appears. Another benefit of this is to limit the amount of material encrypted under the key to legitimate traffic and the escape sequences prefixing them. Some minor details involving resynchronizing when the PRNG happens to produce the same output as the expected encrypted escape sequence is left as an exercise for the reader. -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: [PracticalSecurity] Anonymity - great technology but hardly used
Part of the problem is using a packet-switched network; if we had circuit-based, then thwarting traffic analysis is easy; you just fill the link with random garbage when not transmitting packets. I considered doing this with SLIP back before broadband (back when my friend was my ISP). There are two problems with this; one, getting enough random data, and two, distinguishing the padding from the real data in a computationally efficient manner on the remote side without giving away anything to someone analyzing your traffic. I guess both problems could be solved by using synchronized PRNGs on both ends to generate the chaff. The two sides getting desynchronzied would be problematic. Please CC me with any ideas you might have on doing something like this, perhaps it will become useful again one day. On packet-switched networks, running full speed all the time is not very efficient nor is it very friendly to your neighbors. Again, if you have any ideas on how to deal with this, email me. Many of the anonymity protocols require multiple participants, and thus are subject to what economists call network externalities. The best example I can think of is Microsoft Office file formats. I don't buy MS Office because it's the best software at creating documents, but I have to buy it because the person in HR insists on making our timecards in Excel format. In this case, the fact that the HR person (a third party to the transaction) is using it forces me to buy it from Microsoft. Similarly, the more people use digital cash, the more likely I am to decide to use it. The more Tor nodes we have, the more high speed and close nodes there will be, and the more enjoyable the experience will be (assuming Tor is smart enough to use the close, fast nodes). For more information on network externalities, see the book Information Rules, available from Amazon for just over $4. Everyone working in IT or interested in computers should read that book. Another issue involves the ease of use when switching between a [slower] anonymous service and a fast non-anonymous service. I have a tool called metaprox on my website (see URL in sig) that allows you to choose what proxies you use on a domain-by-domain basis. Something like this is essential if you want to be consistent about accessing certain sites only through an anonymous proxy. Short of that, perhaps a Firefox plug-in that allows you to select proxies with a single click would be useful. It would be nice if the protocols allowed you to specify a chain of proxies, but unfortunately HTTP only allows you to specify the next hop, not a chain of hops. Perhaps someone could come up with an encapsulation method and cooperative proxy server that is more like the old cpunk remailers, using nested encrypted envelopes in the body of the request. Perhaps crowds or Tor already does this, I don't know. Where anonymizing facilities fail are fairly obvious to anyone who has used them, listed in descending order of importance: ease of configuration (initial setup cost) ease of use locator services for peers or servers network effects (not enough people using it) efficient use of resources (see quote in sig about why this is the least important) There are some technical concerns limiting their security: resistance to traffic analysis or trojaned software ad-hoc systems for crypto key updates or revocation I think one way to encourage adoption is to amortize the cost of setup over a group of people. For example, everyone who reads this could set up a hardened co-loc box and install all the relevant software, then charge their friends a small fee to use it. An ISP could make these services available to their customers. An ASP could make them available to customers over the web. People could start creating open-source Live! CD distributions* with all the software clients installed and preconfigured (or configured easily through a wizard-like set of menus invoked automatically at bootup). With Live! CDs in particular, you'd have a bit of a problem with generating crypto keys since the RNG fires up in the same state for everyone, but perhaps you could seed it by hashing the contents of a disk drive, or the contents of memory-mapped hardware ROMs (e.g. ethernet MAC address), network traffic, and/or with seed state persisted on a removable USB drive. [*] See http://www.frozentech.com/content/livecd.php I don't see a distro specifically for anonymity; if you have friends who want to create Yet Another Linux Distro, perhaps they could fill this niche. Two alternatives suggest themselves; a client distro for end-users and a server distro for people with a machine that's not doing anything. You'd just pop in the CD and it announces its availability to various locator services to act as a Tor, mixmaster, or whatever node. Again, keep me informed if anyone starts work on this. -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. --
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
If you have to be that confident in your computer security to use the payment system, it's not going to have many clients. Maybe the trusted computing platform (palladium) may have something to offer after all, namely enabling naive users to use services that require confidence in their own security. One could argue it's like going to a Vegas casino; software vendors (MS *cough* MS) probably won't cheat you in such a system because they don't have to; the odds are in their favor already. The whole system is designed to assure they get paid, and they have a lot to lose (confidence in the platform) by cheating you (at least in ways that can be detected). And since you won't be able to do anything to compromise the security, you can't screw it up. While I wouldn't see an advantage in that, I might recommend it for my grandmother. More on topic, I recently heard about a scam involving differential reversibility between two remote payment systems. The fraudster sends you an email asking you to make a Western Union payment to a third party, and deposits the requested amount plus a bonus for you using paypal. The victim makes the irreversible payment using Western Union, and later finds out the credit card used to make the paypal payment was stolen when paypal reverses the transaction, leaving the victim short. -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: [PracticalSecurity] Anonymity - great technology but hardly used
Part of the problem is using a packet-switched network; if we had circuit-based, then thwarting traffic analysis is easy; you just fill the link with random garbage when not transmitting packets. I considered doing this with SLIP back before broadband (back when my friend was my ISP). There are two problems with this; one, getting enough random data, and two, distinguishing the padding from the real data in a computationally efficient manner on the remote side without giving away anything to someone analyzing your traffic. I guess both problems could be solved by using synchronized PRNGs on both ends to generate the chaff. The two sides getting desynchronzied would be problematic. Please CC me with any ideas you might have on doing something like this, perhaps it will become useful again one day. On packet-switched networks, running full speed all the time is not very efficient nor is it very friendly to your neighbors. Again, if you have any ideas on how to deal with this, email me. Many of the anonymity protocols require multiple participants, and thus are subject to what economists call network externalities. The best example I can think of is Microsoft Office file formats. I don't buy MS Office because it's the best software at creating documents, but I have to buy it because the person in HR insists on making our timecards in Excel format. In this case, the fact that the HR person (a third party to the transaction) is using it forces me to buy it from Microsoft. Similarly, the more people use digital cash, the more likely I am to decide to use it. The more Tor nodes we have, the more high speed and close nodes there will be, and the more enjoyable the experience will be (assuming Tor is smart enough to use the close, fast nodes). For more information on network externalities, see the book Information Rules, available from Amazon for just over $4. Everyone working in IT or interested in computers should read that book. Another issue involves the ease of use when switching between a [slower] anonymous service and a fast non-anonymous service. I have a tool called metaprox on my website (see URL in sig) that allows you to choose what proxies you use on a domain-by-domain basis. Something like this is essential if you want to be consistent about accessing certain sites only through an anonymous proxy. Short of that, perhaps a Firefox plug-in that allows you to select proxies with a single click would be useful. It would be nice if the protocols allowed you to specify a chain of proxies, but unfortunately HTTP only allows you to specify the next hop, not a chain of hops. Perhaps someone could come up with an encapsulation method and cooperative proxy server that is more like the old cpunk remailers, using nested encrypted envelopes in the body of the request. Perhaps crowds or Tor already does this, I don't know. Where anonymizing facilities fail are fairly obvious to anyone who has used them, listed in descending order of importance: ease of configuration (initial setup cost) ease of use locator services for peers or servers network effects (not enough people using it) efficient use of resources (see quote in sig about why this is the least important) There are some technical concerns limiting their security: resistance to traffic analysis or trojaned software ad-hoc systems for crypto key updates or revocation I think one way to encourage adoption is to amortize the cost of setup over a group of people. For example, everyone who reads this could set up a hardened co-loc box and install all the relevant software, then charge their friends a small fee to use it. An ISP could make these services available to their customers. An ASP could make them available to customers over the web. People could start creating open-source Live! CD distributions* with all the software clients installed and preconfigured (or configured easily through a wizard-like set of menus invoked automatically at bootup). With Live! CDs in particular, you'd have a bit of a problem with generating crypto keys since the RNG fires up in the same state for everyone, but perhaps you could seed it by hashing the contents of a disk drive, or the contents of memory-mapped hardware ROMs (e.g. ethernet MAC address), network traffic, and/or with seed state persisted on a removable USB drive. [*] See http://www.frozentech.com/content/livecd.php I don't see a distro specifically for anonymity; if you have friends who want to create Yet Another Linux Distro, perhaps they could fill this niche. Two alternatives suggest themselves; a client distro for end-users and a server distro for people with a machine that's not doing anything. You'd just pop in the CD and it announces its availability to various locator services to act as a Tor, mixmaster, or whatever node. Again, keep me informed if anyone starts work on this. -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. --
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
If you have to be that confident in your computer security to use the payment system, it's not going to have many clients. Maybe the trusted computing platform (palladium) may have something to offer after all, namely enabling naive users to use services that require confidence in their own security. One could argue it's like going to a Vegas casino; software vendors (MS *cough* MS) probably won't cheat you in such a system because they don't have to; the odds are in their favor already. The whole system is designed to assure they get paid, and they have a lot to lose (confidence in the platform) by cheating you (at least in ways that can be detected). And since you won't be able to do anything to compromise the security, you can't screw it up. While I wouldn't see an advantage in that, I might recommend it for my grandmother. More on topic, I recently heard about a scam involving differential reversibility between two remote payment systems. The fraudster sends you an email asking you to make a Western Union payment to a third party, and deposits the requested amount plus a bonus for you using paypal. The victim makes the irreversible payment using Western Union, and later finds out the credit card used to make the paypal payment was stolen when paypal reverses the transaction, leaving the victim short. -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: [EMAIL PROTECTED]: Skype security evaluation]
That's a fairly interesting review, and Skype should be commended for
hiring someone to do it. I hope to see more evaluations from vendors
in the future.
However, I have a couple of suggestions.
My understanding of the peer-to-peer key agreement protocol (hereafter
p2pka) is based on section 3.3 and 3.4.2 and is something like this:
A - B: N_ab
B - A: N_ba
B - A: Sign{f(N_ab)}_a
A - B: Sign{f(N_ba)}_b
A - B: Sign{A, K_a}_SKYPE
B - A: Sign{B, K_b}_SKYPE
A - B: Sign{R_a}_a
B - A: Sign{R_b}_b
Session key SK_AB = g(R_a, R_b)
0) The p2pka allows us to use a peer as a signing oracle for nonces by
performing steps 1 through 4. Only the one-wayness of f (specified
only as modified in a standard way) stands in the way of arbitrary
forgery, which would allow us to bypass the security on steps 3, 4, 7,
and 8. It would not stop us from knowing the session key, since there
is no restriction on the form of R_a or R_b.
1) It's not clear that the identity certificates are bound to a
[externally visible] network [source] address at registration time.
IMHO, this would be a good idea.
2) He implicitly ignores the fact that the skype key is a trusted CA,
so skype can impersonate anyone (or delegate that impersonation by
signing a bogus ID). This is obvious to a cryptographer but should be
mentioned for the layperson. An evaluation should explicitly specify
who must be trusted by whom, and everyone must trust the Skype
registrar.
3) It looks like the peer-to-peer communication involves the same key,
SK_AB, in both directions, opening the door for keystream re-use, but
there's 64 bits of presumably random salt so it shouldn't be very
common.
Vagueness:
1) They use an unencrypted 2-byte CRC on each packet between peers.
Undetected modification to a packet is possible, since the CRC is
computed over the encrypted data and stored en clair. In this case,
arbitrary bits can be flipped, the CRC recomputed, and no future
packets depend on the current packet, so there's no tell-tale garbling
afterwards like there is in most other block modes. He alludes to
this in section 3.4.4 but doesn't really specify the impact, merely
compares it to WEP.
2) The session established with the Skype server during registration
is protected with a 256-bit key, which is random, but he doesn't say
how the client and Skype agree on it.
3) It's not clear why they used rc4 instead of ICM to generate key
material, but at least it's not being used for confidentiality.
4) The details of the random number generation are vague (makes a
number of win32 calls).
5) The details of the SK_AB key composition are vague (combined in a
cryptographically-sound way), shown by g in the p2pka above.
6) It doesn't say who sends the nonces first --- is it the recipient
of the connection, or the initiator? Can we DoS people by repeated
connections triggering digital signatures?
7) It doesn't say whether it's a TCP or UDP protocol, what ports it
uses, etc. I'm curious if it will work through NAT at both ends.
8) The skype server's timeout on login passwords can be used for a
denial-of-service against the registration protocol and doesn't affect
username guessing (fixed password variable username, a/k/a reverse
hack).
9) It doesn't specify how the salts used in ICM mode are communicated.
10) It doesn't specify how streams are created and numbered.
It'd be nice to see the protocol clearly specified and analyzed via
automated means (finite state analysis via murphy, etc.).
Obsession with performance:
He makes no fewer than six comments about performance (of the AES
code, of the modular exponentiation, of the primality testing, of
modular inversion, of multi-precision arithmetic libraries, and SHA-1
implementation), which should normally be the least of anyone's
worries, especially cryptographers. Is this is a security evaluation,
or a performance test?
However, since we're talking about real-time audio streams, perhaps
some discussion of the bandwidth and especially latency of the p2p
protocol would be in order. Unfortunately, there's no quantification
(... performs favorably in terms of clock cycle per encryption).
Trust us:
Finally, the whole thing is closed source, so none of it is easily
verifiable. We just have to take his word on it, and often he just
offers opinions (see the complaints of vagueness above).
Summary:
All that having been said, I still have more confidence in Skype than
I did before reading the paper.
--
http://www.lightconsulting.com/~travis/ --
We already have enough fast, insecure systems. -- Schneier Ferguson
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: [EMAIL PROTECTED]: Skype security evaluation]
That's a fairly interesting review, and Skype should be commended for
hiring someone to do it. I hope to see more evaluations from vendors
in the future.
However, I have a couple of suggestions.
My understanding of the peer-to-peer key agreement protocol (hereafter
p2pka) is based on section 3.3 and 3.4.2 and is something like this:
A - B: N_ab
B - A: N_ba
B - A: Sign{f(N_ab)}_a
A - B: Sign{f(N_ba)}_b
A - B: Sign{A, K_a}_SKYPE
B - A: Sign{B, K_b}_SKYPE
A - B: Sign{R_a}_a
B - A: Sign{R_b}_b
Session key SK_AB = g(R_a, R_b)
0) The p2pka allows us to use a peer as a signing oracle for nonces by
performing steps 1 through 4. Only the one-wayness of f (specified
only as modified in a standard way) stands in the way of arbitrary
forgery, which would allow us to bypass the security on steps 3, 4, 7,
and 8. It would not stop us from knowing the session key, since there
is no restriction on the form of R_a or R_b.
1) It's not clear that the identity certificates are bound to a
[externally visible] network [source] address at registration time.
IMHO, this would be a good idea.
2) He implicitly ignores the fact that the skype key is a trusted CA,
so skype can impersonate anyone (or delegate that impersonation by
signing a bogus ID). This is obvious to a cryptographer but should be
mentioned for the layperson. An evaluation should explicitly specify
who must be trusted by whom, and everyone must trust the Skype
registrar.
3) It looks like the peer-to-peer communication involves the same key,
SK_AB, in both directions, opening the door for keystream re-use, but
there's 64 bits of presumably random salt so it shouldn't be very
common.
Vagueness:
1) They use an unencrypted 2-byte CRC on each packet between peers.
Undetected modification to a packet is possible, since the CRC is
computed over the encrypted data and stored en clair. In this case,
arbitrary bits can be flipped, the CRC recomputed, and no future
packets depend on the current packet, so there's no tell-tale garbling
afterwards like there is in most other block modes. He alludes to
this in section 3.4.4 but doesn't really specify the impact, merely
compares it to WEP.
2) The session established with the Skype server during registration
is protected with a 256-bit key, which is random, but he doesn't say
how the client and Skype agree on it.
3) It's not clear why they used rc4 instead of ICM to generate key
material, but at least it's not being used for confidentiality.
4) The details of the random number generation are vague (makes a
number of win32 calls).
5) The details of the SK_AB key composition are vague (combined in a
cryptographically-sound way), shown by g in the p2pka above.
6) It doesn't say who sends the nonces first --- is it the recipient
of the connection, or the initiator? Can we DoS people by repeated
connections triggering digital signatures?
7) It doesn't say whether it's a TCP or UDP protocol, what ports it
uses, etc. I'm curious if it will work through NAT at both ends.
8) The skype server's timeout on login passwords can be used for a
denial-of-service against the registration protocol and doesn't affect
username guessing (fixed password variable username, a/k/a reverse
hack).
9) It doesn't specify how the salts used in ICM mode are communicated.
10) It doesn't specify how streams are created and numbered.
It'd be nice to see the protocol clearly specified and analyzed via
automated means (finite state analysis via murphy, etc.).
Obsession with performance:
He makes no fewer than six comments about performance (of the AES
code, of the modular exponentiation, of the primality testing, of
modular inversion, of multi-precision arithmetic libraries, and SHA-1
implementation), which should normally be the least of anyone's
worries, especially cryptographers. Is this is a security evaluation,
or a performance test?
However, since we're talking about real-time audio streams, perhaps
some discussion of the bandwidth and especially latency of the p2p
protocol would be in order. Unfortunately, there's no quantification
(... performs favorably in terms of clock cycle per encryption).
Trust us:
Finally, the whole thing is closed source, so none of it is easily
verifiable. We just have to take his word on it, and often he just
offers opinions (see the complaints of vagueness above).
Summary:
All that having been said, I still have more confidence in Skype than
I did before reading the paper.
--
http://www.lightconsulting.com/~travis/ --
We already have enough fast, insecure systems. -- Schneier Ferguson
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
