-
Notifications
You must be signed in to change notification settings - Fork 3
Schemes
Below are descriptions of the various encoding schemes. Various details will be gone over to describe how they each function.
Each framed segment that is sent by an encoding scheme will have a 4-byte header. This header will include a 16-bit sequence, an 8-bit of Session ID, a 4-bit flag field, a 4-bit nonce value. See below:
F E D C B A 9 8 7 6 5 4 3 2 1 0
Byte 0 | Sequence Number |
Byte 2 | Session Num | Flags | Nonce |
Flags are simple, at the moment. There is only the "More" bit at the moment. It is the highest order bit in the Flags field (bit 7 in byte 3, above). It indicates that there is more to be read in this transfer.
The URL encoding scheme is designed to look like a personalized advertising/tracking link. Within it, there are 40 bytes that can be used, represented by an 80 character hex-encoded string.
This is implemented in the initial release.
This is a very basic encoding that consists of a proper header that defines the size of the file, and the raw data providing the bitmap itself. This will be produce a noise filled bitmap, but will be a valid image file.
Additional metadata can be stored within the bitmap itself, such as the sequence number, number of padding bytes, and the like.
This is not implemented in the initial release. REVISIT
This encoding is to provide an image format for the Tor bridge's side to provide data back to the client. This is similar to the bitmap format, but is different insofar as it is encoded as a Lossless JPG.
This is implemented in the initial release.
First, a proper bitmap will be created (see section above). This is then translated by ImageMagick's routines to be a Lossless JPG. This is then sent out to the client.
Decoding is only slightly more difficult then the encoding. First, the Lossless JPG is converted back to a bitmap, again using ImageMagick. From here, the bitmap's header is parsed, to find the offset for the bitmap data. The bitmap data is then parsed out for metadata (e.g., sequence number, data length) and actual data.
This is a more unique idea. Since SVGs are XML documents, pretty much anything can be put into it. It includes the ability to have raster images (such as JPGs and bitmaps), which could be created using variants of the previous methods, text, which can be encoded similar to how URLs are encoded, and property fields for the vectors parts of the image, which can also be a location for data.
This is not well developed at this point, but should provide potential for encoding information more discretely.
This is not implemented in the initial release.
In this scheme, data will be hidden in a generic HTML page. Essentially, the frame will be serialized with HTML elements and English words as the storage medium. For instance, the word 'the' might represent the byte 0xAA and the element '<div>' might represent the byte 0x34 so the HTML content '<div>the</div>' would represent 0xAA34.
This is not implemented in the initial release.