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] > >
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
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.
RE: [EMAIL PROTECTED]: Skype security evaluation]
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? No ,Skype use RSA encryption: "Each party contributes 128 random bits toward the 256-bit session key. The contributions are exchanged as RSA cryptograms. The two contributions are then combined in a cryptographically-sound way to form the shared session key." I. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of cyphrpunk Sent: Monday, October 24, 2005 8:51 PM To: Travis H. Cc: [EMAIL PROTECTED]; cryptography@metzdowd.com; [EMAIL PROTECTED] Subject: 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] - This e-mail is intended for the addressee(s) named above. It may contain confidential information, and any unauthorised disclosure, use or dissemination, either in whole or in part, is prohibited. If you have received this e-mail in error, please notify the sender immediately via e-mail and delete this e-mail from your system. Communications by e-mail are not subject to the same verification procedures as paper-based communications, therefore this e-mail is in no way whatsoever binding on the Bank of Latvia.
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
[EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Skype security evaluation]]
- Forwarded message from Damien Miller <[EMAIL PROTECTED]> - From: Damien Miller <[EMAIL PROTECTED]> Date: Mon, 24 Oct 2005 12:39:42 +1000 (EST) To: cryptography@metzdowd.com Cc: [EMAIL PROTECTED] Subject: 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] - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
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]
- 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