OTP4U algorithm

This paper contains 3 paragraphs:
1. Introduction
2. Considerations about the security of OTP4U
3. Pseudo-code algorithm (with figures)
3.1. Changes in the 0.8.2 release
3.2. Known-plaintext attack

1. Introduction

OTP4U (One Time Pad for you) is a new crypto-system which provides an easy to use cipher, very similar to the One Time Pad, which is the only known unbreakable cipher. If OTP4U probably is not unbreakable, it seems that the only attack against it is a brute force attack. A known-plaintext attack, as explained below, should be infeasible. The Java open source implementation provided in my site is a demonstration of OTP4U and is also the best description for the algorithm for anyone that knows the Java language. For everyone else, below I have provided many pseudo-code lines, and I hope this will help understanding the algorithm.
The idea of OTP4U is similar to that of Sysepub, which inspired OTP4U and from which it has been partly derived.
Like a One Time Pad (OTP), OTP4U uses a key made of truly random bytes, that are used to generate an array to which the plaintext is XORed to obtain the ciphertext. The great limitation of the OTP is that "Alice and Bob" have to share the key between them; the key must be of the same length of the plaintext, so a secure channel is needed to exchange the key.
The main goal of OTP4U is to make the key exchange simpler. Thus, instead of using a secure channel to exchange a large amount of random bytes when needed, Alice and Bob will need a secure channel only the first time, when they start the process. They will need to share only a little random byte array (say of very few K-Bytes); let's call this array K4K0 (Key for Key 0, as it will be used to transmit securely another key).

Once that K4K0 has been shared, let's see how Alice and Bob proceed.
Supposing that Alice has got a truly Random Number Generator RNG (used also to generate K4K0), she generates the bytes that will be used as the OTP-key (K4M1, Key for Message 1) and she generates also another byte array (p0, called "public" key, in the sense that is not secret) that she will send, on an insecure channel, to Bob. And only Bob will be able to obtain K4M1 from p0, because to do this the only way is using K4K0, that is secret.
The Java class used to manage the key "enciphering/deciphering" is called KeyManager. It's an abstract class, so it allows multiple subclasses to implement it. The OTP4U main class is designed to be able to dinamically instantiate a particular key manager at runtime, with the aim of simplifying and encouraging the writing of new key managers. This release includes two different impementations of KeyManager: KM_Permutation and KM_Xor.
The first obtains K4M1 and K4K1 from the "public" key p0, with a permutation of its bytes. This permutation is quite random, and an adversary could not obtain it, as it is determined from the byte values of the "public" key itself and of K4K0 (secret)(detailed pseudo-code description below).
The second implementation instead uses K4Kn to generate a new array that is XORed to the random stream r0 to "encipher" it and generate the "public" key p0. This second method seems as secure as the first, but it's less performing, as it requires that the length of the encrypted (public) key is at least two times the length of the plaintext. In certain cases this would be a problem, but in many cases this is not.
Alice generates exactly l random bytes (where l = 2*K4K0.length) in the array r0 with the RNG. Now she enciphers r0 using K4K0 as key and obtaining p0 (detailed pseudo-code description below).
Now Alice sends to Bob on an insecure channel p0, from which he is able to recover r0.
Finally Alice and Bob split r0 in two arrays: the right end (K4K1) and the left end, that will be used to generate K4M1. K4K1 will be used in the next iteration of the process to exchange r1, and K4M1 contains the truly random bytes that will be used as key for the OTP-like encryption of their plaintexts (i.e.: ciphertext = plaintext XOR K4M1).
Getting the ciphertext

There are many possible ways for exchanging K4K0: I suggest the use of a Criptographically Secure Pseudo-Random Number Generator (CSPRNG) to encipher K4K0, or other existing systems that can be useful for a key exchange (like those in public key schemes); the present implementation of OTP4U assumes that the users start with K4K0 already shared.
Finally, there is also an OTP4U variant (not yet implemented) based upon the use of a CSPRNG to encipher the random bytes of r0; in this way Alice and Bob can use all the bytes of r0 (not only the half of the array, like KM_Xor), however the security of this variant depends on the level of security of the CSPRNG. Again, the pseudo-code description can be found below.

2. Considerations about the security of OTP4U

The use of a RNG (instead of a PRNG) makes the OTP unbreakable: the ciphertext could be obtained from any plaintext with the same probability, thus it gives absolutely no information about the real plaintext.
Now, let's see the information that an adversary C of Alice and Bob can get, and what he could obtain from it.
The first array that C could get is p0: this should appear to him absolutely random, in any case.
In the KM_Permutation variant, he knows that with a permutation of its bytes he could obtain K4M1 concatenated with K4K1. But the number N(n) of permutations of an array of length n is a very large number: if there were n distinct objects this number would be n! , but normally a byte array has every possible byte value repeated several times, so N(n) is smaller (because some permutations act on identical byte values, so they are equivalent and they have to be excluded from the count), anyway too large even for the fastest computer. To have an idea of the dimension of N(n), consider the asymptotical function:
f(n) = n! / ((n/256)!)^256
f(n) counts the number of permutations of a byte array of length n (multiple of 256), in which the 256 possible byte values have an uniform distribution (every value occurs exactly n/256 times). The denominator counts the permutations to be discarded. Some examples: f(512) has 1089 digits, f(1024) has 2286 digits, etc..
f(n) is "asymptotical" to N(n) because a randomly generated byte array tends to have an uniform distrubution of its bytes, so f(n) can be taken as a good approximation of N(n).
Also a brute force attack on K4K0 is infeasible if K4K0 is long enough: a length of only 1 KB implies a keyspace of 256^1024 = 2^8192, a number of 2466 digits!
About the KM_XOR variant: here p0 comes from the XOR between r0 and concat(K4K0, A(K4K0, r0Left) (see below)). In fact, r0 is the "purest" random array, as the second term of the XOR could show some little organization inside; but, having only p0, there's no way to obtain the two terms of this XOR.
Another array that C could get is for example: ciphertext1 = plaintext1 XOR K4M1
In the KM_Permutation variant K4M1 comes from a random permutation of the truly random array p0, and in the KM_Xor variant K4M1 is permutation(K4K0, r0Right) (see below). Hence if a RNG was used, K4M1 still looks really random and the security of plaintext1 is absolute: a ciphertext-only attack is infeasible under this assumption.
Finally, C could try a known-plaintext attack: the discussion of this case requires some pseudo-code explanations, which can be found at the end of this paper.

I guess the following notations are obvious:
byte[] is a byte array; x.length is the length of the byte[] x
XOR between two byte array (of the same length) is equivalent to XORing byte per byte from the first to the last byte.
A byte value can be considered also as an integer from -128 to 127.
% is the modulo: a%n is the same of a mod n; for simplicity I assume that always is: a mod n >= 0
= is assignation, not equality

3. Pseudo-Code Algorithms

Here are presented the algorithms of two key managers, provided within OTP4U. Anyway, I think some improvements still can be done. New proposals, or new implementations of KeyManager, are welcome (after all, contributions are fundamental in open source projects). Let's start with the key manager based on the permutation.