Penumbra

Broadcast-based Wireless network

What is Penumbra?

Right now we are surrounded by wireless-enabled computers in nearby buildings, but they can't communicate together directly. That's because they're sealed away in Crypto bubbles to protect their traffic and Internet connection.



Penumbra is what happens if those computers, in addition to their existing WEP or WPA encrypted private networks, are enabled to communicate using unencrypted broadcast packets with the computers in nearby buildings. And those in turn... the idea is, pretty soon you have a free distributed 54Mbps Mega-network. If you have a nearby station running Penumbra on the same channel as your network, you don't even need any new hardware to participate if your driver speaks Penumbra.

Since it is based on short-range broadcasts, the Penumbra network cannot be spied upon or disrupted at the transport level unless attackers are physically present near all nodes. And because traffic is requested and forwarded for unknown nodes an unknown distance away in addition to your own traffic, communicating using short range unencrypted broadcasts can actually be more private than using the Internet, since your ISP not only knows who you are but every packet you send on their network and who it is from and where it is going to.

Penumbra packets

Small changes are necessary to the wifi drivers to allow unencrypted packets to be sent and received without disturbing any existing association.

The concept is there will be no identifying information sent using the Penumbra protocol. IP addresses, MAC addresses or equivalents are not sent at all. There is no routing in the traditional sense, nor logging. Just sourceless unencrypted broadcast packets that are only visible to people physically within range.

Every station will use the same MAC address for the Penumbra packets, currently 13:22:33:44:55:66. See Packet Traces for an idea of what the packets look like and Implementation for more details.

Propogation of uploads

Penumbra Stations can express an interest in one or more upload, perhaps on behalf of stations further away. Other stations broadcast information to all listeners in range, if the receivers are interested they store the packets and are available to rebroadcast it for retries and for propagation.

Accepting that it is possible for a station to hear the broadcast but not be able to reply to the sender, and that no station can speak for all receivers of the broadcast, there are no acknowledge packets. Stations that are unsatisfied by a broadcast will repeat their request after a random time, and may be fulfilled by a different station. When stations that intend to broadcast to fulfill a request see another station broadcast it before they have a chance, they drop the request and will try again only if they hear the request is repeated.

Reed Solomon Forward Error Correction is used to optimize the value of every broadcast packet, allowing recovery of the contents after up to 16 symbol errors have damaged it. That is 16 damaged bytes, whether they dropped one bit or there was up to 128 bits of contiguous corruption. So the broadcasts are very robust.

User interface

Users communicate with the Penumbra usermode daemon using https.



See Implementation for full details on how this works.

Penumbra can run on a local machine, or on a small embedded device with a USB stick or drive for storage, communicating via encrypted Wifi.

Using https (openssl) means that you can remotely post or retrieve content even over the Internet with SSL encryption improving your privacy.

No logs are kept, all pages are set no-cache and browser autocomplete is disabled for all pages on the embedded https:// site.

Content security

When a file is uploaded over https to the userspace Penumbra daemon, a one-time RSA keypair is generated along with an additional AES encryption key. As the upload is received, it is encrypted by the AES key and signed at 4KByte intervals using the RSA private key. Currently the encrypted data is stored in ~8MByte "chunks", which are the units used for storage by penumbrad.

The chunks are named using an ASCII representation of a hash for the upload, eg, 012345678989-00001. There is no indication in the chunk what the original filename was and the content is all obfuscated by the AES encryption.

When the upload is complete, the RSA private key is destroyed, and the RSA public key is stored along with the original filename and the AES key in a small file, with the hash name and a .info suffix. This file is used to advertise the availability of the upload and contains the information needed to confirm it is intact and to decrypt it. All generated files in Penumbra have their timestamp forced to 1970-01-01 00:00 on close.

The purpose of the obfuscation from the AES encryption is to avoid nodes, in the event of an attack on them, from being shown to have possession of plaintext. On an uncontrolled network that content could be anything, and is likely present on the node because it was being "routed" to another node.

Because of the one-time keypair used for signing and the destruction of the private key after upload, there is nothing to show who the content originator was from the moment the upload is complete. The chunks in the cache could equally have come from the broadcast network as the local user. Similarly in the case of multiple uploads from the same user, there is nothing in common between the uploads, eg, no shared key.

See Implementation for full details.

---