4,105 reputation
1421
bio website
location
age
visits member for 2 years, 9 months
seen Dec 15 at 15:38

May
22
comment Is “non-repudiation” automatically proven, given the other three tenets of info security?
I am, however, starting to understand that there are ways to use DH to verify the other person is who they say they are but not be able to prove it to anyone else after the fact, which is a practical requirement of non-repudiation in the legal sense. SPEKE's one possibility; even giving up the password used in key exchange isn't a proof for posterity that any given message was sent by Alice.
May
22
comment Is “non-repudiation” automatically proven, given the other three tenets of info security?
I still don't understand; what's Alice's "long-term key" in DH terms? Is it her secret, a, or the generator g or prime modulus p, or something used to generate one or more of them, like a shared password? For Bob to know it's Alice, Bob would have to know something that, in the simple ephemeral DH scheme, only Alice would know.
May
22
comment Is “non-repudiation” automatically proven, given the other three tenets of info security?
But, how does Bob know he's talking to Alice in the first place? He may know that the other party to his conversation wrote the message (because he didn't and no-one else could have), but he doesn't know who that other party is. MACs are for message integrity verification; proof the message is exactly what the other party sent (and did actually come from the other party), but there's no identity validation inherent in it. Maybe you're suggesting using SPEKE (password-based DH variant)?
May
22
comment Is “non-repudiation” automatically proven, given the other three tenets of info security?
@Iszi - Availability is a fifth tenet, separate from all others mentioned. The CIA model typically relates to storage of information; keep unauthorized people from getting it, protect the correctness of it, and keep it available to authorized people. Two additional tenets shake out when it comes time to communicate it; make sure the party with whom you're communicating is who they say they are and that what you "heard" is what they "said", and make sure neither side can deny the communication occurred.
May
22
comment Is “non-repudiation” automatically proven, given the other three tenets of info security?
How? How would Bob know that a message came from Alice when using D-H? The scheme doesn't verify either party's identity; anyone can generate a random key component, and use it along with the other party's modulated key base to set up a shared key. The Wikipedia page specifically calls it an anonymous, non-authenticated key agreement protocol. That's my point; you must authenticate the sender to authenticate any messages from a sender, and if you don't you cannot have non-repudiation.
May
22
comment Is “non-repudiation” automatically proven, given the other three tenets of info security?
I have edited the OP. The problem is in defining "authentic" as somehow not requiring the identification of the real-world sender. I can initiate an asymmetrically-secured key exchange, whether based on the RSA scheme or D-H, with any IP address on the Internet that understands the request I am making. I can assert that the resulting communication channel is confidential, and if a MAC-based encryption mode is used, that the messages exchanged are unaltered. The messages are still garbage because I don't know and can't prove who sent them, and thus I can't assert the messages to be "authentic".
May
22
revised Is “non-repudiation” automatically proven, given the other three tenets of info security?
added 1271 characters in body
May
22
comment Is “non-repudiation” automatically proven, given the other three tenets of info security?
Right, but TLS allows for remote party authentication during the handshake, via certificate exchange, independently from the use of the exchanged key. Authenticating the sender as not only being the party you began the conversation with, but the party you wanted to begin the conversation with, is key to authenticating the messages exchanged as genuine. It would thus follow that the D-H scheme which I was referring to doesn't actually provide authentication, and thus it cannot provide non-rep. Perhaps that requires a change in definition of "authenticity" from my OP.
May
22
revised Is “non-repudiation” automatically proven, given the other three tenets of info security?
added 2 characters in body
May
22
comment Is “non-repudiation” automatically proven, given the other three tenets of info security?
... yes, but on its face this is no different than if I chose to trust a self-signed certificate when initiating a TLS handshake. Just because only you and I know a key and can thus communicate confidentially and with integrity, doesn't mean I actually know who you are and can thus verify that the messages I am getting are coming from whom I expect them to. I would say this does not provide authentication, because verifying a message as genuine, authenticating it, involves positive identification of the sender as the party who should be sending the message in the first place.
May
22
comment Is “non-repudiation” automatically proven, given the other three tenets of info security?
Yes, mostly. We are assuming, for the purposes of this question, that no cryptographic secrets are compromised; that is a different problem.
May
22
asked Is “non-repudiation” automatically proven, given the other three tenets of info security?
May
13
comment How does hashing work?
Well if you're using a secure hash (>=256-bit digest size) then storing the hashed value of "password" is going to increase your storage size. In addition, if an attacker were ever to see that 50% of the user accounts had the same password hash, he'd know that all he'd have to do is crack one password and he has access to 50% of the user accounts. You should be "salting" your password hashes; there are a variety of methods, but the end result is that the same password hashed by the same algorithm produces a different digest, because of an additional unique salt value for each account.
May
9
comment How do spammers verify the validity of a huge amount of email addresses?
... and in that case they don't care.
May
1
comment Is publishing your public IP address a security threat?
This. Posting your public IP on a message board might raise interest in trying to hack the computer or network behind it, but there's really no way to avoid someone else knowing about it (even if that person is the anonymous proxy gateway you route your traffic through).
Apr
30
revised The security level in hash function
deleted 1 characters in body
Apr
12
comment How is “hacking” even possible if I “defend” properly?
"As the defender, you must win 100% of the time. A hacker only needs to win once." - This, x1000.
Apr
9
revised How does hashing work?
added 250 characters in body
Apr
9
answered How does hashing work?
Apr
5
comment DDoS - Impossible to stop?
Short and sweet, but somewhat incorrect. Most DDoSs are the result of a botnet. Botnets, however massive, are a subset of the Internet, that attack by making sustained, rapid requests, often in a manner differing significantly from legitimate traffic (no legitimate user sends SYN after SYN without completing the handshake). More sophisticated attacks that turn legitimate users against a site (DNS hacking, malicious Slashdot-style linking) are harder to defend against, but also harder to pull off and control (as in Tom Leek's analogy; you set it up and hope for the worst).