Stack Exchange
log in

Mike Ounsworth

 Discussion between Gamer2015 and Mani…

Imported from a comment discussion on security.stackexchange.c...
Mike Ounsworth
May 28, 2021 20:29
Put a different way, if my company's IT department buying an E2E encryption product that claimed to be both fully blind to the server, and also devices can join even if no other devices are online, I would tell my IT guys to walk away; this feels like snake oil because clearly there's some hack; there's no way that's 256-bit security all the way through. There's no way that a client with no prior connection or pre-distributed crypto keys can join and get all the messages, but an attacker can't.
Mike Ounsworth
May 28, 2021 20:26
And yes, that means new devices can't join if all other devices with the plaintext messages are offline.
Mike Ounsworth
May 28, 2021 20:25
I feel pretty strongly that to properly call this E2E, you need each device to have an RSA or DH / ECDH public key where the private key never leaves the device and that each message is encrypted for a specific recipient device.
Mike Ounsworth
May 28, 2021 20:22
idk, this whole thing feels like an XY Problem in that you're asking about avoiding IV re-use, but I think the bigger problem is that a central vault does not really accomplish the goals of E2E Encryption: it does not have perfect forward secrecy, it will only be as strong as the user's password, etc.
Mike Ounsworth
May 28, 2021 20:18
The argument "my big complicated thing is totally good because I'm using AES-GCM" is a bit like this guy saying "This is safe because I'm using ladders with safety testing stickers on them!".
https://i.redd.it/yf10xnyvfu441.jpg
Mike Ounsworth
May 28, 2021 20:15
I admit that I don't really understand how you're trying to do this, but I'm guessing that either the whole thing will rest on a memorized password (in which case the whole encryption thing will only be as strong as the user's password, which is typically about 40 bits), or you are going to build something that you call E2E, but the server does actually have the ability to read messages if it really wants to.
Mike Ounsworth
May 28, 2021 20:12
In regards to this: "I do not see at what point i try to implement something that is not already well established"
If it was already well established, then you wouldn't need to build it. Stating your goals as 1) Fully E2E encryption where the server cannot read the messages, and 2) A new device can read the past messages by only interacting with the server. These seem contradictory to me.
Mike Ounsworth
May 28, 2021 20:06
So does a new device join? With some sort of password I assume?
Mike Ounsworth
May 28, 2021 20:06
@Gamer2015 Right, I see your point: the out-of-the-box signal protocol is an online protocol; it does not allow a new device to join and recover previous messages by only interacting with the server.
Mike Ounsworth
May 28, 2021 17:09
Sorry for the wall of text.
Mike Ounsworth
May 28, 2021 17:09
You should take something that's well-established and well-studied, adjust it to your needs if you must, but know that every change from the real version is a potential place to get it wrong.
Mike Ounsworth
May 28, 2021 17:08
So, your current approach of "I thought up this thing? How do I make it secure?". Unless you happen to be all of the world's best cryptographers together, the answer is going to be "you don't".
Mike Ounsworth
May 28, 2021 17:07
I would really strongly advise you to take the "Don't roll your own" advice to heart: designing complex crypto protocols is really hard. For example TLS 1.0 was designed by the world's best cryptographers but had flaws that nobody noticed at the time. Signal Protocol is currently the state of the art for E2E Encryption; it's been around since 2014 with no major flaws discovered.
Mike Ounsworth
May 28, 2021 17:03
I'm not an expert in the Signal Protocol, but I believe its "Double Ratchet" is basically about incrementing your AES keys and IVs:
*"The parties derive new keys for every Double Ratchet message so that earlier keys cannot be calculated from later ones."*
Mike Ounsworth
May 28, 2021 17:00
That means the client can keep its own IV counter, and the server can keep its own counter and you don't care about syncronizing them because each party is using different AES keys. If either the client or the server somehow loses its counter, then start a new session with a new AES key. AES keys are cheap; counter syncronization is hard.
Mike Ounsworth
May 28, 2021 17:00
@Gamer2015 "I would like to use this deterministic approach as much as possible as it completely avoids collisions." In TLS where you have a sender and a receiver each AES encrypting for the other; you derive different AES session keys for each direction.
Mike Ounsworth
May 28, 2021 14:25
I haven't fully read the thread, but I also feel like your approach does not really make sense. Usually the IV is randomly-generated for each encryption and is essentially part of the ciphertext.
 

 Discussion between Borka and Mike Oun…

