m-o-o-t Product Notes

m-o-o-t will consist of one CD which will boot on as many computers as possible. There will be a suite of email , w/p, spreadsheet, graphics etc programs on the CD. Access to local storage (hard drives etc.) will be disabled , and the system will shut down if the CD is removed . Data and mail will be transmitted and stored in encrypted form split between off-shore data havens.

m-o-o-t will not be compatible with any other security software . m-o-o-t will not interfere with the normal use of the computer .

It will be secure ( with the usual caveats about security) against RIPA, Carnivore, the Australian and proposed Council of Europe and NZ laws regarding seizure of stored data, intercepted data, traffic data and access to plaintext /keys of encrypted data.

product


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.

Notes

one
a) so we can get the system to shut down if the CD is removed
b) we will use the CD as a large look-up table to ensure authenticity of the CD and prevent fake CD's with backdoors etc., to ensure that your correspondants are using a secure implementation of m-o-o-t and not software running on an insecure operating system, and as part of a strategy to prevent meaconing and man-in-the-middle attacks
c) for users convenience - we want users to be able to use it intuitively, even if they know next to nothing about computers
d) we will not do updates due do the insecurity of distribution methods and to avoid incompatibilities, although we might bring out a new program in a few years time to account for hardware or cryptographic developments, or if the thrust of the laws changes
top

CD:
a) almost all computers have CD readers
b) CD is read only if the correct medium is used
c) CD is fast enough and large enough to suit our purposes (tho' it'll be a struggle to fit it in)
d) the only executables will be on the read-only CD (no scripts, applets or other executables) to deter viruses, backdoors and trojans etc.
top

boot:
a) (almost) all operating systems use temporary files, cache files etc. which are available on the hard drive, even if deleted
b) a clean boot leaves the computer in a known state and deters access to viruses and trojans
top

as many computers as possible:
a) we want everybody to be able to communicate and store data securely
b) wide availability might make people more aware of the importance of privacy
c) the more users there are the harder it is to target those who use it
top

suite:
a) it will be more like one big program with a common user interface to make it easy to use
b) so we can ensure that the programs act securely
c) so there are no compatibility issues anywhere
d) to provide a common output interface to the cryptography and thence to the outside world
top

email:
a) email will not be traceable, in fact it will be impossible for others to distinguish between email and other traffic or measure the amount of email
top

w/p, spreadsheet, graphics etc:
a) note there will be no web browser as it is not possible to implement one securely
top

Access to local storage (hard drives etc.) will be disabled:
a) so if a computer is seized there will be nothing to find
b) to prevent trojans, backdoors etc on local storage from executing
top

The system will shut down if the CD is removed:
a) to deter people from using insecure add-on programs. Security depends on both ends of a communication channel and if your correspondent's security measures are blown then so are yours
b) to provide a quick and easy way to delete data in RAM - just press the eject button
top

transmitted:
a) encrypted to prevent reading interceptions and outgoing email addresses, of course
top

stored in encrypted form:
a) to prevent the data havens reading it
b) for deniability even if all the data havens are compromised - an added layer of encryption for defence in depth
top

split:
a) so if a data haven is compromised the damage will be limited to (incomplete) traffic data
b) split any-m-of-n to prevent denial-of-service attacks
top

off-shore data havens:
a) there aren't many yet but we should be able to find enough to split data any-m-of-n
b) they make it harder to demand raw data, but we will not ultimately rely on them not to do so
c) they don't actually have to be in the sea(!), just in countries where access can't be demanded
top

It will not be compatible with any other security software:
a) deliberately so in order to discourage insecure implementations of Moot!-like software and to ensure that the person on the other end is secure too. If he isn't, your communications aren't secure. We don't yet know if it will be free, we would like it to be, but it will be a condition that a paid user (if there are any) can burn a CD for his friends to communicate with him
top

Moot will not interfere with the normal use of the computer:
a) we may have to slightly change the startup procedures on some computers (perhaps on Macs, probably not on PC's) but that's all
top

with the usual caveats about security:
a) there are lots of these - no cyphersystem is secure against an over-the-shoulder blonde - but we will clearly state the known risks and minimise them as far as we can
top

against RIPA, Carnivore, the Australian and proposed Council of Europe and NZ laws:
a) this is our goal and is feasible, but as the situation is so complicated and the laws change almost daily the most we can guarantee is security against these as presently understood by us
b) we intend to produce a definitive guide to which laws Moot! circumvents, or as definitive as the lawyers allow
top

seizure of stored data:
a) there is no stored data on your computer to seize
b) data in data havens will be protected by i) the legal inability to access it ii) being split between havens iii) being encrypted iv) being stenographically hidden v) it's existance being deniable vi) the data itself being deniably encrypted vii) in the case of RIPA some legal fol-de-rol involving signature keys
top

intercepted data:
a) interceptions will be encrypted using short-term keys
b) interceptions will not be identifiable - all sent data will be padded to fixed lengths and mixed with random data
top

traffic data:
a) all headers that are encrypted using short-term keys except those of the data havens and the user
b) data is padded or split to fixed lengths
c) data is mixed with random amounts of random data going in both directions (a "bodyguard of lies") so
d) the most that can be determined is that you may have traffic
top

access to plaintext:
1) intercepted data
a) intercepted data is not identifiable even by the user as it was encrypted using deleted short-term keys, padded to length and mixed with a random amount of random data from multiple sources
b) intercepted data is not decipherable even by the user as it was encrypted using deleted short-term keys
c) decryptions of interceptions are deniable anyway

2) seized data (if enough data havens are compromised)
a) being stenographically hidden in random data
b) the data itself is deniably encrypted
top

access to /keys:
1) intercepted data
a) intercepted data is not identifiable even by the user
b) intercepted data is encrypted using deleted short-term keys
c) decryptions of interceptions are deniable anyway

2) seized data (if enough data havens are compromised)
a) being stenographically hidden in random data it's existance is deniable
b) the data itself is deniably encrypted
top


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.