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!
Is there a Windows version of Kiwi available?
Why use encryption at all? Why not a cryptographically secure
psudo-random number in conjunction with a database?
Is it legal for you to release this code to the international
community?