Imported from a comment discussion on security.stackexchange.c...
Mike Ounsworth
Feb 3, 2021 16:34
Yeah! Nice! That matches my understanding :)
Mike Ounsworth
Feb 3, 2021 14:52
2) Another thing about certificates: during the TLS handshake, the certificates (both client and server) are sent un-encrypted, so anybody sniffing network traffic can sniff a copy of your certificate; similarly any routers that carry your packets between your laptop and the server will have a copy of your certificate. Certificates are designed to be public information; the protocols and software that handle them do not use the same security that they do, for example, with the private key.
Mike Ounsworth
Feb 3, 2021 14:49
Hi @Borka, sorry for the slow reply. A couple thoughts: 1) "self-signed" means that the client has signed its own certificate (technically: it's when the subject public key and the signing key are the same key). What you're describing is a "private CA". That actually seems ok as a pattern.
Mike Ounsworth
Jan 29, 2021 00:08
@Borka I removed it because apiKey over non-mutual TLS is strong security; a server configured to accept any self-signed client cert is no security at all. (that said, sometimes servers are configured for users to upload their self-signed certificates in advance -- or ssh public keys -- this is a perfectly fine solution that still relies on the private key to prove that you are the owner of a public key that has been "pinned" in the server configuration)
Mike Ounsworth
Jan 29, 2021 00:08
@Borka I think what you're saying is that doing TLS client auth with a self-signed client cert is completely useless (no security). Yes, I agree with that. Don't do that!
Mike Ounsworth
Jan 29, 2021 00:08
@Borka With all due respect, I don't think you do understand how certs work. Sending a client cert without using the private key is like showing your ID to a bouncer without showing your face. You need to use the private key in order to prove that you are the owner of the public key in the certificate.
Mike Ounsworth
Jan 29, 2021 00:08
@Borka ... I don't know where to start. I think you completely mis-understand how certificates work. Yes, you pass privkey + cert to curl, curl most certainly does not pass the priv key to the server. Certificates are intended to be public information (the thing inside it is called a public key after all). You may choose to keep your certificate as a secret, but that is not what they are designed for.
 

 Discussion on answer by Mike Ounswort…

Imported from a comment discussion on security.stackexchange.c...
Mike Ounsworth
Nov 25, 2020 07:34
@CharlesDuffy My employer maintains two FIPS and CC validated crypto modules. I've worked on both. I'm very familiar with the shortcomings of the FIPS system. I have even posted answers on this site where I rage against the FIPS system. None of that changes what I wrote here: the target audience of this USB stick are people who are required by their contracts to use FIPS-certified hardware. Claiming that it's difficult to achieve does not imply that it's better ;)
 

 Discussion between Mike Ounsworth and…

Imported from a comment discussion on security.stackexchange.c...
Mike Ounsworth
Apr 10, 2020 16:21
Aha, good to know!
Mike Ounsworth
Apr 10, 2020 14:58
Conclusion: edge cases are hard. Your intuition probably is more refined than mine since you spend more time at it.
Mike Ounsworth
Apr 10, 2020 14:52
:P I'll spring your trap.
I do not have an answer. Indeed, it may be something to do with the risk context config on the bank's side (ie if it's coming from Google Wallet, then we consider MFA to already have been done by Google, or some equivalent thing), or it could be some trick on Google's end that the bank is oblivious to.

I don't know enough to post an Answer, but I think this question *may* have an interesting on-topic answer, which is criteria I use when evaluating the Re-Open queue.
Mike Ounsworth
Apr 10, 2020 14:30
(though as mod, your votes insta-close, giving your personal opinions a lot more weight than someone who has to convince 4 other people to vote the same way)
Mike Ounsworth
Apr 10, 2020 14:29
@schroeder Yup, I support! This is indeed the process :)
Mike Ounsworth
Apr 10, 2020 14:27
I can't speak to the other "why is my bank and payment provider doing/not doing X?" type questions. I see your point that in general the people at PersonalFinance probably have more knowledge about these things. I'm trying to draw a parallel with a "why is my google account doing/not doing X?", which I guess in some cases could be on-topic but in others should see Google documentation. Same here I guess?

About this specific question; as a security architect on an auth/MFA platform which includes but isn't specific to PSD2, I see this question in particular as a general security question.
Mike Ounsworth
Apr 10, 2020 14:20
I see your point.
We may just have to agree to disagree on this one and leave the question up to the community to re-open or not.
Mike Ounsworth
Apr 10, 2020 14:09
By the way, you used to live in Vancouver, right? But from your active times, I'm guessing you're somewhere in Europe now?
Mike Ounsworth
Apr 10, 2020 14:07
Hey @schroeder.

