4 ms·

You're right the documentation is incomplete, we are actively working on the protocol and for any sections that we feel are too much "up in the air" as far as d

You're right the documentation is incomplete, we are actively working on the protocol and for any sections that we feel are too much "up in the air" as far as details go, we have purposefully left blank so as to not mislead implementations of the protocol. However, the core of the protocol is stabilizing and I can answer generally as far as missing sections go. Regarding federation, instead of publishing events to the server you're connected to, you publish events to a different server. Everything else works pretty much the same.

mdaniel 3y ago
I had a similar question about the vast number of "coming soon" sections and that led me to wonder why you would choose to submit this link at this stage of the specification's lifecycle Would it be accurate to say you're trying to get broader adoption of this idea, but currently the only implementation is in your group-income repo? I ask that with an especial emphasis on the zero knowledge password system which is currently undocumented but, if I'm understanding correctly, also unimplemented? https://github.com/okTurtles/group-income/blob/3e50642ab8866f19ac088d428e73e3fd005719db/frontend/controller/actions/identity.js#L183 https://github.com/okTurtles/group-income/blob/3e50642ab8866...
- gslepak 3y ago
  A lot of federated protocols (including partially implemented protocols, thinking @-protocol) are being released right now. There is a paradigm shift occurring in the way software development of web apps is done, and we want people to be aware of all of their choices when exploring this new way of building web applications. Maybe you want to build a federated application yourself, but want certain features that some of these protocols don't have. Well, now you know a little more about what's possible in this design space. Perhaps you've already settled on a protocol (e.g. have started building on ActivityPub), but want end-to-end encryption. Well, now you're aware that you can in fact add it in to your existing ActivityPub-based app. For example, there's no reason why Mastodon couldn't use Shelter Protocol to encrypt DMs between users. Shelter Protocol is very lightweight, and can be an add-on to existing apps. Regarding the ZKPP, it is implemented, but like the rest of the code is not yet separated out from that repo. That is one of the next steps we'll be working on, a standalone developer SDK. We are also welcoming early feedback and contributions from those who would like to participate.
  - duskwuff 3y ago
    > Regarding the ZKPP, it is implemented I'm not sure how that squares with the // TODO: Insert cryptography here comment in the source code of your demo app's login endpoint -- which doesn't appear to make use of the user's password at all? Surely that can't be right.
    - gslepak 3y ago
      The demo used ZKPP, it’s implemented in a different branch.
