dxs/onionr
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

prevent replay of very old encrypted data

Browse source
This commit is contained in:
Kevin Froman 2019-02-25 22:19:37 -06:00
parent 31039861c2
commit 651fc8c43c
12 changed files with 119 additions and 24 deletions
Download patch file Download diff file Expand all files Collapse all files

BIN
docs/onionr-logo.png~
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 191 KiB

20
docs/whitepaper.md
View file

@ -91,6 +91,22 @@ In addition, randomness beacons such as the one operated by [NIST](https://beaco
# Direct Connections
We propose a method of using Onionr's block sync system to enable direct connections between peers by having one peer request to connect to another using the peer's public key. Since the request is within a standard block, proof of work must be used to request connection. If the requested peer is available and wishes to accept the connection,Onionr will generate a temporary .onion address for the other peer to connect to. Alternatively, a reverse connection may be formed, which is faster to establish but requires a message brokering system instead of a standard socket.
We propose a method of using Onionr's block sync system to enable direct connections between peers by having one peer request to connect to another using the peer's public key. Since the request is within a standard block, proof of work must be used to request connection. If the requested peer is available and wishes to accept the connection, Onionr will generate a temporary .onion address for the other peer to connect to. Alternatively, a reverse connection may be formed, which is faster to establish but requires a message brokering system instead of a standard socket.
The benefits of such a system are increased privacy, and the ability to anonymously communicate from multiple devices at once. In a traditional onion service, one's online status can be monitored and more easily correlated.
The benefits of such a system are increased privacy, and the ability to anonymously communicate from multiple devices at once. In a traditional onion service, one's online status can be monitored and more easily correlated.
# Threat Model
The goal of Onionr is to provide a method of distributing information in a manner in which the difficulty of discovering the identity of those sending and receiving the information is greatly increased. In this section we detail what information we want to protect and who we're protecting it from.
In this threat model, "protected" means available in plaintext only to those which it was intended, and regardless non-malleable
## Threat Actors
Onionr assumes that traffic/data is being surveilled by a multitude of actors on every level but the local machine. Some examples of threat actors that we seek to protect against include Internet service providers, local area network administrators,
## Assumptions
We assume that Tor onion services (v3) and I2P services cannot be trivially deanonymized, and that the cryptographic algorithms we employ cannot be broken in any manner faster than brute force unless a quantum computer is used.
Once supposed quantum safe algorithms are more mature and have relatively high level libraries, they will be deployed.