4,345 reputation
1724
bio website
location
age
visits member for 3 years, 2 months
seen 21 hours ago

Jun
13
comment Client-side encryption, but cloud service can still decrypt data in the event of a death? Is this possible?
Companies that give a flip about IT security don't advertise a lot of the security measures they take. Why make it that much easier for an attacker to identify potential holes?
Jun
13
comment Client-side encryption, but cloud service can still decrypt data in the event of a death? Is this possible?
No. Either a key on the server and a key on the client can be used in the scheme I described, which is simpler than Adman's SSSS. The server never knows the password used to generate the key, nor the private key that can obtain it from the recovery key data it stores, but the user and the company have access to each. And the fact that the family has to present a death certificate is evidence in itself that the recovery mechanism has at least somewhat more process to it than storing the recovery key in a thumb drive in the top drawer.
Jun
12
revised Client-side encryption, but cloud service can still decrypt data in the event of a death? Is this possible?
added 56 characters in body
Jun
12
revised Client-side encryption, but cloud service can still decrypt data in the event of a death? Is this possible?
added 281 characters in body
Jun
12
answered Client-side encryption, but cloud service can still decrypt data in the event of a death? Is this possible?
Jun
12
accepted Is “non-repudiation” automatically proven, given the other three tenets of info security?
May
30
answered Can unencrypted keys & logins be kept out of program memory?
May
28
revised Why standards organizations give so short protection times for 128 bit encryption?
added 498 characters in body
May
22
answered Why standards organizations give so short protection times for 128 bit encryption?
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.