bindhast.com : keylilla

`keylilla' is a keyless protocol for secure exchange of files between two correspondents. In this protocol, both the originator and the recipient use one single common programme, `keylilla'.

Secure transmission of a single file from the originator to the recipient requires four `runs' of `keylilla'. Each of these is called a `step'. The two correspondents alternate to sequentially execute the 4 steps. The invocations for the four steps have identical syntax; the programme determines which computations to perform during each step. The file-exchange is complete when the recipient completes the execution of step4.

During the protocol, 3 transmissions of intermediate files occur between the two correspondents. In order to intercept the message, the eavesdropping agency will have to intercept all three transmissions. AND they'll also need to know the algorythm.

(It is easy for each pair-of-correspondents to keep changing the algorythm. This is done through 8 parameters in the source-code: byte[addtag], bytes nn[1-6], and word[seema].)

`keylilla' is not a `public key' procedure. Nor is it a `secret key' procedure. The two correspondents do not share any pre-arranged secret key. Also, no keys are exchanged during the entire protocol. At each correspondent's, the programme creates a (local) random key, to be used during the two steps performed by that correspondent. The local key is automatically destroyed when its owner completes her/his two steps.

`keylilla' is fully self-contained; i.e. it contains its own privacy schemes, and does not need to `trust' anyone about the un-breakability of their high-math algorythms. The local keys change with every execution of the `keylilla' protocol.

`keylilla' turns out to be not quite a modification of Shamir's three-pass protocol. There is no authentication scheme here. As expected, this version will fall to a man-in-the-middle attack (iff the attacker also has access to the particular algorythm being used).

Secret-key communication programmes, such as BYOP, have to face the problem of a secure exchange of keys. Users of BYOP, for example, will need to securely exchange a BYOP script. That bash-script will be their `key'. `keylilla' can be useful for a secure exchange of BYOP scripts. (BYOP -- Build Your Own Privacy -- is also licensed under the GPL. It is available for download here).

The `messagefile' being exchanged via `keylilla' can also be a simple ascii text file, a binary, or any other kind of file. There is no restriction on the type of the messagefile.

It may be said that `keylilla' can be a part of a dispersed, low-intensity, 'cottage-industry' of privacy protection.

`keylilla' is licensed to you under the GNU General Public Licence, GPL. The source-code is provided in the file keylilla.nsm.

Ayesha, the originator, has an important file, `m'. She wishes to securely send `m' to Bashir, the recipient.

@ The outfilenames [`rndmj.xtj', j=1,2,3] are internally generated by the programme.

note: Steps 1,2,3,4 must be invoked from the directory keylilla/ , and all 4 invocations have the form
$ ./keylilla infilename

The name `keylilla' was formed from a short sentence in a highly developed (and rich) regional language. The sentence has two words: `keyli' and `illa'. These could be translated into the English words `lock' and `none'. The name can also be looked upon as a bilingual pun -- meaning `no key'.

The two versions are fully compatible. However, the dos
version is limited to messagefile sizes of about 60 kBytes.

Step No.	Performer	infile name	outfile name @	comments

0	Ayesha	---	---	Create messagefile 'm'
1	Ayesha	'm'	'rndm1.xt1'	Send outfile to Bashir
2	Bashir	'rndm1.xt1'	'rndm2.xt2'	Send outfile to Ayesha
3	Ayesha	'rndm2.xt2'	'rndm3.xt3'	Send outfile to Bashir
4	Bashir	'rndm3.xt3'	'm'	'm' received; end of exchange.