![]() keybase/public/ /hello.txt or /keybase/public/ /hello.txt Like for example /keybase/public/andreagrandi/hello.txt but you can also use any other identity like Every user public folder/file can be accessed using their Keybase username, Public foldersĪnything you place inside the /public folder can be accessed by any Keybase user and it'sĪutomatically signed. Where you will find at least three other folders: public, private, team. There is a virtual folder located at /keybase (on OSX/Linux or k:\keybase on Windows) One of the first features launched by Keybase was their encrypted filesystem. Very useful in some situations, we will see it later. Without having to know your email address or Keybase username. Once you are on Keybase, other users can look for you even using your GitHub or Twitter username Unless an attacker controls all your social accounts, they cannot impersonate and verify In Keybase youĬan link your existing online accounts to your Keybase account and show additional You don't just say "I'm Andrea Grandi, this is my PGP key.". Many of us have a personal blog, a Twitter or Facebook accounts, a GitHub account etc.Īll these accounts combined together make our online identity.Įvery Keybase account can be verified by other online identities. In Keybase it's possible to either generate a new PGP key or import an existing oneīut the most important thing is being able to verify our own identity using multiple proofs. To encrypt and decrypt a message for a certain user, but it also introduced a very nice When Keybase was launched it was mainly a wrapper for PGP commands Keybase really makes encryption easy to use. In chat, all messages are encrypted using NaCl's secret box primitive, with the key derivedĪs above.Using PGP can be quite hard, even if you have a lot of experience with computers.īy the way encryption is what gives us privacy and permits us to safely transmit informationĪnd for this reason it should be easy to use, for everyone. Preventing them from viewing the chats or files encrypted with those keys. The server withholds them from implicit admins, For the given team, all readers, writers, owners,Īnd explicit admins can see these 32-byte masks. That is, the key is the XOR of a key derived from the team-shared secret s i,Īnd a server-stored 32-byte random mask. For Chat: HMAC( s i, "Keybase-Derived-Team-Chat-1") ⊕ S i,CHAT.For KBFS: HMAC( s i, "Keybase-Derived-Team-KBFS-1") ⊕ S i,KBFS.Team members derive application keys from the shared seeds s i described See the description of Cascading Lazy Key Rotation for more detailsĪbout how this rotation is orchestrated. Over, the previous seed s i is encrypted withĬ i 1 via NaCl's SecretBox symmetric encryption, just as with Key halves are written into the team's sigchain. ![]() The new PTK keys are encrypted for all remaining members, and the new public Leaves or is removed from a team, the PTK must rotate. When a team member revokes a device, or a team member is reset, or a user The current s i should have a box for every team member, whether implicit or explicit. This make s i available on every device for the user. S i is encrypted for the user's public PUK DH key. At generation i, the keys E iĪnd D i are signed into the team's public sigchain. ![]() This process is repeated at every generation i. Where HMAC is computed with SHA512, and truncated to the first 32 bytes. Secret key in NaCl secretbox when encrypting previous seeds s.
0 Comments
Leave a Reply. |