# Tag Info

11

By George, you're on to something. To answer the question you asked, I don't know of anyone actually attempting to recover a password this way, or it even being discussed. However, it does appear to be feasible, given enough encrypted streams. How many are enough? Well, I've started running a few simulations; preliminary results indicate that with ...

9

The server doesn't sign the data itself. It only signs part of the handshake if you're using a signing based suite. That means you can prove to a third party that a handshake with a certain server happened, and what data was exchanged in that handshake. If you're using a RSA encryption suite, it doesn't even sign the handshake, but authenticates indirectly ...

9

The reason why you see that is because Camellia is the highest-preference cipher in NSS (Chrome and Firefox). Servers that support Camellia and use the client-preferred cipher suite will use Camellia. NSS's rationale for this ordering is: National ciphers such as Camellia are listed before international ciphers such as AES and RC4 to allow servers ...

8

To complete what @CodesInChaos explains: If the server has a RSA key in a certificate which is suitable for encryption, then anybody can forge a completely fake conversation without the server being involved at all. In the SSL/TLS protocol, when using a "RSA" cipher suite, the client generates the random "pre-master secret" which it then encrypts with the ...

6

There are several effects coming into play. But the most important property is that with increasing keylengths, the attacker's work becomes exponentially expensive, whereas the defenders work only becomes a bit more expensive. Looking at the different kinds of cryptography in use: Symmetric cryptography Originally we used DES and 3DES. DES had a ...

5

