Cleanup
emdee
parent
2068699ff7
commit
61c11b11ee
|
|
@ -118,8 +118,8 @@ It has these characteristics:
|
|||
|
||||
2. It is small - 1K to 4K in size.
|
||||
|
||||
3) As we will need a NaCl signing keypair in order to sign the
|
||||
payload, the name, (PersonaID) can be the public key of the signing keypair -
|
||||
3) As we will need a NaCl signing keypair in order to sign the payload,
|
||||
the name, (PersonaID) can be the public key of the signing keypair -
|
||||
32 bytes or 64 hex chars.
|
||||
|
||||
4. If we push the blob info by DHT announcements, it pushed regularly
|
||||
|
|
@ -158,11 +158,10 @@ the PersonaID. The mapping table can be automatically scanned and any
|
|||
entries for which the PersonaID == ToxPk could be automatically
|
||||
updated to use the signing key as the PersonaId.
|
||||
|
||||
|
||||
I had assumed we would have to use the DHT to deal with decentralization.
|
||||
But this POC makes me think we can use the toxcore status_message
|
||||
and avatar_files code to do it without the DHT. So let's say for now
|
||||
to focus this discussion, we will ignore DHT announcements.
|
||||
and avatar_files code to do it without the DHT, at least to Friends.
|
||||
So let's say for now to focus this discussion, we will ignore DHT announcements.
|
||||
|
||||
1. Set your status message to be the signing public key and push the blob by some means like avatars to Friends, or
|
||||
|
||||
|
|
@ -179,12 +178,13 @@ it got too big for a status message.
|
|||
|
||||
The same blob would be on each of a Person's devices.
|
||||
|
||||
### put that in the status message if less than 1007 bytes
|
||||
### Use the status message if less than 1007 bytes
|
||||
|
||||
With the signature and the public key, this should leave room for at least 12 devices in less than 1007 bytes, compressed and base64 encoded. With 1007 bytes with the signature and signing key, and nicknames of 12 bytes it will take about 16 devices
|
||||
```
|
||||
1007-128-64-2/(32+6+12) = 16
|
||||
```
|
||||
With the signature and the public key, this should leave room for at
|
||||
least 12 devices in less than 1007 bytes, compressed and base64
|
||||
encoded. With 1007 bytes with the signature and signing key, and
|
||||
nicknames of 12 bytes it will take about 16
|
||||
devices: ```1007-128-64-2/(32+6+12) = 16```
|
||||
|
||||
One problem with this is that only your Friends could verify the blob,
|
||||
which means users you have never invited will not be able to verify,
|
||||
|
|
@ -268,25 +268,29 @@ keys of that Persona for each NGC group the Persona belongs to.
|
|||
should be managed by a keymanager. In a corporate setting, this will
|
||||
be a requirement.)
|
||||
|
||||
There is Python script to parse profiles that could be modified to rekey at:
|
||||
https://git.plastiras.org/emdee/tox_profile
|
||||
There is a Python script to parse profiles that could be modified to rekey
|
||||
group self entries at: https://git.plastiras.org/emdee/tox_profile
|
||||
|
||||
|
||||
## Summary
|
||||
|
||||
The changes to the core are not large:
|
||||
1. Change the status message callback to look for public signing keys
|
||||
2. Extend the avatar file transfer mechanism to transfer blobs
|
||||
3. Use the public signing keys to verify the blobs
|
||||
4. Use the blobs to populate the table, and designate one entry as active.
|
||||
5. Wrap all the calls that use a PK to look in the table for the active PK.
|
||||
2. Change the status message callback to look for public signing keys
|
||||
as a first cut, and then extend the avatar file transfer mechanism
|
||||
to transfer blobs
|
||||
3. Use the public signing keys to verify the blobs
|
||||
4. Store the blobs in a subdirectory, with their signature.
|
||||
5. Use the blobs to populate the table, and designate one entry as active.
|
||||
6. Wrap all the calls that use a PK to look in the table for the active PK.
|
||||
|
||||
All existing unmodified users would continue to work: no testnet required.
|
||||
|
||||
Assuming the blobs were created by an independent stand alone utility,
|
||||
the changes to the clients are not large:
|
||||
1. Consult the mapping table and show it to the users.
|
||||
1. Consult the mapping table and show it to the users.
|
||||
2. Accept or reject new blob updates.
|
||||
3. Redefine the notion of contacts to point to the PersonaID
|
||||
4. Add the ability to push a new blob to friends, or perhaps selected friends.
|
||||
3. Redefine the notion of contacts to point to the PersonaID.
|
||||
4. Add the ability to push a new blob to Friends, or perhaps selected Friends.
|
||||
|
||||
Also we would want the Python script to keep profiles within a Persona in sync.
|
||||
|
|
|
|||
|
|
@ -4,12 +4,12 @@ Up: [[SecurityVulnerabilities]]
|
|||
|
||||
## DeCentralized
|
||||
|
||||
|
||||
### richochet
|
||||
|
||||
Always uses Tor, rather than Tox, where Tor can be used at will.
|
||||
|
||||
<https://richochet.im> https: certificate expired over a year ago, and latest version in 2016. <https://github.com/ricochet-im/ricochet> last updated 2017.
|
||||
* <https://richochet.im> https: certificate expired over a year ago, and latest version in 2016.
|
||||
* <https://github.com/ricochet-im/ricochet> last updated 2017.
|
||||
|
||||
Relaunched as <https://github.com/blueprint-freespeech/ricochet-refresh>
|
||||
|
||||
|
|
@ -40,12 +40,16 @@ Features:
|
|||
|
||||
### ZeroNet
|
||||
|
||||
* Abandonned by its creator, it is being carried on by a number of non-cooperating forks.
|
||||
* A known RCE vulnerability is in some of the forks, but the developers of the patched forks have not filed a CVE.
|
||||
* None of the current developers have write access to the main web site.
|
||||
* Abandonned by its creator, it is being carried on by a number of
|
||||
non-cooperating forks.
|
||||
* A known RCE vulnerability is in some of the forks, but the developers
|
||||
of the patched forks have not filed a CVE.
|
||||
* None of the current developers have write access to the main web site,
|
||||
which distributes code with the CVE.
|
||||
|
||||
|
||||
## Centralized
|
||||
|
||||
Who cares.
|
||||
Centralized systems make it easy to MITM the E2E crypto, so unless they
|
||||
are open source, they can't be trustworthy.
|
||||
|
||||
|
|
|
|||
|
|
@ -159,7 +159,7 @@ A max limit of devices will need to be chosen later to limit worst case usage of
|
|||
|
||||
When a client sends a message to a friend/user, Toxcore will only
|
||||
attempt to send the message to the last 3 devices that sent data from
|
||||
the user that are online.[c][^3][d][^4][e][^5] E.g., Device_A sends a
|
||||
the user that are online.(c)[^3] (d)[^4] (e)[^5] E.g., Device_A sends a
|
||||
message, Device_B comes online, Device_C sends a file, Device_D sends
|
||||
a message then goes off line, Device_F sends a picture, Device_H comes
|
||||
online. Toxcore will attempt to send only to devices A, C and F. While
|
||||
|
|
@ -184,7 +184,7 @@ It is considered the job of the receiving client to keep all the other devices i
|
|||
|
||||
3. [[GroupOfDevicesPOC]]
|
||||
|
||||
4. [[MultiDevice-Announcements-POC]]
|
||||
4. [[MultiDeviceAnnouncementsPOC]]
|
||||
|
||||
### Unsolved Issues
|
||||
|
||||
|
|
@ -225,12 +225,10 @@ Conversations that need to be added to the spec:
|
|||
<grayhatter> then the file will get canceled / "marked as accpeted on a different device"
|
||||
<nurupo> so, Alice accepts and completes the file transfer on her phone
|
||||
```
|
||||
[h][^8] [i][^9] [j][^10]
|
||||
(h)[^8] (i)[^9] (j)[^10]
|
||||
```
|
||||
<nurupo> hm
|
||||
<nurupo> ok
|
||||
<nurupo> i guess you answered what i wanted to know
|
||||
<nurupo> what if race condition happends?
|
||||
<nurupo> what if race condition happens?
|
||||
<grayhatter> but I hadn't considered that detail... It'll break the existing file transfer API...
|
||||
<nurupo> Alice accepts files at the same time both on pc and phone?
|
||||
<grayhatter> nurupo, can't happen
|
||||
|
|
@ -248,7 +246,7 @@ Conversations that need to be added to the spec:
|
|||
<grayhatter> OH
|
||||
<grayhatter> bob will in that case cancel the phone then
|
||||
```
|
||||
[k][^11]
|
||||
(k)[^11]
|
||||
```
|
||||
<nurupo> fair enough
|
||||
<grayhatter> no reason to make it more complicated then it needs to be
|
||||
|
|
@ -257,7 +255,7 @@ Conversations that need to be added to the spec:
|
|||
|
||||
|
||||
|
||||
### Feature requests:
|
||||
### Feature Requests:
|
||||
|
||||
(Requested publicly, no suggestions have been reviewed or accepted yet.)
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue