[lifthrasiir]

> Basically cryptography means secure plaintext replaced with it by some other thing and you should be able to make inverse replacation proccess as well (decryption) this function should be based on mathematical theories or methods.

Under your definition cryptographic hash algorithms [1] and digital signatures [2] are not cryptographic.

> I think you are not familiar with the cryptography concepts in general trends because today the most of data breaches become dangerous if the encrpyted part decrypts by the hackers, so that is why we should avoid typical approaches.

Your claim suggests that you are not familiar with cryptography at all. Modern cryptographic algorithms are parameterized with keys in a way that knowing the algorithm doesn't give adversaries much hint---you just have to keep keys safe. By comparison knowing that your algorithm is in use allows the complete decryption. This is...

> If you have an important data, you should protect it by an well-developed algorithm.

...what I referred by a "complex" approach. Existing algorithms are complex by themselves, but have well-defined interfaces and guarantees that you don't have to care about its innards. But rolling your own crypto means you have to care about its innards, thus more complex.

[1] https://en.wikipedia.org/wiki/Cryptographic_hash_function

[2] https://en.wikipedia.org/wiki/Digital_signature

[kronxe]

Basically hash functions are not reversible that is why we call them as cryptographic hash function and my algorithm is cryptographic encryption function (which has a reverse). Also digital signature has a math behind I could not understand what the problem is here. [1]

> Your claim suggests that you are not familiar with cryptography at all. Modern cryptographic algorithms are parameterized with keys in a way that knowing the algorithm doesn't give adversaries much hint---you just have to keep keys safe. By comparison knowing that your algorithm is in use allows the complete decryption.

Have you got an experience in data encryption for databases or related ? My point is your function may used by other people, for example: If a hacker reached db of website, and tried to find the keys of encryption. He can make brute force trial to accomplish it or some analysis. There is lots of field that used cryptography like e2e encryption in communication applications or cryp. hash functions like md5 in databases. This field is very broad, it does not focus on just one subject.

[1] https://miro.medium.com/max/1272/1*sc0fhLXdwc2WRzGRDAfkcQ.pn...

[lifthrasiir]

> Have you got an experience in data encryption for databases or related ?

Yes, I worked on online game servers, encrypted protocols and of course encrypted databases (required by the law). There were no keys stored in the database nor in our code, we had a dedicated encryption server that holds them. (Nowadays we would use AWS KMS or similar services.) Our keys were far longer than what is brute-forcable as well. In fact if something is brute forcable your response should be increasing key length (at the very least 128 bits or more), not changing algorithms to some obscure home-made one.

[kronxe]

I see and I understand your point but I want to say the cllasical approaches are more stable but more unsafe. By the way, there is no something that non brute-forcable today, increasing proccesing power and quantum computing allows it. I think we look some different specific fields. 'Home-made' algorithms certainly gives much more safety because people cannot attack if they dont know how it works. For example, in my algorithm I used ideas of prime numbers and also changing the order of the characters but maybe some other people use turn bytes into bcd values and than make some change for complexity. My algorithm is one of the example of trying to use some other method different than standard encryption with key.

[lifthrasiir]

> By the way, there is no something that non brute-forcable today, increasing proccesing power and quantum computing allows it.

See, you don't know anything about cryptography. Quantum computing (which is currently very experimental) aside, 2^128 is not something you can brute force today and even in a near future. Let's see why.

Bitcoin is something very close to the most performant globally distributed computing system, and its hash rate is about 3 x 10^20 SHA-256 hashes per second (since Bitcoin PoW uses double SHA-256, a commonly cited hash rate is a half the actual hash rate). Therefore we can reasonably assume that we can do the order of 10^22 decryptions per second today. Note that this hash rate is increasing, but now in a roughly linear rate (currently about 10^20 hashes per second per year) so this assumption should be not too off. Given 2^128 / 10^22 = 3.4 x 10^16 seconds = 10^9 years, it is clearly not brute-forcable today.

Quantum computing is also not a magical sauce. QC poses a problem to the cryptography mainly because some cryptographic algorithms relied on currently hard problems like integer factorization and they can be efficiently solved by quantum computers. Post-quantum cryptography (PQC) thus seeks for alternative problems that would be still hard for quantum computers. More importantly though, symmetric encryption does not make use of such hard problems, so the potential speedup is only possible with Grover's algorithm that searches N records in sqrt(N) time. Quantum computing thus does make 128-bit keys unsafe (since it will only take the order of 2^64 operations to brute force). But by then we can simply double the key length to restore the difficulty.

> For example, in my algorithm I used ideas of prime numbers and also changing the order of the characters but maybe some other people use turn bytes into bcd values and than make some change for complexity.

Your algorithm, as I can see, is equivalent to a Vigenère cipher with implicit character mapping generated from prime numbers. The practical cryptanalysis of Vigenère cipher (Kasiski examination) appeared in mid-19th century. Using prime numbers doesn't make your algorithm automatically safe.

[kronxe]

I dont want to discuss this issue too much but maybe you can check that what is the ongoing problems about bitcoin's p=np problem, is 2140 a realistic target and is your calculation still applicable for today.

Also, I recommend you to read Google's quantum paper and quantum attacks on some sort of cryptography things.

If we think about today, we cannot catch up new techs, we should think about future. That is why technology is growing exponential.

[lifthrasiir]

Yes I haven't claimed that it will last forever. But you have claimed "there is no something that non brute-forcable today" haven't you? 2140 is not "today" nor a near future. In fact it is more likely that a flaw is found in existing algorithms before 2140. Do you make your system last that long? Then you would want to avoid algorithms already broken in 19th century.