TLS not only provides privacy, but also authentication: You can be sure you know who you speak to (at least the client knows if the server was using a certificate). (You provide this by the "HTTPS key exchange" you are doing at the start.) You can be sure that you speak to the same entity at the other side throughout the whole live of your connection (even ...

5

I know of two standard protocols that support AES encryption without public key cryptography getting involved: With TLS, we have RFC4279, and in particular, the ciphersuite TLS_PSK_WITH_AES_128_CBC_SHA. Now, the two sides don't literally have preconfigured AES keys; instead, they have preshared premaster secrets; the AES (and HMAC-SHA1) keys are derived ...

5

Assuming that the keys used for the SSL and SSTP layers are independent (which they should be, since both layers have their own separate key setup processes), compromising the outer layer (SSTP) cannot make the inner layer (SSL) any less secure than it would be if used alone. To see why this is, imagine that there was an attack that did allow breaking SSL + ...

4

CRAM-MD5 is a protocol to demonstrate knowledge of a password. In the context of email, it is sometime used by an email client to authenticate to a POP, IMAP, or/and SMTP server. Basically, the password is used as the key of HMAC-MD5 in a challenge-response protocol. Among positive things there are to say about CRAM-MD5: The password is not exchanged in ...

4

If all the components share the same certificate, then they share the same private key. This raises the two following points: When a secret is shared by more than two people, can it still be considered really secret ? Secrecy dilutes fairly fast. If all components share the same secret value, then breakage of any single component reveals the private keys ...

4

Only two people can communicate with each other with the chat program. No group conversations. This is fairly limited, but let's admit. The people will be communicating over the internet. So, an insecure channel. OK. The chat program will just handle basic characters, numbers and symbols that are on a standard US keyboard. This is to keep ...

3

It sounds like you are conflating the strength of SSL and the strength of encryption. The two are distinct; SSL is a protocol that uses encryption, but the security of SSL is not strictly dependent on encryption. SSL can be vulnerable even when the underlying encryption is not. Overall, security and speed for SSL are not a tit-for-tat trade-off. Making SSL ...

3

Well, whether it would be safe to use the same keys to encrypt and to decrypt depends a great deal on the ciphersuite. In particular, TLS supports ciphersuites where it would cause a serious security problem; hence TLS was designed to have different keys in two directions (so that it could use those ciphersuites safely). In particular, the RC4 encryption ...

3

Currently, your protocol has a fatal design flaw by only considering an attacker who could manipulate the communication. You mentioned the two security properties confidentiality and integrity and you implicitly expect some kind of deniability by using a OTP and its properties. But your protocol ensures no entity authentication or perfect forward secrecy so ...

3

This is, as you guessed, an incorrectly encoded key. I suspect that OpenSSL ASN.1 decoder is written to assume that the modulus (and other parameters) is always positive, and so interprets them as if they were (that is, interprets them as if the leading 00 byte was there); hence it just happens to work. Now, what do you do about it? Well, if it's ...

3

I don't know of any practical attacks along these lines that pose a realistic threat in practice, on any current protocol. Let me explain. There are two standard kinds of distinguishing attacks on RC4: The first two bytes. Mantin and Shamir showed that the second byte of output from RC4 is biased. If the password was always encrypted at the very start ...

3

Well, no, there's no defined TLS ciphersuite that does the RC4 algorithm with a discard of the original stream. I'm not a designer of TLS, nor am I a member of the IETF working group that controls it; I suspect that they'd prefer for people to transition to ciphersuites that use AES (or some other newer cipher), and so there's little incentive for them to ...

2

So the question I have is on a SSTP Connection is the MSChapv2 handshake encrypted pre SSL setup or post. Post is the answer. Specifically, SSTP is basically SSL, with special body specific to a tunnelling protocol. You can read the full spec here, but it's a little dry. Essentially, your options are these: Authenticate through SSL/TLS certificates as ...

2

I would say the real standard here for TCP is TLS with a PSK ciphersuite. Given you have AES-128 in hardware and PK is not an option, you probably would want the TLS_PSK_WITH_AES_128_CBC_SHA ciphersuite (there are additional options which can use certificates for authentication or DH for forward security with AES but seems like these are non-starters). ...

2

I'd like to add to Ilmari's answer. Specifically, Ilmari said: compromising the outer layer (SSTP) cannot make the inner layer (SSL) any less secure than it would be if used alone. which is exactly right - however, if the SSTP tunnel has been broken through whatever means the attacker can still pull off any attacks on your key distribution that may be ...

2

To answer your specific questions: From reading around I understand that ... encrypting a counter and use that as the IV is OK, is that true? For CBC mode, that is absolutely true, as long as the key that you use to encrypt the counter is secret (that is, not known to any possible adversary). Should I start in random number? Actually, that's ...

2

Well, that would work, but identification is not enough for SSL. You would need to make the PKE scheme one-way against CCA1 attacks. $\:$ (On the other hand, it wouldn't need any semantic security.) $\:$ Sending back H(S') would change the required security notion to one that's even farther from what's been studied. You could use a tag-based PKE scheme ...

1

Have you considered generating the IV in a cryptographically pseudorandom way? This approach makes it easiest to be sure that you're not introducing some subtle weakness in your IV selection. I would start by benchmarking how fast it is to use RandomNumberGenerator. If that's fast enough, job done. I would not give up on that idea until you know that it ...

1

By non-standard do you mean when to use custom curves? Like in crypto++ where you can specify your own parameters? Given that the standards recommend certain sets of domain parameters (and interesting enough US government departments are forbidden from using their own parameters) it's sounds like the answer is no, for reasons of avoiding the risks of self ...

1

1. Was I right? Pretty much. I want to add something to help clarify though: The Verisign public key in his store is of the Verisign CA (It is also stored in the form of a certificate). Also I think this process would qualify at decryption, no? 2. Verisign creates the digital signature over my certificate data. Which data? I'm not really sure what you ...

1

As for the conspiracy theory issue. You should consider that the NSA deemed AES fit to protect National Security Systems and National Security Information. http://www.nsa.gov/ia/programs/suiteb_cryptography/ No one knows if AES will ever be broken apart from the people who actually broke it already so either the NSA believes AES is secure or they know it's ...

1

Got news: http://en.wikipedia.org/wiki/Transport_Layer_Security#RC4_attack It's not very practical yet (at least 224 ciphertexts), but attacks can only get better, not worse. Remember how it was with WEP cracking.

Only top voted, non community-wiki answers of a minimum length are eligible