- loup-vaillant 3y ago
  > I ask that with an especial emphasis on the zero knowledge password system which is currently undocumented but, if I'm understanding correctly, also unimplemented? That one’s easy, it’s just (likely augmented) PAKE. There are a couple options in this space. The zero-knowledge stuff likely comes from the blind salt (OPRF, Oblivious Pseudo-Random Function). There are different variants to chose from, with slightly different security & performance trade-offs. This stuff indeed allows password authentication without ever revealing the password to the server, but the password database itself is still vulnerable to dictionary attacks once it’s stolen. What worries me though is how they failed to mention PAKE. I’ve seen much of their talk, and to be honest it smelled like snake oil. Very shallow explanation of the protocol, and many missing steps between that and an actual use case. It’s supposed so solve many Big™ problems, but how it achieves it is very unclear to me.
  - emurlin 3y ago
    Indeed, although undocumented, this is implemented and is a PAKE variant ([1] and [2]). The way that it works, at a high level, is similar to how SRP works. Two random salts are generated (let's say, A and B), where A is used for authentication (and hence public) and B is used for deriving the other cryptographic keys. When you authenticate, you retrieve A and then you prove to the server that you know what scrypt(A, password) is. At this point, the server provides you with B, and you can use this information to derive scrypt(B, password), which in turn you use to derive other cryptographic keys. It being an oblivious password store, there are other steps taken to make the protocol stateless (from the perspective of the server) and to make parties commit to random values used so that runs of the protocol cannot be replayed. > but the password database itself is still vulnerable to dictionary attacks once it’s stolen This is correct, and I'm not sure there are good ways to prevent this or equivalent scenarios from occurring. Therefore, you should see this as an additional layer on top of your already secure password and not as a substitute for a secure password. The reason for having this mechanism rather than not having it is to protect your password from brute-forcing by the public at large, in a scenario where the server operator is semi-trusted. Without this implementation, you have three alternatives: (1) Forego passwords entirely; (2) make the salted password 'public', along with the salt, which is all the information you need to brute-force it or (3) make more "normal" authentication flows without PAKE, in which case you need to trust the server even more. If you insist on using passwords, this is a compromise solution between (2) and (3), i.e., between anyone can break it and trust the server entirely. [1] <https://github.com/okTurtles/group-income/blob/e2e-protocol/shared/zkpp.js https://github.com/okTurtles/group-income/blob/e2e-protocol/...> [2] <https://github.com/okTurtles/group-income/blob/e2e-protocol/backend/zkppSalt.js https://github.com/okTurtles/group-income/blob/e2e-protocol/...>

mdaniel 3y ago

I had a similar question about the vast number of "coming soon" sections and that led me to wonder why you would choose to submit this link at this stage of the specification's lifecycle Would it be accurate to say you're trying to get broader adoption of this idea, but currently the only implementation is in your group-income repo? I ask that with an especial emphasis on the zero knowledge password system which is currently undocumented but, if I'm understanding correctly, also unimplemented? https://github.com/okTurtles/group-income/blob/3e50642ab8866f19ac088d428e73e3fd005719db/frontend/controller/actions/identity.js#L183 https://github.com/okTurtles/group-income/blob/3e50642ab8866...

gslepak 3y ago
A lot of federated protocols (including partially implemented protocols, thinking @-protocol) are being released right now. There is a paradigm shift occurring in the way software development of web apps is done, and we want people to be aware of all of their choices when exploring this new way of building web applications. Maybe you want to build a federated application yourself, but want certain features that some of these protocols don't have. Well, now you know a little more about what's possible in this design space. Perhaps you've already settled on a protocol (e.g. have started building on ActivityPub), but want end-to-end encryption. Well, now you're aware that you can in fact add it in to your existing ActivityPub-based app. For example, there's no reason why Mastodon couldn't use Shelter Protocol to encrypt DMs between users. Shelter Protocol is very lightweight, and can be an add-on to existing apps. Regarding the ZKPP, it is implemented, but like the rest of the code is not yet separated out from that repo. That is one of the next steps we'll be working on, a standalone developer SDK. We are also welcoming early feedback and contributions from those who would like to participate.
- duskwuff 3y ago
  > Regarding the ZKPP, it is implemented I'm not sure how that squares with the // TODO: Insert cryptography here comment in the source code of your demo app's login endpoint -- which doesn't appear to make use of the user's password at all? Surely that can't be right.
  - gslepak 3y ago
    The demo used ZKPP, it’s implemented in a different branch.
loup-vaillant 3y ago
> I ask that with an especial emphasis on the zero knowledge password system which is currently undocumented but, if I'm understanding correctly, also unimplemented? That one’s easy, it’s just (likely augmented) PAKE. There are a couple options in this space. The zero-knowledge stuff likely comes from the blind salt (OPRF, Oblivious Pseudo-Random Function). There are different variants to chose from, with slightly different security & performance trade-offs. This stuff indeed allows password authentication without ever revealing the password to the server, but the password database itself is still vulnerable to dictionary attacks once it’s stolen. What worries me though is how they failed to mention PAKE. I’ve seen much of their talk, and to be honest it smelled like snake oil. Very shallow explanation of the protocol, and many missing steps between that and an actual use case. It’s supposed so solve many Big™ problems, but how it achieves it is very unclear to me.
- emurlin 3y ago
  Indeed, although undocumented, this is implemented and is a PAKE variant ([1] and [2]). The way that it works, at a high level, is similar to how SRP works. Two random salts are generated (let's say, A and B), where A is used for authentication (and hence public) and B is used for deriving the other cryptographic keys. When you authenticate, you retrieve A and then you prove to the server that you know what scrypt(A, password) is. At this point, the server provides you with B, and you can use this information to derive scrypt(B, password), which in turn you use to derive other cryptographic keys. It being an oblivious password store, there are other steps taken to make the protocol stateless (from the perspective of the server) and to make parties commit to random values used so that runs of the protocol cannot be replayed. > but the password database itself is still vulnerable to dictionary attacks once it’s stolen This is correct, and I'm not sure there are good ways to prevent this or equivalent scenarios from occurring. Therefore, you should see this as an additional layer on top of your already secure password and not as a substitute for a secure password. The reason for having this mechanism rather than not having it is to protect your password from brute-forcing by the public at large, in a scenario where the server operator is semi-trusted. Without this implementation, you have three alternatives: (1) Forego passwords entirely; (2) make the salted password 'public', along with the salt, which is all the information you need to brute-force it or (3) make more "normal" authentication flows without PAKE, in which case you need to trust the server even more. If you insist on using passwords, this is a compromise solution between (2) and (3), i.e., between anyone can break it and trust the server entirely. [1] <https://github.com/okTurtles/group-income/blob/e2e-protocol/shared/zkpp.js https://github.com/okTurtles/group-income/blob/e2e-protocol/...> [2] <https://github.com/okTurtles/group-income/blob/e2e-protocol/backend/zkppSalt.js https://github.com/okTurtles/group-income/blob/e2e-protocol/...>