One commonly asked question is if it is possible to bypass Kiwi by simply striping out the cookie from a email address generated by Kiwi. Bypassing Kiwi is not this simple.
Kiwi rejects emails without a valid cookie. The one exception is a "password" email address that one can give to their friends.
This can be illustrated with an example. Supposing that one's email address is in the form:
mail sent toname+cookie@domain.com
name@domain.com will be discarded. One who
wishes to send you mail without knowing a valid cookie will have to know
your password. If they know your password, they will send mail to an
email address in the form:
name+password@domain.com
The reason to use strong encryption is because security through a system with known security is always stronger than security through obscurity. By using strong encryption, we make it more difficult for a spammer to bypass Kiwi, making them perform more work to send us unwanted email.
The first target platforms for Kiwi are open-source platforms. Kiwi is much easier to implement on an open-source platform, since access to the source allows easy modification of the components that send out mail and news. In addition, open-source platforms are generally more modular, meaning that the changes Kiwi makes impact less programs, making debugging easier.
The full specification to Kiwi is available for programmers who make closed-source mail and news user agents for Windows. Those programmers are free to incorporate Kiwi compatibility in to their programs. The specification and software is in the public domain, and infringes on no patents.
Since I do not have access to the source of closed-sourced applications, I can not enhance these applications to have Kiwi compatibility.
There are a number of practical problems with using a database.
A database will take more machine resources than the cipher Kiwi uses, and will become slower and less efficient as we add new records to the database. The cipher that Kiwi uses, on the other hand, uses less than 50 lines of C code, using no loops. The cipher runs at a constant, very fast, speed, and places a minimum of load on a mail server. Kiwi would still stay practical if dozens upon dozens of emails were being delivered every second, each one being processed by Kiwi. The same thing can not be said for a database implementation.
A database will have to be synchronized between the machine we send mail from, the machine we post news from, the machine we serve our web pages from, the machine that we receive mail from, and any other machine that we make our email address public from. This could require that a single machine, whose purpose it is to synchronize the database, would have to be up whenever we sent an email, posted to Usenet, or have someone grab an email address from our web page. The database would have to be accessible from all machines. These factors make a database less reliable than the current system Kiwi uses.
A database would violate the principle of simplicity of code that can run with a minimum of system resources. These factors far outweigh any potential benefit we would get from running a database.
Yes.
The ITAR regulations that stopped people from exporting crypto software are, for all intents and purposes, no more. Yipee!