Privacy and confidentiality are essential parts of life
ZAS Security Concepts
(Rev. 0.3 May 9 2014)
This document describes general concepts and constituent blocks of DH crypto library used in ZAS communicator. Refer to the source code for particular details. In case of an inconsistency, source code has precedence over document.
General concept of fail-safe security
- The security should be based on three different algorithms (at least). Total failure of either one of algorithms should not result in a loss of security. The internal working of algorithms should be based on different unrelated structures.
- No algorithms designed, adopted, recommended or otherwise compromised by association with a government. Also, we won't use algorithms designed by control over communication supporters; or protected by copyright.
- Of three algorithms, two should be well studied, time proven and patched if necessary, and the third should be customized and/or home made.
- Long term security requires key strength no less then 256 bits for symmetric ciphers and hash functions, and no less then 4096 bits for public key algorithms and electronic signatures (big number discrete log based). Recent experience shows that 4096 bit number discrete log functions are safe. A public key system with more then 4096 bit key size would be too slow for today's PC.
- Elliptic curve cryptography (ECC) is not used for following reasons:
- Success of quantum computing requires operation in large fields (>1000 bits) This takes away key size and computing speed advantage of ECC.
- Weak curve possibility (deliberate or accidental, hard to prove).
- Copyright and patent restrictions.
- Computation and memory requirements of cryptographic algorithms are unimportant in the ZAS application. Algorithms could be cascaded and number of iterations could be increased to improve security.
- Algorithms should have simple implementation and clear concept.
- We don't use commonplace crypto libraries such as OpenSSL, Crypto++, GPG, etc. for number of technical, copyright and security reasons.
Considering the above, we choose IDEA, XTEA, XXTEA and big number Diffie Hellman key exchange and electronic signature as primary crypto primitives. We also use proprietary nonlinear substitution block cipher.
Number of rounds in the algorithms is increased to provide at least x3 times security against best publicly known attacks.
Diffie - Hellman key exchange
Principal public key algorithm used in ZAS is Diffie - Hellman key exchange (in El Gamal form). Prime modulo for every session is chosen randomly from a table of 360 precomputed safe primes of size of 4096 bits each. It is possible to add more primes or replace existing primes in the table; the communication protocol allows for that.
The 360 precomputed safe primes are made from base of random numbers generated by main pseudorandom generator; there isn't any specific structure in those primes.
At the very beginning of each exchange, a 4095 bit number which acts as generator modulo prime is chosen randomly and checked so it makes full size group modulo selected prime.
The Diffie - Hellman parameters are protected by electronic signature. This averts "man in the middle" class of attacks. The signature uses 256 bit hash of DH parameters.
At the end of successful DH exchange, both sides of the communication link come up to the same 4096 bit number. This number is hashed to 1152 bits (using COLLAPSE function). From those 1152 bits, 576 bits are used for inbound decryption initialization and the other 576 bits are for outbound encryption initialization. Of each 576 bits, 192 bits initialize packet MIC procedure, and 384 bits initialize key stream generator.
This procedure generates strong and unrelated keys for all constituent algorithms.
Identity of the users of the system is protected by electronic signatures. The signature algorithm is based on discrete log function and uses the same base of precomputed 4096 bit safe primes as the Diffie Hellman exchange.
Signature secret key is only secret element of the ZAS cryptosystem. The secret key is stored in encrypted file. The encryption is done by IDEA and XTEA combination in XEX mode (equivalent strength no less then 256 bits). The key for XEX encryption is derived from passphrase and 256 bit random salt using password to key function (PKF).
Open key to verify signature is further referred as certificate. The 256 bit hash of certificate also acts as unique user id in the ZAS network. The certificate is always attached to the signed data; so it could be used for validation.
ZAS does not rely on any public key infrastructure (PKI), as PKI concept is unsafe. Moreover, PKI is dangerous because it creates false impression of security. It is the job of a user of the system to verify that he communicates to a valid correspondent; not a man in the middle.
Password to key function (PKF)
PKF is irreversible function which generates binary key of arbitrary size from password and salt combination of arbitrary size. The function is intentionally slow and memory consuming to complicate brute force and/or dictionary password search. PKF computation takes about 0.1 sec on PC; and requires 1MB of memory. Internal structure of PKF is designed to take lots of hardware resources so to make FPGA realization difficult and slow.
Main hash function (COLLAPSE)
Main hash function generates hash of arbitrary size from data of arbitrary size. The size of hash must be multiple of 128 bits. Hash is computed using variable size block cipher in UBI chaining mode.
Variable size block cipher uses N bit size block and 2N bit size key (N is a multiple of 128 bits). UBI initializes first N bits of key with the output of the previous block, and the remaining key bits are initialized from pseudorandom generator using 64-bit linear congruent function.
The N-bit block cipher has N/32 rounds. That is 4 rounds for 256 bit hash for example. Keys for each round are calculated using custom algorithm.
Each round consists of 4 steps:
- Generate round keys by custom algorithm
- Apply proprietary block cipher
- Apply IDEA blocks to fit the full width of the data
- Apply XXTEA with 66 rounds.
Computing of 256 bit hash out of 4096 bit size Diffie Hellman parameters takes less then 1ms on modern PC.
Stream Cipher (KEYSTREAM)
Stream cipher is used to protect all of communication data. The cipher function is irreversible. So even if enemies discover current state of the cipher, it won't be feasible for them to decode previous data.
The cipher uses total of 384 bits of state information (derived from Diffie Hellman exchange data). All communication links use different, unique and unrelated keys. Keys are also different and unrelated for inbound and outbound transfers.
Stream cipher uses IDEA to generate random sequence, and 256 bit hash function based on XXTEA to encode IDEA key. The 128 bit nonlinear congruent generator is used as counter to produce hash key and IDEA input value.
The speed of generator is over 10 MB/s on modern PC. Stream cipher guarantees sequence period no less then 2131 bytes. The presumed strength is at least 256 bit.
Packet structure and MIC
Each communication packet consists of 64 bit sequential number field, 32 bit data length field, data field with variable length, and 32 bit MIC code to protect message integrity and avoid packet alteration, replay and injection attacks. The data is protected by stream cipher.
MIC is computed over encrypted data as following:
- Hash computation is initialized with 64 bit secret IV.
- The 64 bit hash is computed over data using XTEA function in UBI mode.
- Final hash value is enciphered by IDEA with128 bit secret key.
- The 64 bit word is collapsed to 32 bit MIC by adding upper and lower words.
MIC hash IV and encryption key (total 192 bits) are initialized from Diffie Hellman exchange data. The values of IV and key are different and unique for every communication session; they are different and unrelated for inbound and outbound directions also.
Main generator of random numbers
Main RNG is used to initialize key data for Diffie Hellman exchange, and other sensitive communication session data. The RNG is based on nonlinear feedback structure over 1KB state (seed). A change of any bit of seed will cause avalanche; i.e. the output of RNG would be completely different.
The state is updated by irreversible function before and after generation of every random sequence. This makes impossible recovering previously generated pseudorandom sequence from current state. The state is also updated from entropy collection procedure.
Entropy is collected continuously from different sources and applied to main seed. The main seed is 1KB size. File seed.bin is created automatically. The file is updated at every launch of the ZAS program; however image of seed in memory is updated more often.
Seed updates are done by irreversible function; so it is impossible to recover previous or next state of seed from the current state of seed.
Sources of entropy:
- System provided (/dev/random(), CryptGenRandom())
- Inbound and outbound plaintext data. Plaintext is thought unknown to attacker (at least partially). So the plaintext could be used as source of entropy. Every received or transmitted data packet contributes to seed entropy.
- Keyboard and mouse data are used to add to entropy when generating secret key.
Encryption of ZAS history files
Starting from version 1.6, ZAS chat history files and downloads history file are encrypted. It is impossible to read those files outside of ZAS program without knowledge of user secret key. The encryption is done in XEX mode using IDEA and XTEA algorithms. The 256 bit XEX key and 64 bit IV are calculated by hash function from user secret signing key (of 4096 bit size). Hash calculation is initialized with random salt of 256 bits. The salt value is stored at the beginning of each file, when file is created. So, each file is encrypted differently, with unique IV and key. If a file was deleted, a new file will be created with different salt value, therefore the encryption is going to be different. If a user would generate new secret key, it won't be possible to decrypt old files.
Starting from ZAS version 1.7, all network traffic is obfuscated. The transmitted packets look like random data with random length. There are no identifiable signatures, easily recognizable data fields or typical sizes of packets. Obfuscation doesn't provide additional security to the system. The goal of obfuscation is masking network traffic and avoiding internet blocks.