Ok. But why use AES and GOST? AFAIK they're both based on feistel networks? If one were to layer two symmetric encryption schemes today I'd think one would go with something like salsa[ed:chacha] and keccak (in authenticated encryption mode) -- and it would probably still be a bad idea, adding much more complexity than security?

[ed: Oh, and here I go, proving that non-cryptographer should be careful about what they say wrt encryption, apparently AES isn't a feistel cipher? http://crypto.stackexchange.com/questions/10605/why-is-aes-n... ]

> Also Instead of using N code bases (one for each platform) we reduce it's amount by conversing sources from java to other languages for every platform.

It's a pretty strong claim to say that you take three different encryption primitives, implemented by other people in java, and translate them to other languages -- and can also be sure there are no timing attacks? (Or oracles, or resulting errors)?

Surely it would be easier to stick to as few lines and layers as possible if you want it to be easy(er) to audit?

(So simple there's obviously no mistakes, vs so complex there's no obvious mistakes and all that).

I will let you know when we will complete audit of our crypto.

You're not helping your case. You make it sound like you are using bricks without knowing what their strength is.

It's a bit like saying you made a boat out of wood for buoyancy and filled it with sand in case the wood catches fire. Sure, a plank of wood doesn't sink, but too much sand can make it sink, and sand won't be of much help if there is a fire. A wooden boat is better than one filled with sand.

I'm not sure how the fact that the boat was made in Java is relevant, either. If anything, it makes it harder to prove that there is no timing attack, as the JIT could do unexpected things, long after the program has started.

Agreed. One OT nitpick: The fire-quenching properties of sand is actually somewhat different to that of water - eg in case of burning fuel/oil.