pckr (picker) is
- a P2P
network
discovery framework - a
public_key
infrastructure - a messaging service
- an end-to-end encrypted file transfer service
- a possible security hazard
This is a high-level view of how the network
is created and how users are bootstrapped into it.
Instructions are provided elsewhere.
user1
is created with apublic_key
/private_key
pairuser1
can then expose an interface to the world (we which we call theirsurface
) at anip:port
combination- the
surface
will listen for incomingframe
s and react to them
- the
user1
will be very lonely indeed until bootstrapped into anetwork
user1
is encouraged to contact a friend (user2
) out-of-band to exchangeip:port
infouser1
can then stitchuser2
into theiripcache
- at this point either
user1
oruser2
can request the other'spublic_key
- if
user1
initiates thepublic_key
exchange,user1
volunteers theirpublic_key
freely- no cryptographic protocol is established beween the users at this point, so
user1
'spublic_key
is transmitted in the clear
- no cryptographic protocol is established beween the users at this point, so
user2
can accept this request for theirpublic_key
user2
can also storeuser1
'spublic_key
which was just transmitteduser2
will encrypt theirpublic_key
with apassword
, and encrypt thatpassword
withuser1
'spublic_key
, and send it backuser1
can decrypt thepassword
using theirprivate_key
, and then decryptuser2
'spublic_key
using thepassword
- at this point
user1
anduser2
are sharingpublic_key
s, and are aware of each other'sip:port
s - both
user1
anduser2
will periodicallyseek_user
to seek each other out, toping
the other andchallenge
their storedpublic_key
s user1
anduser2
are also expected to transmitframe
s from users that are surfacing into thenetwork
, and users that areseek_user
ing other users- more details on both follow
user1
anduser2
are also expected to transmitframe
s pertaining to the health of thenetwork
- specifically,
frame
s are sent out to gather information about the health of thenetwork
topology user1
anduser2
would do well to heed the advice of theseframe
s, and challenge or expel inconsistently recognized users in their reachablenetwork
- specifically,
- my first drafts of the client include a server, which coördinated
ip:port
combinations for certain users. very early drafts also included thepublic_key
of each user, in plain text, as a column, sitting on a Postgres database behind a REST API - the challenge was to make it a true P2P
network
, with no coördinating server - since no coördinating server was desirable, every client has to ensure that they remain a part of the
network
- for this reason, the
network
is hereby referred to as amurmuration
- no such thing is true
- each client is responsible for tagging-along by informing the
network
of their whereabouts ("surfacing") or verifying theip:port
and cryptographical links of their contacts ("seeking") - clients also have a role to play in ensuring the health of their
network
topology, by propagatingframes
which aim to collect information about the consistency of thenetwork
- such
network
topology checks might also then inform clients about inconsistently recognized users, which the client could then choose to expel from theiripcache
, or challenge, as they wish - every client is also free to do nothing
- such
- it might seem a pain to bootstrap over the phone or WhatsApp or Telegram or what have you but you can create small
network
s isolated from the outside world
- user information is thrown into a directory tree
- the client was written to allow unfettered access to users on the same account or physical machine as you
- no passwords exist. anyone that has access to your computer has access to your pckr "account"
- users are not guaranteed unique across a
network
of any size greater than 1public_key
challenges are used when needed to establish the identity of your contacts- it's entirely possible that your
ipcache
will become overrun with duplicate usernames of people purporting to be who they say they are. woe to you and them!public_key
challenges to the rescue. - seriously though this could be a problem
- remember to contact your contacts out of band as appropriate to verify their identities
- the health of the
network
is achieved by voluntary participation in two activitiesseek_users
surface_user
- clients are encouraged to
surface_user
on startup- they need to tell all of the contacts they have in their
ipcache
that they are alive - they do this by encrypting their
ip:port
using their contacts'public_key
s, and transmitting that information to each contact
- they need to tell all of the contacts they have in their
- clients are also encouraged to
ping
andchallenge
all users they have knowledge of- clients can
ping
orchallenge
any conact in theiripcache
- clients can
- they can also
seek
contacts that they have apublic_key
for
user1
can seek out any user in their reachablenetwork
, if they know that user'spublic_key
user1
prepares apayload
for destined foruser2
user1
encrypts apassword
usinguser2
'spublic_key
- they encrypt their own
ip:port
combination asjson
, along with theirusername
, using thepassword
- they also generate a random
seek_token
, which they encrypt using thepassword
- the
seek_token
is stored locally - they send the
frame
out to every contact they have in theiripcache
- each contact can try to decrypt the
password
- if they can decrypt it, they reply directly to
user1
using theip:port
combination they get by decrypting it from theframe
'spayload
user1
can process theseek_user_response
to storeuser2
'sip:port
in theiripcache
user1
can ensure thatuser2
send back the correctseek_token
user2
is free to storeuser1
'sip:port
combination as welluser2
is equally free to challengeuser1
before doing so
user1
can challengeuser2
in 2 ways:- does
user2
have theprivate_key
that matches thepublic_key
thatuser1
has stored for themuser1
encrypts an arbitrary piece of data usinguser1
'spublic_key
and sends it touser2
user2
responds by using theirprivate_key
to decrypt the data and send it backuser1
can verify the data- if it matches, the challenge has succeeded
- does
user2
haveuser1
'spublic_key
user1
sends a piece of data touser2
user2
encrypts it using thepublic_key
ofuser1
user1
decrypts it using theirprivate_key
- does
- by using both methods,
user1
anduser2
can verify a solid cryptographical link - either user can also ensure that the user presenting at a certain
ip:port
is who they claim to be - this makes the exchange of
public_keys
s as early as possible quite important for the health of thenetwork
- users can (and even must) store the
ip:port
of their contacts in theiripcache
- the contents of the
ipcache
are updated or adjusted in response to particularframes
user2
can store theip:port
ofuser1
that is included in aseek_user
frame
user1
can store theip:port
ofuser2
that they might receive in aseek_user_response
frame
- users can also stich a contact into their
network
manually- in fact, this is how they are bootstrapped into the
network
- in fact, this is how they are bootstrapped into the
- since everyone is so well connected and cryptographic protocols are established and verifiable between users, we might as well also send files to each other