m-o-o-t Cryptography Notes

As we consider all present protocols insecure against the new attacks brought about by legislation , we are not going to use any of them. The crypto layer will interface between the application programs and the comms and will use nine algorithms. There will only be one choice for each type of algorithm. We haven't chosen them yet.

All comms between users and havens will be encrypted in a symmetric algorithm using short-term keys derived from a signed key-exchange protocol . All comms will be padded to fixed length blocks and mixed with random amounts of random data blocks and fake "housekeeping" traffic . Email will be treated the same way but will also use authenticated ephemeral keys for forward secrecy.

Data will be stored symmetrically encrypted with a last-ditch key , encrypted with a deniable cypher , hidden stenographically in fixed-size blocks of random data and split m-of-n between data havens . It will undergo a further encryption when it is being transmitted . Defence in depth . Only the symmetric transmission cypher , it's key exhange, server certification and some email forwarding tasks will be done by the server.


main page . product . code . cryptography . security . FAQ

You can contact us here
You can join our mailing list m-o-o-t here. It's low volume and technical.


all present protocols insecure
Yes, all of them. We'd be interested in hearing of one that is secure, but we're bored looking. Some can be secure in limited circumstances and with limited usage, but we're trying to write a program for the masses who don't understand the limitations of eg SSL with EDH-RSA-DES-CBC3-SHA (depends who your server is, got temp files? etc...) top

new attacks brought about by legislation
Increased interception and demands for keys, plaintext etc. A similar situation arose in relation to the telegraph but eventually people were able to use cryptography there, and the economic realities will eventually ensure that no matter what Law Enforcement wants, people will be able to use unbreakable codes. Anyway, cryptology has passed the bounds of legislation. top

interface between the application programs and the comms
We want it to go comms-crypto-apps to keep nasty sneaky programs out. No executables except what's on the CD, we will have a common interface between the apps and the crypto and another between the crypto and the comms and use both as walls top

nine algorithms.
i) a signature scheme ii) a symmetric algorithm iii) a signed Diffie-Hellman type key exchange iv) a variation of this to provide forward secrecy for emails v) an m-of-n algorithm vii) a stego algorithm viii) a deniable algorithm ix) a hash. There will also be a RNG. top

one choice for each type
We think that most programs offer too much choice in this and thus lose security as people don't know what is happening or how secure the algorithms being used are, often they don't know what they are and they may be using eg export grade cyphers. top

symmetric algorithm
Our main algorithm, also used for the last-ditch defence. We may use a variation of a popular algorithm rather than the popular algorithm itself - maybe change s-boxes or something - to ensure incompatibility with other security products. Why do we want to be incompatible? If your system is insecure (we consider all present systems insecure), then if we're talking to you we can't be secure. So we make m-o-o-t incompatible and we can't talk insecurely. top

short-term keys
So we can delete them to provide forward secrecy. top

To prevent meaconing and man-in-the-middle attacks, also there is an issue about signature keys that is interesting and relevant to RIPA in particular, though the issue applies worldwide. See the FAQ for more details top

key-exchange protocol
eg Diffie-Hellman. top

padded to fixed length blocks
To make them indistinguishable from... top

random amounts
"a bodyguard... top

random data blocks
...of lies" top

fake "housekeeping" traffic
shorter messages requesting files etc top

the same way
most relevently, the address of the recipient will be encoded too to prevent traffic analysis top

authenticated ephemeral keys
eg if you want to send me email you ask for a signed Diffie-Hellman key which i left in the server. When I read my email I retreive the private part which is held encrypted in my files and then delete it. top

last-ditch key
If all else fails and it's cheaper for you to go to jail than to give up your secrets. top

deniable cypher
Working on this, it may be too high-tech and/or patented etc, so no guarantees here yet. We are also working on a process to perform the deniable, stego and m-of-n stages in one go. top

hidden stenographically
Demands for raw stego are randomised. As data is symetrically encrypted with the last-ditch cypher before hiding it looks random... top

fixed-size blocks of random data
...which makes it harder to distinguish from the random data in the blocks. They are fixed size so no information can be reliably adduced from knowing their size except perhaps how much you pay the data havens. top

split m-of-n
so you don't have to trust one haven to keep your secrets and to prevent denial-of-service attacks. top

data havens
We use data havens because a) 80% of useful data comes from seized computers (FBI), reducing to none if no hard drives are used
b) it makes it harder to determine the amount of data held
c) for instance it denies access to the raw steganographic text. top

a further encryption when it is being transmitted
this is the short-term key encypherment using D-H key exchange. top

Defence in depth
It's often regarded as unnecessary in crypto work but why not use a concept like this? It might help and it's doing no harm. top

Only the symmetric transmission cypher, it's key exhange
a) so we don't have to trust the server too much b) to lighten the server load top

some email forwarding tasks
eg distributing D-H keys

main page . product . code . cryptography . security . FAQ

You can contact us here
You can join our mailing list m-o-o-t here. It's low volume and technical.