RE: [EMAIL PROTECTED]: Skype security evaluation]
Do you have some articles about these protocols? The authoritative reference for TLS is the TLS RFC (http://www.ietf.org/rfc/rfc2246.txt). The authoritative reference for IPsec is of course the IPsec RFC (http://www.ietf.org/rfc/rfc2401.txt). As to why they wouldn't use these as they stand, synchronized protocols often require finer control over the data block size than these offer, but modification is easy enough, and would certainly have caused fewer concerns than a roll your own. [Marcel] Thanks, and appreciated, but I haven't made myself clear. I meant: is there a page by one of the known names in the field saying something like: if you want to do this, then you should use these protocols? Like Peter said: they should have used TLS or YASSL for the handshake and IPSEC + ESP for the transport. Is there a place where one trying to implement a secure system could go and find out the basic components he needs? With pros and cons, preferably? [Marcel] Maybe this is too much to ask, I don't know. That's pretty much the point :) Thanks, Marcel - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: [EMAIL PROTECTED]: Skype security evaluation]
Marcel Popescu [EMAIL PROTECTED] writes: From: [EMAIL PROTECTED] [mailto:owner- [EMAIL PROTECTED] On Behalf Of Peter Gutmann I can't understand why they didn't just use TLS for the handshake (maybe YASSL) and IPsec sliding-window + ESP for the transport (there's a free minimal implementation of this whose name escapes me for use by people who want to avoid the IKE nightmare). Established, proven protocols and implementations are there for the taking, but instead they had to go out and try and assemble something with their own three hands (sigh). Do you have some articles about these protocols? I can't find anything on your webpage, and a newbie (like myself) can't distinguish between well designed and badly designed protocols. Can you recommend such a collection of well designed protocols for various purposes? With implementation caveats if possible? Well, the above text mentions the recommended protocols. You can get YASSL from http://yassl.com, and the IPsec ESP implementation from http://ringstrom.mine.nu/ipsec_tunnel/ (although it looks like it hasn't been updated for awhile, Freshmeat, http://osx.freshmeat.net/projects/ipsec_tunnel/, seems to have newer info). My article on problems I found in homebrew VPN implementations is at http://www.linux-magazine.com/issue/39. If you want to save yourself the effort of building your own TLS + ESP combination, you can use OpenVPN, http://openvpn.net/ (and if you've ever had to struggle with IPsec, you should also consider OpenVPN - unlike IPsec, you can just point it at your target system and that's it, you don't have to start a new career in network and server reconfiguration :-). (actually To be precise OpenVPN doesn't use the ESP format directly (which is rather IPsec-specific), only the general protocol design: OpenVPN's security model can be summarized as such: Use the IPSec ESP protocol for tunnel packet security, but then drop IKE in favor of SSL/TLS for session authentication. This allows for a lightweight, portable VPN implementation that draws on IPSec's strengths, without introducing the complexity of IKE. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Skype security evaluation]
On 10/31/05, Kuehn, Ulrich [EMAIL PROTECTED] wrote: There are results available on this issue: First, a paper by Boneh, Joux, and Nguyen Why Textbook ElGamal and RSA Encryption are Insecure, showing that you can essentially half the number of bits in the message, i.e. in this case the symmetric key transmitted. Thanks for this pointer. In the case of Skype it would be consistent with the security report if they are encrypting random 128 bit values under each other's RSA keys, unpadded, and exchanging them, then hashing the pair of 128 bit values together to generate their session keys. The paper above shows an easy birthday attack on such encryptions. Approximately 18% of 128 bit numbers can be expressed as a product of two 64-bit numbers. For such keys, if the ciphertext is C, consider all 2^64 values m1 and m2, and compare m1^e with C/m2^e. This can be done in about 2^64 time and memory, and if the plaintext is in that 18%, it will be found as m1*m2. Based on these comments and others that have been made in this thread, the Skype security analysis seems to have major flaws. We have a reluctance in our community to criticize the work of our older members, especially those like Berson who have warm personalities and friendly smiles. But in this case the report leaves so much unanswered, and focuses inappropriately on trivial details like performance and test vectors, that overall it can only be called an entirely unsatisfactory piece of work. CP - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: [EMAIL PROTECTED]: Skype security evaluation]
From: [EMAIL PROTECTED] [mailto:owner- [EMAIL PROTECTED] On Behalf Of Peter Gutmann I can't understand why they didn't just use TLS for the handshake (maybe YASSL) and IPsec sliding-window + ESP for the transport (there's a free minimal implementation of this whose name escapes me for use by people who want to avoid the IKE nightmare). Established, proven protocols and implementations are there for the taking, but instead they had to go out and try and assemble something with their own three hands (sigh). Do you have some articles about these protocols? I can't find anything on your webpage, and a newbie (like myself) can't distinguish between well designed and badly designed protocols. Can you recommend such a collection of well designed protocols for various purposes? With implementation caveats if possible? (I haven't looked at it in a long time - is Handbook of Applied Cryptography a good reference for this?) Thanks, Marcel -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.7/155 - Release Date: 11/1/2005 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Skype security evaluation]
Jack Lloyd [EMAIL PROTECTED] writes: I just reread those sections and I still don't see anything about RSA encryption padding either. 3.2.2 just has some useless factoids about the RSA implementation (but neglects to mention important implementation points, like if blinding is used, or if signatures are verified before being released). 3.2.3 describes the signature padding, but makes no mention of the encryption padding, or even that a padding method is used for encryption. This would match my experience with homebrew VPN protocols when I looked at a pile of OSS VPN implementations a year or so back. Evrey single one of them had flaws (some quite serious) not in getting the basic crypto right, but in the way that the crypto was used. I don't see any reason why Skype should break this mould. I can't understand why they didn't just use TLS for the handshake (maybe YASSL) and IPsec sliding-window + ESP for the transport (there's a free minimal implementation of this whose name escapes me for use by people who want to avoid the IKE nightmare). Established, proven protocols and implementations are there for the taking, but instead they had to go out and try and assemble something with their own three hands (sigh). (Having said that, I don't consider it a big deal. I've always treated Skype as a neat way of doing VoIP rather than a super-secure encrypted comms link. The security (for whatever it's worth) is just icing on the basic Skype service - I'd use it with or without encryption. The killer app is the cheap phonecalls, not the crypto). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: [EMAIL PROTECTED]: Skype security evaluation]
A similar approach enabled Bleichenbacher's SSL attack on RSA with PKCS#1 padding. This sounds very dangerous to me. William -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of cyphrpunk Sent: Friday, October 28, 2005 5:07 AM To: [EMAIL PROTECTED]; cryptography@metzdowd.com Subject: Re: [EMAIL PROTECTED]: Skype security evaluation] Wasn't there a rumor last year that Skype didn't do any encryption padding, it just did a straight exponentiation of the plaintext? Would that be safe, if as the report suggests, the data being encrypted is 128 random bits (and assuming the encryption exponent is considerably bigger than 3)? Seems like it's probably OK. A bit risky perhaps to ride bareback like that but I don't see anything inherently fatal. CP - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
AW: [EMAIL PROTECTED]: Skype security evaluation]
-Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von cyphrpunk Gesendet: Freitag, 28. Oktober 2005 06:07 An: [EMAIL PROTECTED]; cryptography@metzdowd.com Betreff: Re: [EMAIL PROTECTED]: Skype security evaluation] Wasn't there a rumor last year that Skype didn't do any encryption padding, it just did a straight exponentiation of the plaintext? Would that be safe, if as the report suggests, the data being encrypted is 128 random bits (and assuming the encryption exponent is considerably bigger than 3)? Seems like it's probably OK. A bit risky perhaps to ride bareback like that but I don't see anything inherently fatal. There are results available on this issue: First, a paper by Boneh, Joux, and Nguyen Why Textbook ElGamal and RSA Encryption are Insecure, showing that you can essentially half the number of bits in the message, i.e. in this case the symmetric key transmitted. Second, it turns out that the tricky part is the implementation of the decryption side, where the straight-forward way -- ignoring the padding with 0s They are zeroes, aren't they? -- gives you a system that might be attacked in a chosen plaintext scenario very efficiently, obtaining the symmetric key. See my paper Side-Channel Attacks on Textbook RSA and ElGamal Encryption at PKC2003 for details. Hope this answers your question. Ulrich - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Skype security evaluation]
On Mon, 24 Oct 2005, cyphrpunk wrote: Is it possible that Skype doesn't use RSA encryption? Or if they do, do they do it without using any padding, and is that safe? You may want to read the report itself: http://www.skype.com/security/files/2005-031%20security%20evaluation.pdf and perhaps section 3.2.3 (about padding) and 3.2.2 (about how RSA is used) may help with this (and what it is used for in section 2). Dw. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Skype security evaluation]
On Wed, Oct 26, 2005 at 07:47:22AM -0700, Dirk-Willem van Gulik wrote: On Mon, 24 Oct 2005, cyphrpunk wrote: Is it possible that Skype doesn't use RSA encryption? Or if they do, do they do it without using any padding, and is that safe? You may want to read the report itself: http://www.skype.com/security/files/2005-031%20security%20evaluation.pdf and perhaps section 3.2.3 (about padding) and 3.2.2 (about how RSA is used) may help with this (and what it is used for in section 2). I just reread those sections and I still don't see anything about RSA encryption padding either. 3.2.2 just has some useless factoids about the RSA implementation (but neglects to mention important implementation points, like if blinding is used, or if signatures are verified before being released). 3.2.3 describes the signature padding, but makes no mention of the encryption padding, or even that a padding method is used for encryption. Jack - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Skype security evaluation]
On 10/23/05, Travis H. [EMAIL PROTECTED] wrote:
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)
But what you have shown here has no encryption, hence no secrecy.
Surely RSA encryption must be used somewhere along the line. The
report doesn't say anything about the details of how that is done. In
particular, although it mentions RSA signature padding it says nothing
about RSA encryption padding.
Is it possible that Skype doesn't use RSA encryption? Or if they do,
do they do it without using any padding, and is that safe?
CP
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Skype security evaluation]
On Sun, 23 Oct 2005, Joseph Ashwood wrote: - Original Message - Subject: [Tom Berson Skype Security Evaluation] Tom Berson's conclusion is incorrect. One needs only to take a look at the publicly available information. I couldn't find an immediate reference directly from the Skype website, but it uses 1024-bit RSA keys, the coverage of breaking of 1024-bit RSA has been substantial. The end, the security is flawed. Of course I told them this now years ago, when I told them that 1024-bit RSA should be retired in favor of larger keys, and several other people as well told them. More worrying is the disconnect between the front page summary and the body of the review. If one only reads the summary, then one would only see the gushing praise and not the SSH protocol 1-esque use of a weak CRC as a integrity mechanism (section 3.4.4) or what sounds suspiciously like a exploitable signed vs. unsigned issue in protocol parsing (section 3.4.6). Also disappointing is the focus on the correct implementation of cryptographic primitives (why not just use tested commercial or open-source implementations?) to the exclusion of other more interesting questions (at least to me): - What properties does the proprietary key agreement protocol offer (it sounds a bit like an attenuated version of the SSH-1 KEX protocol and, in particular, doesn't appear to offer PFS). - Does the use of RC4 follow Mantin's recommendations to discard the early, correlated keystream? - How does the use of RC4 to generate RSA keys work when only 64 bits of entropy are collected from Skype's RNG? (Section 3.1) - Why does Skype roll its own entropy collection functions instead of using the platform's standard one? - Ditto the use of standard protocols? (DTLS would seem an especially obvious choice). - What techniques (such as privilege dropping or separation) does Skype use to limit the scope of a network compromise of a Skype client? -d - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
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
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Skype security evaluation]
- Original Message - Subject: [Tom Berson Skype Security Evaluation] Tom Berson's conclusion is incorrect. One needs only to take a look at the publicly available information. I couldn't find an immediate reference directly from the Skype website, but it uses 1024-bit RSA keys, the coverage of breaking of 1024-bit RSA has been substantial. The end, the security is flawed. Of course I told them this now years ago, when I told them that 1024-bit RSA should be retired in favor of larger keys, and several other people as well told them. Joe - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
