4 ms·

lol, you are concerned by interception (gov and isps have root certificates) but not about where the data is stored? With OTP you can easily encrypt your data

by bullen 3y ago

lol, you are concerned by interception (gov and isps have root certificates) but not about where the data is stored? With OTP you can easily encrypt your data so nobody can read it inflight over HTTP. I guess you need to have the creativity to extend the link knowledge with encrypting the data with the OTP.

progval 3y ago
How do you encrypt data with one-time passwords?
SahAssar 3y ago
The RFC seems to presuppose that there has been an initial trust setup (since it says the the client has a pass-phrase already). How do you setup that that initial pass-phrase without TOFU?
- bullen 3y ago
  You cannot solve this unless you send a pigeon or trust some higher power. Certificates are a scam. My solution which is convoluted and relatively insecure if you have a persistent MITM is to require a password change that you can encrypt with the old password, then the MITM has to remember the old password to know the secret. But you are right that OTP only are safe after the secret has been shared. Just like all crypto including HTTPS and SSH.
  - SahAssar 3y ago
    For HTTPS we have setup a infrastructure to solve that. Without similar steps for your OTP solution it will never catch on. Why not advocate for something like DANE if you do not like the current PKI setup?
    - bullen 3y ago
      The steps are for most people to stop using what the governements and companies provide/enforce. HTTPS is _not_ more secure in any way. The lock icon is an illusion. As for the technical reasons: - Big-ints are not trivial in js. - DNS is centralized.
chrismorgan 3y ago
HTTPS is about encryption with no preshared secrets, and proving the origin’s authority (the CA part of TLS). OTP is about authenticating clients, using a preshared secret established by unspecified means. They’re completely different things. It’s like you’re comparing Apple (the company) and Orange (the city in NSW, Australia). Cleartext HTTP is bad for various reasons, one of which is that pervasive monitoring is an attack: https://www.rfc-editor.org/rfc/rfc7258.html https://www.rfc-editor.org/rfc/rfc7258.html.
- bullen 3y ago
  "encryption with no preshared secrets" that does not exist, never have and never will.

by bullen 3y ago

progval 3y ago

How do you encrypt data with one-time passwords?

SahAssar 3y ago

The RFC seems to presuppose that there has been an initial trust setup (since it says the the client has a pass-phrase already). How do you setup that that initial pass-phrase without TOFU?

bullen 3y ago
You cannot solve this unless you send a pigeon or trust some higher power. Certificates are a scam. My solution which is convoluted and relatively insecure if you have a persistent MITM is to require a password change that you can encrypt with the old password, then the MITM has to remember the old password to know the secret. But you are right that OTP only are safe after the secret has been shared. Just like all crypto including HTTPS and SSH.
- SahAssar 3y ago
  For HTTPS we have setup a infrastructure to solve that. Without similar steps for your OTP solution it will never catch on. Why not advocate for something like DANE if you do not like the current PKI setup?
  - bullen 3y ago
    The steps are for most people to stop using what the governements and companies provide/enforce. HTTPS is _not_ more secure in any way. The lock icon is an illusion. As for the technical reasons: - Big-ints are not trivial in js. - DNS is centralized.

chrismorgan 3y ago

HTTPS is about encryption with no preshared secrets, and proving the origin’s authority (the CA part of TLS). OTP is about authenticating clients, using a preshared secret established by unspecified means. They’re completely different things. It’s like you’re comparing Apple (the company) and Orange (the city in NSW, Australia). Cleartext HTTP is bad for various reasons, one of which is that pervasive monitoring is an attack: https://www.rfc-editor.org/rfc/rfc7258.html https://www.rfc-editor.org/rfc/rfc7258.html.

bullen 3y ago
"encryption with no preshared secrets" that does not exist, never have and never will.