I just want to be clear that I've got no hard feelings here.
Mike Ounsworth
Apr 10, 2020 14:07
Where are you getting intra-institution from? As an end-user, if I try to buy a pack of gum with my credit card, I need to confirm the push notification to my phone, but if I load that same card into Google Wallet then for some reason the MFA goes away. Seems very much like Google is lowering my end-user security.
Mike Ounsworth
Apr 10, 2020 14:07
You're also implying that people working in the payment card industry trying to implement these security features are not welcome to post on this site. ..??
Mike Ounsworth
Apr 10, 2020 14:07
@schroeder That's your opinion; I'm gonna disagree. Would you say that how TLS works between servers is off-topic here and belongs on serverfault? You're the mod, so final decision is yours, just logging my opinion :P
Mike Ounsworth
Apr 10, 2020 14:07
@schroeder Attempt: If the security model of your credit card involves MFA-per-transaction, then why does entering the card into your Google Wallet allow you to bypass the bank-enforced security model? I'll give you that, as written, it seems like an opinion-based "amirite?" question, but the link to security seems clear to me.
Mike Ounsworth
Apr 10, 2020 14:07
@schroeder I disagree with closing this question. It seems totally valid to me. I assume this question relates to the EU's PSD2 standard, which can include blocking a credit card transaction until MFA / OTP / Push Notification confirmation of the transaction by the card owner. I know because we make the auth software that drives this. I've voted to re-open.
 

 The DMZ

A serious place where infosec is discussed PS we don't do hard...
3
Mike Ounsworth
Dec 10, 2018 02:50
I closed my browser in exasperation around 12:30 EST. I'm honestly appalled that this tantrum continued on for another 5 hours afterwards...
Mike Ounsworth
Dec 10, 2018 02:39
@RoryAlsop BLESS YOU for handling this! You have certainly earned my vote for crypto.se mod!
Mike Ounsworth
Dec 9, 2018 17:26
ah, thanks
Mike Ounsworth
Dec 9, 2018 17:24
@curiousguy If you have a problem with me, then let's talk about it here rather than filling my inbox with angry comments.
https://security.stackexchange.com/questions/195688/how-is-danger-badidea-thisisunsafe-justified/199382?noredirect=1#comment397691_199382
Mike Ounsworth
Dec 9, 2018 17:13
Yeah, I feel weird about it too. I added a "Views expressed are my own" disclaimer to my profile :/
Mike Ounsworth
Dec 9, 2018 17:12
Thanks :)
I re-wrote the post in question: https://security.stackexchange.com/a/174694/61443, basing it this time on the RFCs rather than Cisco's marketing materials, and sent my colleague a "Thanks for pointing this out". Hopefully that's the end of it.
Mike Ounsworth
Dec 9, 2018 17:07
@curiousguy I feel like you've stopped caring about being constructive, and are just trying to pick a fight with me. I've flagged a couple of your comments as Rude or Abusive.

https://security.stackexchange.com/a/199382/61443

https://security.stackexchange.com/questions/189496/is-it-possible-to-check-if-a-usbs-firmware-is-unmodified-when-plugged-in/189497?noredirect=1#comment397684_189497
Mike Ounsworth
Dec 8, 2018 21:40
Question: I've just run into the situation where a post I made (citing publicly-available information, and drawing my own conclusion) differs from the marketing material of my company.
My gut is to re-read the relevant RFC's and edit my post to correct any factual errors, but not necessarily bring it into line with marketing's stance. "Views expressed are my own, blah blah".
Advice / opinions?
 

 Discussion on question by kayla: Encr…

Imported from a comment discussion on security.stackexchange.c...
Mike Ounsworth
Sep 7, 2018 19:04
Either way I'm guessing you'll need to write software for each user to install on their computer so that your server retrieves the encrypted blobs from the database, and it stays encrypted all the way to their laptops. Any scheme where the user sends up their private key will basically defeat the purpose of encrypting it on the server (though if the server has its own decryption key for everything, then maybe you've already defeated the purpose??)

I'm thoroughly confused now.
Mike Ounsworth
Sep 7, 2018 19:01
If you go a symmetric key route, that might have a simpler solution, but it's a bit outside my expertise.
Mike Ounsworth
Sep 7, 2018 18:59
This will get tricky if you want a central server to store private keys so that users can access their encrypted data from any device. Doing that in a way that's secure will be next to impossible.

I don't like to plug my company's products on this site, but Entrust's PKI has a module called Roaming Server that is for exactly that: giving users access to their private keys.