Our encryption is based on Java and everywhere we check buffer overflows and possible timing-attacks. Hopefully we use AES and SHA256 that is easy to validate. 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.

US-based encryption is taken directly from BouncyCastle, time-proven library for Java. Russian implementation can contain bugs, yes, but i can guarantee that there are no timing or overflow attacks possible. Even when we will have broken russian layer, us layer will be safe. Also we are on the way to make everything verified by 3rd parties and seal cryptography parts.

For key exchange we use curve25519. Implementation is taken directly from Signal and this app is trusted by majority.

We

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.