how chat autentification works ?

Discussion in 'Other Ghost Security Software' started by gkweb, Dec 3, 2003.

Thread Status:
Not open for further replies.
  1. gkweb
    Offline

    gkweb Expert Firewall Tester

    Hi,

    i yet don't had the possibility to test the chat feature because in the free version you can't host a server (so i wasn't able to ask a friend to host), so i wasn't able to check what i wanted to see.

    I'm well aware of possibility of "man in the middle attack" (MITMA), which is extremely difficult in the Internet but sadly easy in university networks.

    It's said in the helpfile that to 100% prevent MITMA you need a password to connect to the server.
    Can i now how ?

    C
    A -------------------------- (MITMA) ------------------------ B


    B want to talk to A.

    In a classic MITMA, B talks to C who reply to B who believes it's from A (so he has now a secret key with B).
    Then C start a connection with A spoofing B identities (he has now a different secret key with A).
    For each data coming to C, C use one secret key to decrypt, log the clear data, and encrypt it with the other key which it is sharing with the other.

    What protection offers a password ?

    If B sends a clear password, C reply "OK" to B, and in the meantime start a new connection with A using the same pasword.
    If B sends a "hash" (a SHA-512 digest for instance of the password), same thing, C can then send the hash too.

    now, RSA come in.
    From the official website :

    So even with RSA encryption, MITMA is still possible, the only way with RSA is the digital signature, but i still don't know for what the CS password is used.



    CS seems so to use hash of the password, but how the autentification protocol works to ensure MITMA isn't possible ?

    Thanks in advance for your answer :)
  2. Jason_R0
    Offline

    Jason_R0 Developer

    Yes authentication is an interesting subject. The shared passphrase is never sent to the server or client. Basically what happens for each packet sent is :-

    1) HASH the passphrase (SHA256)
    2) HASH the message+IV (SHA256)
    3) Generate 2 Hashes of the above hashes combined (SHA256+HAVAL256)
    4) Xor the 2 hashes to get a "Message Authentication Code"

    Now unless the person who is trying to perform a man in the middle attack has the passphrase they cannot generate a VALID "Message Authentication Code" and hence cannot change any message sent from either the client or server. Since the client and server KNOW the password they can always generate a valid MAC for any message, and can also verify every message to make sure the MAC is valid.

    The only time a man in the middle attack can occur is when the keys are exchanged, and basically the attacker creates his own sets of keys and gives them to the client and server instead. You are right, it is extremely difficult to set up attacks like these on networks like the internet.

    Since the MITMA can only occur during the very first stages of CryptoSuite's authentication process which on average would take around 1 second, your passphrase does not need to be THAT secure, it only needs to be good enough to stop the attacker from bruteforcing it in that early window he has to do this. Of course he could delay the packets if so desired, but if it took 5 minutes to connect I think you would realize something wrong is happening and use a bigger passphrase or switch to a secure network :) . To be safe using a passphrase of more than 18 characters should be sufficient, especially if you want to re-use it. Otherwise the attacker could spend all his time bruteforcing it just waiting for the next time you connect with the same password.

    If a invalid MAC is detected by CryptoSuite it immediately disconnects that client.

    I hope this helps with your understanding. If you have any more questions feel free to ask them. :)

    -Jason-
  3. gkweb
    Offline

    gkweb Expert Firewall Tester

    ok, this MAC feature is very interesting !

    In this way, the MITM can never spoof any message since he can't create a valid MAC, so he can't do anything while key exchange with RSA, so at the end, only A and B have a secret key to start the encrypted chat, bye bye MITM.

    good job.

    I haven't more question :)

    EDIT : i miss your old avatar Ryu :'(
  4. Justin Troutman
    Offline

    Justin Troutman Cryptography Expert

    Are you sure you're doing HMAC right?

    Is this what you're calling HMAC? It doesn't look like it to me. HMAC is defined by:

    HMAC.png

    Is this what you're really doing? If so, then you're using HMAC. Otherwise, it's something else. HMAC is a specific function; it's not just a generic term for using a hash function in a MAC function.

    Also, I would avoid combining hash functions as you do. When you do, you have to make extra assumptions about the hash functions not being related to each other, which isn't the case here. In both SHA and HAVAL, you're turning a block cipher into a hash function, in the Davies-Meyer feedforward construction; it follows that both of their compression functions are source-heavy, heterogenous UFNs (Unbalanced Feistel Networks). I can't think of any convincing argument in favor of combining them, over, say, using HMAC-SHA-256 by itself; it certainly makes it easier to analyze the system, as a whole, under notions of indistinguishability (e.g., IND-CCA2), nonmalleability (e.g., NM-CCA2), and integrity (e.g., INT-CTXT).

    For the chat feature of your software, here's something that makes more sense. You're already using the AES, so recycle it for your MAC. Drop Twofish. Encrypt with AES-CTR, then compute a tag on the ciphertext using CMAC-AES. CTR mode is IND-CPA secure and CMAC-AES is a SUF-CMA MAC; therefore, in the Encrypt-then-Authenticate composition, this gives you IND-CCA2 /\ INT-CTXT security. It's easier to analyze and easier to implement; that is, it's much better than what you're doing now, which seems more ad hoc, than anything. Be careful when trying to be conservative. It's not about adding more to achieve more; it's about achieving a lot with a little.

    Don't worry about the cryptography; it will do its job. Worry about the implementation; it's the one thing that often keeps it from doing its job. (More of my concerns regarding CryptoSuite are outlined here, including a more detailed look at the Encrypt-then-Authenticate composition for authenticated encryption schemes.)

    (Edit: I just noticed that you've responded to the post that I link to.)
    Last edited: Dec 27, 2007
  5. Jason_R0
    Offline

    Jason_R0 Developer

    Re: Are you sure you're doing HMAC right?

    You are right, I probably shouldn't be using the term HMAC to describe what I am doing as it is slightly misleading, though for all intents and purposes it's rather similar. Can you see any weaknesses in what I am doing at the moment? I can't see how it could be changed without the server knowing, provided the hash functions aren't broken.

    Yes I understand there is some risk in combining them, though there are some possible benefits. If one of the hashes is broken then you are possibly covered long enough for something to be done about it. Weigh that up with the risk of using one alone, plus how much research is done into hash cascades compared to stand alone?

    Define "much better"? You can't exactly put a number on it can you.. :) Sure it's a bit adhoc, but that can also be a benefit. Using secure cryptographic functions in a way which hasn't been broken or shown to be insecure isn't that bad in my opinion. I can certainly understand where you are coming from, the whole "unknown" aspect with using things in a slightly non standard way, but that is what I prefer.
  6. Justin Troutman
    Offline

    Justin Troutman Cryptography Expert

    Avoid ad hoc guesswork in security.

    Well, at a glance, you're not using a keyed function; it's not a MAC. All of your operations include an unkeyed hash function. Simply hashing a passphrase isn't a keyed function; if the adversary wants to change anything, he simply recomputes the hash on the modification. It doesn't matter what you hash; it's still unkeyed. Forgeries are easy. To provide security against active attacks, you need to use a keyed function, of which a MAC is. Without the key, it becomes hard for an adversary to produce a forgery; that is, the probability of a successful existential forgery under a chosen-message attack is negligible.

    Your function is unkeyed; HMAC is keyed. HMAC is a PRF is the underlying compression function is a PRF. Futhermore, a good PRF is a good MAC. Your function doesn't inherent this proof. It might appear to be similar to HMAC, but it's drastically different. To call it HMAC is incorrect and confusing, and I can assure you that most any cryptographer would come down hard on you for this; take this as a friendly warning! It's better not to use the name HMAC for your construction; it's even better to use HMAC instead of your construction.

    In this thread, I establish the position that the odds of making an implementation are a stack of magnitudes greater than that of a practical attack surfacing on a secure cryptographic primitive. The same applies here. In cryptography, designs should be as easy to analyze as possible; this makes it easier to evaluate its security claims. Cryptographic implementation should follow suit. Practice suggests that the real risk is making an implementation mistake - not succumbing to a practical attack on a cryptographic primitive.

    Be careful. There's a big difference between not being proven to be insecure and being proven to be secure. The latter is much more valuable than the former, which is what your ad hoc approach is. This sets the stage for what I mean by "much better." It's better to use primitives in the way that they're designed; after all, you inherit the associated formal security proofs. Why risk doing something different based on an ad hoc assumption that can't be quantified? Which makes more sense to production software? A developer's preference or a cryptographer's judgment? Sure, a cryptographer can be wrong, but they're also more likely to be right.

    As far as why my recommendation is much better, the security of CMAC and HMAC comes down to the security of their underlying primitives, and I feel a lot better about the structure of the AES than I do that of SHA and HAVAL, given the semi-recent cryptanalysis against hash functions of their structure. Furthermore, in general purpose schemes, like yours, you want IND-CCA2 /\ INT-CTXT secure.

    My approach of AES-CTR-then-CMAC-AES, in the Encrypt-then-Authenticate composition, is IND-CCA2 /\ INT-CTXT secure; your scheme isn't. My approach makes better engineering sense, because it recycles the AES for both encryption and authentication; your scheme uses four different primitives to do what I do with one, which demonstrates that mine is much easier to implement and analyze.

    In summary, cryptographically speaking, my approach is easier to implement, analyze, and provably secure under the strongest notions of confidentiality and integrity that we have, for authenticated encryption. Performance-wise, it's much faster and more efficient. Why bother with an ad hoc approach that sacrifices all of this for unsupported and unquantifiable guesswork?
  7. Jason_R0
    Offline

    Jason_R0 Developer

    Re: Avoid ad hoc guesswork in security.

    Well look at it from this perspective.

    [256bits][256bits]
    [PASSPHRASE HASHED][MESSAGE HASH]

    So from that 512bits of data two hashes are generated and xored into 256bits and that is what is used to verify the message. Now unless the passphrase is known, or the hash of the passphrase is known (which is never sent) I'm not sure how the attacker would have a means to generate a valid code.

    There are other programs out there which use stock standard approaches to cryptography, so if that's what people want they can get it. My personal opinion is that we are already supporting in some manner guess work just by relying on these ciphers in the first place. As you know, you can't guarantee a cipher will not be broken. Sure, people may say that something which isn't targeted for attack 24/7 *may* be weaker, but they will never know until it is. My point is until you *can* say it is insecure or weak, with a number to prove it (like it takes X cycles to break/brute it compared to product Z which takes Y cycles), then it's really as secure as the next standard solution which uses the same crypto functions.

    The way CryptoSuite encrypts archives with cascading, etc, isn't inherently insecure, as long as the implementation is error free it's secure (at this point in time given publicly available information </disclaimer> :) ).
  8. Justin Troutman
    Offline

    Justin Troutman Cryptography Expert

    Why not just use a real MAC?

    Let's get this straight. First, you hash the passphrase. Second, you hash the message and IV. Third, you concatenate these two hashes, then compute separate SHA-256 and HAVAL-256 hashes on the concatenation. Fourth, you XOR these two hashes. Are you XOR'ing an SHA-256 hash with a HAVAL-256 hash, or what? I'm a bit confused about what you mean by "3) Generate 2 Hashes of the above hashes combined (SHA256+HAVAL256)." I'll keep going though, assuming this is right. Please correct this if it's wrong!

    On the generic side of things, if you're doing something like SHA-256(m,mlen,x), you're going to run into length extension attacks. One can easily compute SHA-256(m,mlen,x) from SHA-256(m),mlen,x. You could hash twice to avoid this, but that's beside the point. Specific to your approach, it's not good that the hash of the passphrase is sufficient for producing a forgery. Also, with a known message and IV pair, I can calculate half of the intermediate values before the final XOR takes place, which is probably not a good property to have. The problem is that no part of the process is keyed; everything is an output of a public function. That's not a MAC. Why not use HMAC or CMAC? Combining hash functions just isn't a good idea. I would also check out work in multicollisions for iterated, concatenated, and expanded hash functions, by Joux, Nandi and Stinson, and Hoch and Shamir, respectively.

    I think this misses the point of good cryptographic design, altogether. We obviously make assumptions, but good design is about minimizing those assumptions. That's why provable security under notions of confidentiality and integrity is important. That's why we reduce the security of one thing to another (i.e., if you can break X, then you can break Y). It's easier to design a good system if you can clearly define your goals and assumptions, and justify your design claim, such that if the assumptions hold, your system meets the goals. Your ad hoc approach is based on goals that aren't quantifiable and makes extra assumptions that are more difficult to analyze. It's anything but clean! You can do better, with fewer expenses!

    If you're trying to say that something is secure until proven otherwise, then you've got it backwards; it should be taken as insecure until proven secure. As I mentioned before, "proven to be secure" is a lot more meaningful than "not proven to be weak." There's never a complete guarantee, but I'd rather place my bets on the former, over the ad hoc latter, because it makes it easier to pinpoint potential weaknesses.

    What we normally want is IND-CCA2 /\ INT-CTXT security. By applying a SUF-CMA MAC to the ciphertext of a secure block cipher operating in an IND-CPA secure mode of operation, we get IND-CPA /\ INT-CTXT, which implies IND-CCA2. What you're using isn't a MAC, let alone SUF-CMA. Even if we assume that you've implemented the encryption scheme properly, the lack of proper integrity preservation could cost you you're confidentiality. At best, though, all you're going to get is IND-CPA. Based on this, I can say that your approach is insecure against chosen-ciphertext attacks, which can be quite real in practice. The good thing is that it's really easy to fix.

    Using code-based game-playing techniques, we have provable results that show cascades composed of at least three block ciphers, with three independent keys, to be the minimum, for a significant gain in security. Triple encryption increases security (significantly) in a way that double encryption cannot (negligibly); triple encryption is the shortest potentially "good" cascade, in this sense. Furthermore, we're not sure if security increases when you increase the number of block ciphers in a cascade beyond four.

    Triple encryption is the "sweet spot," if you will, but, as I've said many times, the added complexity of implementing a cascade just isn't warranted, compared to what it gives you. Either way, if you want to take advantage of the security that cascades are meant to provide, you should be using at least three independently keyed block ciphers. You know by now though that my advice is to stick to one.
Thread Status:
Not open for further replies.