Use kerl's method to convert from trytes to bytes

[vbakke]

Current implementation uses vbakke/trytes to convert the seed (trytes) to bytes.

It should use the well accepted ioteledger/iota.lib.js's implementation in kerl to convert the trytes to bytes.

[vbakke]

There are a few drawbacks with both the kerl method and the vbakke/trytes method.

Avaliability

A definite drawback with kerl is that functionality is not exposed in the iota.lib.js library, A kerl based solution must therefore utilise internal workings of the library, or duplicate the algorithm.

The secure encryption methods all are binary (and not ternary). Converting from trytes to bytes is fairly straight forward, only using a subset of the full byte range.

But the encrypted version may use the full byte range (0-255), and it will never fit back into the same number of trytes.

The vbakke/trytes method solves this by increasing the 81 tryte chars to 100 tryte chars (ref https://vbakke.github.io/trytes/).

The kerl method solves this within the 81 tryte chars. However, I have not checked how many cases (if any) that will break. An IOTA seed (after curl was substituded by kerl), is actually only 80 trytes and 2 trits (not 3). Meaning it is only using a third of the full range. If that is enough to accept every combinations of the 384 bits, I have not checked, yet. It may cause a problem for a limited number of encryptions.

And it will, at least, cause a problem with the current implementation in kerl, that slams the last trit to zero.

[vbakke]

I've checked out a bit more about using the kerl method to create the binary key for encryption.

AES can only encrypt binary data. We can use the kerl method or the vbakke/trytes method to convert the tryte seed to bytes. Kerl gives 48 bytes, vbakee/trytes gives 50 bytes.

AES encryption keep the number of bytes. so far, no big difference. But now we get into the old fit the square peg in the round hole problem.

The encrypted bytes, use the full range of their bytes values.

Reverse kerl
The Kerl conversion produces only a subset of the all possible values in the 48 bytes.
All binary values outside of the original tryte range, cannot be converted back to a 81 tryte string, without creating a collision with other seeds.

The Kerl method slams the last trit to 0, to allow the range of seeds to fit inside 48 bytes. Reverting a seed, will possible have a different last tryte letter. This has no technical significance, since the same Kerl method is used for IOTA computations. It has only a psychological downside.

The Kerl method has a collision with the seed 99999...99999, and NNNNN...NNNNN. But I don't see that as any problem at all.

Reverse vbakke/trytes
The vbakke/trytes is designed to encode and decode any arbitrary length tryte stings, with exact match.

However, I will require more that the original 81 tryte characters.

Conclusion
Using Kerl is fine for encoding trytes as bytes. But for creating a tryte string from the bytes, we need to use some other method.

Currently Kerl's method of converting the tryte seed into bytes is not exposed in iotaledger/iota.lib.js.

Therefore, I will vote for using vbakke/trytes to convert between trytes and bytes.

I'm open for other suggestions, though. For example, we don't need to convert the encrypted bytes back to trytes, at all. A QR code would actually end up smaller, containing 48 bytes, than 100 alphanum characters.