The complete microsoft word file can be downloaded
here(as a raw file)
Summary The whole password setup/change process is as follows: 1. The client inputs the user ID and its password in plaintext
2. A
salt for
hashing the password in plaintexts will be randomly generated
3. The password will be combined with a fixed
pepper in the client software source code and the aforementioned
salt, to be
hashed in the client terminal by
SHA3-512 afterwards
4. The
hashed password as a hexadecimal number with 128 digits will be converted to a base 256 number with 64 digits, which will be repeated 8 times in a special manner, and then broken down into a list of 512 literals, each being either numeric literals 1 to 100 or any of the 156 named constants
5. Each of those 512 numeric literals or named constants will be attached with existing numeric literals and named constants via different ways and combinations of additions, subtractions, multiplications and divisions, and the whole attachment process is determined by the fixed
pepper in the client software source code
6. The same attachment process will be repeated, except that this time it's determined by a randomly generated
salt in the client terminal
7. That list of 512 distinct roots, with the ordering among all roots and all their literal expressions preserved, will produce the resultant polynomial equation of degree 512
8. The resultant polynomial equation will be encoded into numbers and number separators in the client terminal
9. The encoded version will be encrypted by
RSA-4096 on the client terminal with a public key there before being sent to the server, which has the private key
10. The server decrypts the encrypted polynomial equation from the client with its
RSA-4096 private key, then decode the decrypted version in the server to recover the original polynomial equation, which will finally be stored there
11. The 2 aforementioned different salts will be encrypted by 2 different
AES-256 keys in the client software source code, and their encrypted versions will be sent to the server to be stored there
12. The time complexity of the whole process, except the
SHA3-512,
RSA-4096 and
AES-256, should be controlled to
quadratic time The whole login process is as follows: 1. The client inputs the user ID and its password in plaintext
2. The client terminal will send the user ID to the server, which will send its corresponding
salts for
hashing the password in plaintexts and forming distinct roots respectively, already encrypted in
AES-256 back to the client terminal, assuming that the user ID from the client does exist in the server(otherwise the login fails and nothing will be sent back from the server)
3. The password will be combined with a fixed
pepper in the client software source code, and the aforementioned
salt that is decrypted in the client terminal using the
AES-256 key in the client software source code, to be
hashed in the client terminal by
SHA3-512 afterwards
4. The
hashed password as a hexadecimal number with 128 digits will be converted to a base 256 number with 64 digits, which will be repeated 8 times in a special manner, and then broken down into a list of 512 literals, each being either numeric literals 1 to 100 or any of the 156 named constants
5. Each of those 512 numeric literals or named constants will be attached with existing numeric literals and named constants via different ways and combinations of additions, subtractions, multiplications and divisions, and the whole attachment process is determined by the fixed
pepper in the client software source code
6. The same attachment process will be repeated, except that this time it's determined by the corresponding
salt sent from the server that is decrypted in the client terminal using a different
AES-256 key in the client software source code
7. That list of 512 distinct roots, with the ordering among all roots and all their literal expressions preserved, will produce the resultant polynomial equation of degree 512
8. The resultant polynomial equation will be encoded into numbers and number separators in the client terminal
9. The encoded version will be encrypted by
RSA-4096 on the client terminal with a public key there before being sent to the server, which has the private key
10. The server decrypts the encrypted polynomial equation from the client with its
RSA-4096 private key, then decode the decrypted version in the server to recover the original polynomial equation
11. Whether the login will succeed depends on if the literal expression of the polynomial equation from the client exactly matches the expected counterpart already stored in the server
12. The time complexity of the whole process, except the
SHA3-512,
RSA-4096 and
AES-256, should be controlled to
quadratic time For an attacker trying to get the raw password in plaintext: 1. If the attacker can only sniff the transmission from the client to the server to get the encoded then encrypted version(which is then encrypted by
RSA-4096) of the polynomial equation, the
salt of its roots, and the counterpart for the password in plaintext, the attacker first have to break
RSA-4096, then the attacker has to figure out the highly secret and obfuscated algorithm to decode those numbers and number separators into the resultant polynomial equation and the way its roots are attached by existing numeric literals and named constants
2. If the attacker has the resultant polynomial equation of degree 512, its roots must be found, but there's no direct formula to do so analytically due to
Abel-Ruffini theorem, and factoring such a polynomial with 156 different named constants efficiently is very, very complicated and convoluted
3. If the attacker has direct access to the server, the expected polynomial equation can be retrieved, but the attacker still has to solve that polynomial equation of degree 512 to find all its roots with the right ordering among them and all their correct literal expressions
4. If the attacker has direct access to the client software source codes, the
pepper for
hashing the password in plaintext, the
pepper used on the polynomial equation roots, and the highly secret and obfuscated algorithm for using them with the
salt counterparts can be retrieved, but it's still far from being able to find all the roots of the expected polynomial equation of degree 512
5. If the attacker has all those roots, the right ordering among them and all their correct literal expressions still have to be figured out, and the
salts and
peppers for those roots has to be properly removed as well
6. If the attacker has all those roots with the right ordering among them, all their correct literal expressions, and
salts and
peppers on them removed, the attacker has effectively recovered the
hashed password, which is mixed with
salts and
peppers in plaintext
7. The attacker then has to figure out the password in plaintext even with the
hashing function,
salt,
pepper, and the highly secret and obfuscated algorithm that combines them known
8. Unless there are really efficient algorithms for every step involved, the time complexity of the whole process can be as high as
factorial time 9. As users are still inputting passwords in plaintexts,
dictionary attacks still work to some extent, but if the users are careless with their
password strengths, then no amount of cryptography will be safe enough
10. Using
numerical methods to find all the roots won't work in most cases, because such methods are unlikely to find those roots analytically, let alone with the right ordering among them and all their right literal expressions, which are needed to produce the resultant polynomial equation with literal expressions exactly matching the expected one
11. Using
rainbow tables won't work well either, because such table would be way too large to be used in practice, due to the number of polynomial equations with degree 512 being unlimited in theory
12. Strictly speaking, the whole password encryption scheme isn't a
one-way function, but the time complexity needed for encryption compared to that for decryption is so trivial that this scheme can act like such a function
Areas demanding further researches: 1. The time complexity for factoring a polynomial of degree n with named constants into n factors analytically
2. Possibilities of
collisions from the ordering among all roots and all their different literal expressions
3. Existence of efficient algorithms on finding the right ordering among all roots and all their right literal expressions
4. Strategies on setting up the fixed
peppers and generating random
salts to form roots with maximum encryption strength
Essentially, the whole approach on using polynomial equations for encryptions is to exploit equations that are easily formed by their analytical solution sets but very hard to solve analytically, especially when exact literal matches, rather than just mathematical identity, are needed to match the expected equations.
So it's not strictly restricted to polynomial equations with a very high degree, but maybe very high order partial differential equations with many variables, complex coefficients and functions accepting complex numbers can also work, because there are no known analytical algorithm on solving such equations yet, but analytical solutions are demanded to reproduce the same partial differential equations with exact literal matches, as long as performing partial differentiations analytically can be efficient enough.