Page 1 of 1 [ 9 posts ] 

gabemai314
Blue Jay
Blue Jay

User avatar

Joined: 12 Feb 2017
Age: 25
Gender: Male
Posts: 76
Location: Loveland, Colorado, USA, Earth, Solar System, Gould Belt, Orion Arm, Milky Way Galaxy, Local Group, Virgo Supercluster, Laniakea Supercluster, Universe

01 Aug 2017, 8:44 am

I have designed and implemented a version of the Rijndael cipher (Advanced Encryption Standard) that uses a 3 dimensional 8x8x8 state (temporary buffer) instead of a 2 dimensional 4x4 state. This means the cipher will have a key size of 4096 bits. It uses 64 rounds for encryption and decryption. The cipher also includes new transformations called ShiftSlices and MixSlices that add additional diffusion into the cipher. These transformations are analogous to ShiftRows and MixColumns. I have a working implementation of the cipher that I wrote in C. I have also implemented various modes of operation such as ECB, PCBC, and XEX. Seeing that quantum computers will only halve the bit-strength of an algorithm, reducing the key size to 2048 bits, the three-letter agencies are surely going to have a field day with this one. Try brute-forcing the keys before the universe reaches heat death! :lol:


_________________
I am open to PMs.
GitHub: https://github.com/gabemaiberger/


Ichinin
Veteran
Veteran

User avatar

Joined: 3 Apr 2009
Gender: Male
Posts: 3,653
Location: A cold place with lots of blondes.

05 Aug 2017, 7:25 am

gabemai314 wrote:
I have designed and implemented a version of the Rijndael cipher (Advanced Encryption Standard) that uses a 3 dimensional 8x8x8 state (temporary buffer) instead of a 2 dimensional 4x4 state. This means the cipher will have a key size of 4096 bits. It uses 64 rounds for encryption and decryption. The cipher also includes new transformations called ShiftSlices and MixSlices that add additional diffusion into the cipher. These transformations are analogous to ShiftRows and MixColumns. I have a working implementation of the cipher that I wrote in C. I have also implemented various modes of operation such as ECB, PCBC, and XEX. Seeing that quantum computers will only halve the bit-strength of an algorithm, reducing the key size to 2048 bits, the three-letter agencies are surely going to have a field day with this one. Try brute-forcing the keys before the universe reaches heat death! :lol:



Redesigning a cipher after it has been made "to improve it" is like making the bradley again (see pentagon wars).

8^3 means an a state of 512, not 4096. Key distribution is a factor you should think of. Like Schneier said: "Cryptography does not exist in a vaccum".

64 rounds, compared to the specified 10-14 will make it extremely slow. Have you done any performance testing? People don't want to die of old age when encrypting data, even if it is more secure.

Please stop using C, its an insecure language that should have been shot and burried by now. C++ and other languages exists and are free, usually comes included in Linux and the free .NET environment (VS express) can be downloaded from Microsoft.

Noone bruteforce - ever. 3 letter agencies cheat by rigging PRNGs and hacking services that use the crypto amongst other things. Did you miss the Shadowbrokers leak? That :lol: is on you.


_________________
"It is far better to grasp the Universe as it really is than to persist in delusion, however satisfying and reassuring" (Carl Sagan)


gabemai314
Blue Jay
Blue Jay

User avatar

Joined: 12 Feb 2017
Age: 25
Gender: Male
Posts: 76
Location: Loveland, Colorado, USA, Earth, Solar System, Gould Belt, Orion Arm, Milky Way Galaxy, Local Group, Virgo Supercluster, Laniakea Supercluster, Universe

07 Aug 2017, 8:10 am

When I said I was using an 8x8x8 state I meant I was using an 8x8x8 byte state. Ergo, the keysize would be 4096 bits since 512*8=4096. In regards to key distribution, I plan on using the Supersingular Isogeny Diffie-Hellman (SIDH) key exchange algorithm? As far as entropy is concerned, couldn't one just use a different algorithm for pseudo-random number generation that does not possess the weaknesses of algorithms compromised by state-level actors?


_________________
I am open to PMs.
GitHub: https://github.com/gabemaiberger/


Ichinin
Veteran
Veteran

User avatar

Joined: 3 Apr 2009
Gender: Male
Posts: 3,653
Location: A cold place with lots of blondes.

08 Aug 2017, 5:00 am

gabemai314 wrote:
When I said I was using an 8x8x8 state I meant I was using an 8x8x8 byte state. Ergo, the keysize would be 4096 bits since 512*8=4096.


Ok.

Quote:
In regards to key distribution, I plan on using the Supersingular Isogeny Diffie-Hellman (SIDH) key exchange algorithm?


It's not what you would do, it is what people implementing the algorithm will do. You have to think about the end user, and in your case it is developers. If you want to work with crypto and develop for others, you have to learn to think like that. Developers do not care for details about crypto, they just want things to be secure, fast and easy to implement. If it is not, they replace your code with someone elses.

Quote:
As far as entropy is concerned, couldn't one just use a different algorithm for pseudo-random number generation that does not possess the weaknesses of algorithms compromised by state-level actors?


You are missing the point, PRNGs is just one thing they could cheat with - it was just an example. Also state level actors are not idiots - some of them are really sharp. Well, at least those who do not spend their days writing compliance documents and play political intra department games to further their career, because generating papers is 100% of their skill set.


_________________
"It is far better to grasp the Universe as it really is than to persist in delusion, however satisfying and reassuring" (Carl Sagan)


Kurgan
Veteran
Veteran

User avatar

Joined: 6 Apr 2012
Age: 35
Gender: Male
Posts: 4,132
Location: Scandinavia

09 Aug 2017, 1:41 pm

if you try to brute-force traditional AES-256, it will take even the most powerful bitcoin mine there is billions of years. Hackers are like horror movie villains, and will take advantage of the careless behaviour of the victim to achieve their goal (eg. their password being "qwerty1234" or "Volvo240"). The police here in Scandinavia has unsuccessfully tried to brute-force Countermail passwords several times.

Keep in mind that something isn't safe per se if it hasn't been thoroughly tested. Microsoft will pay hackers to test their stuff extensively; as will Google. NSA, Microsoft or anyone else aren't going to pay billions to reinvent the wheel. ;)

C still has plenty of stuff going for it. It's much easier to make a compiler for C, and secure PRNGs, ciphers, hash functions and so on need to run of low-end hardware as well (bank tokens, access cards, etc.). If an algorithm's security rests solely on being tough on the hardware, it can be used to mount a DDoS attack (as has been the case with scrypt or bcrypt if not used correctly).


_________________
“He who controls the spice controls the universe.”


Ichinin
Veteran
Veteran

User avatar

Joined: 3 Apr 2009
Gender: Male
Posts: 3,653
Location: A cold place with lots of blondes.

10 Aug 2017, 5:46 am

We're getting off topic but:

Kurgan wrote:
if you try to brute-force traditional AES-256, it will take even the most powerful bitcoin mine there is billions of years. Hackers are like horror movie villains, and will take advantage of the careless behaviour of the victim to achieve their goal (eg. their password being "qwerty1234" or "Volvo240"). The police here in Scandinavia has unsuccessfully tried to brute-force Countermail passwords several times.


If they did that, the are even bigger idiots than i thought. Normally you'd throw a list of hashed passwords against it. People do not walk around with >128 bit keys in their heads.

Quote:
Keep in mind that something isn't safe per se if it hasn't been thoroughly tested. Microsoft will pay hackers to test their stuff extensively; as will Google. NSA, Microsoft or anyone else aren't going to pay billions to reinvent the wheel. ;)


Anyone who care about security will pay for vulnerabilities, but more money can be made on darknets selling the same exploits for bitcoins. No questions asked, exclusive rights to the buyer. (Guess the clientele: well funded, organised, has use for 0-days, don't care about the law/is above the law).

Quote:
C still has plenty of stuff going for it. It's much easier to make a compiler for C, and secure PRNGs, ciphers, hash functions and so on need to run of low-end hardware as well (bank tokens, access cards, etc.). If an algorithm's security rests solely on being tough on the hardware, it can be used to mount a DDoS attack (as has been the case with scrypt or bcrypt if not used correctly).


Nothing is going for C - it is s**t, it has no bounds checking (which means buffer overflows), it has no type safety, and more (see link below) etc which means much of the stuff you write will be full of unpatched vulnerabilities unless you know what you are doing, there is plenty more that ISN'T going for C since people have already moved away from it - C is dead ancient knowledge, please stop resuscitating it and drop that piece of crap and move on to something that can put food on your table - the amount of organisations that are willing to pay someone to code in C are extremely low.

Even this guide how to code securely in C will be over 15 years old in a month:
https://www.sans.org/reading-room/whitepapers/securecode/securely-programming-388


_________________
"It is far better to grasp the Universe as it really is than to persist in delusion, however satisfying and reassuring" (Carl Sagan)


Kurgan
Veteran
Veteran

User avatar

Joined: 6 Apr 2012
Age: 35
Gender: Male
Posts: 4,132
Location: Scandinavia

10 Aug 2017, 12:18 pm

Ichinin wrote:
We're getting off topic but:

Quote:
If they did that, the are even bigger idiots than i thought. Normally you'd throw a list of hashed passwords against it. People do not walk around with >128 bit keys in their heads.


They realized it didn't work and instead got a court order. Before that, they also tried to brute-force private keys (based on public keys they had received from Countermail). Most people do not remember freakishly big keys, but some passwords (for example consisting of a long sentence) are easy to remember and hard to break. The phrase "CountermailIsNoLongerSecureAsOf2017" is easy to remember, but is not found in any dictionary that I know of, for example.

Quote:
Anyone who care about security will pay for vulnerabilities, but more money can be made on darknets selling the same exploits for bitcoins. No questions asked, exclusive rights to the buyer. (Guess the clientele: well funded, organised, has use for 0-days, don't care about the law/is above the law).


Google will pay up to 200,000 USD, depending on the severity. An amount like that in bitcoins can in some cases raise suspicions, especially in places where Bitcoin exchanges are required to file SARs.

Quote:
Nothing is going for C - it is s**t, it has no bounds checking (which means buffer overflows), it has no type safety


A lot of languages, such as JavaScript, HTML, CSS, CG/HLSL, GLSL, etc. are not typesafe. Almost all shaders today are written in a derivate of C, and most jobs these days are for JavaScript. Buffer overflows can happen in most (probably all) languages where you have to handle the memory management by yourself.

Quote:
, and more (see link below) etc which means much of the stuff you write will be full of unpatched vulnerabilities unless you know what you are doing, there is plenty more that ISN'T going for C since people have already moved away from it - C is dead ancient knowledge, please stop resuscitating it and drop that piece of crap and move on to something that can put food on your table - the amount of organisations that are willing to pay someone to code in C are extremely low.


I get paid to write code in derivatives of C. The Linux Kernel development is to a large degree composed of people getting paid to write code in standard C. Knowledge of C alone will not pay the bills, but if it's coupled with a few other languages, it will make it easier to find a job. There are over 40 ads for available jobs in Norway (with 5 million people) alone mentioning C.

Quote:
Even this guide how to code securely in C will be over 15 years old in a month:
https://www.sans.org/reading-room/whitepapers/securecode/securely-programming-388


Many principles are still valid. Means of authentication, tamper resistance, and so on are more relevant on the front-end side these days than what language you use.


_________________
“He who controls the spice controls the universe.”


Ichinin
Veteran
Veteran

User avatar

Joined: 3 Apr 2009
Gender: Male
Posts: 3,653
Location: A cold place with lots of blondes.

10 Aug 2017, 5:06 pm

Quote:
Google will pay up to 200,000 USD, depending on the severity. An amount like that in bitcoins can in some cases raise suspicions, especially in places where Bitcoin exchanges are required to file SARs.


Perhaps i was unclear: we're about organised crime and the intelligence community. Rules go out the window. There is a reason why some security researchers follow digital currency like Bitcoin and Etherum.

Quote:
A lot of languages, such as JavaScript, HTML, CSS, CG/HLSL, GLSL, etc. are not typesafe. Almost all shaders today are written in a derivate of C, and most jobs these days are for JavaScript. Buffer overflows can happen in most (probably all) languages where you have to handle the memory management by yourself.


You shouldn't handle memory as a developer, same argument why construction workers shouldn't handle explosives - it needs expertise - or a remotely controlled robot (analogy for automated memory handling). And you do not write missile guidance systems and access card systems in Javascript, CSS, and whatever. People still do that in C and it need to stop.

Quote:
I get paid to write code in derivatives of C. The Linux Kernel development is to a large degree composed of people getting paid to write code in standard C. Knowledge of C alone will not pay the bills, but if it's coupled with a few other languages, it will make it easier to find a job. There are over 40 ads for available jobs in Norway (with 5 million people) alone mentioning C.


That does not make the language secure and that people should continue to use it. I have moved on from C, C++, VB, Java to newer languages that are safer and more simple to develop in, granted there are limitations when developing operating system features at that level, but there has to be alternatives.

Quote:
Many principles are still valid. Means of authentication, tamper resistance, and so on are more relevant on the front-end side these days than what language you use.


No, some language have more resiliency against some attacks because they are not what C is. I could use the same arguments for Brainfuck, ERLANG or QBasic.

(and if you reply, please don't screw up the quotes again, was rather painful to sort out :lol:)


_________________
"It is far better to grasp the Universe as it really is than to persist in delusion, however satisfying and reassuring" (Carl Sagan)


gabemai314
Blue Jay
Blue Jay

User avatar

Joined: 12 Feb 2017
Age: 25
Gender: Male
Posts: 76
Location: Loveland, Colorado, USA, Earth, Solar System, Gould Belt, Orion Arm, Milky Way Galaxy, Local Group, Virgo Supercluster, Laniakea Supercluster, Universe

17 Aug 2017, 8:39 pm

In this cipher, I have added steps that add additional confusion and diffusion by shifting and mixing the individual slices of the state. These steps are called ShiftSlices and MixSlices respectively. I also have improved the key scheduler by adding a constant that is XORed with the first column of each slice that supplements the round constant and by using the ShiftRows transformation after generating the round key. The ShiftSlices and MixSlices transformations were my idea. The key scheduler improvements I found in some academic papers on cryptography online. A general overview of the algorithm is posted below.

Basics
-------
Key Size: 4096-bit
State: 8x8x8 matrix
Rounds: 51

InitialRound
-------------
1. AddRoundKey

Round
-------
1. SubBytes
2. ShiftRows
3. ShiftSlices
4. MixColumns
5. MixSlices
6. AddRoundKey

FinalRound
------------
1. SubBytes
2. ShiftRows
3. ShiftSlices
4. AddRoundKey

InvRound
--------
1. InvShiftSlices
2. InvShiftRows
3. InvSubBytes
4. AddRoundKey
5. InvMixSlices
6. InvMixColumns

InvFinalRound
---------------
1. InvShiftSlices
2. InvShiftRows
3. InvSubBytes
4. AddRoundKey

MixColumns/MixSlices
------------------------
02 01 03 01 01 01 01 01
01 03 01 01 01 01 01 02
03 01 01 01 01 01 02 01
01 01 01 01 01 02 01 03
01 01 01 01 02 01 03 01
01 01 01 02 01 03 01 01
01 01 02 01 03 01 01 01
01 02 01 03 01 01 01 01

InvMixColumns/InvMixSlices
-------------------------------
0E 01 09 01 0D 01 0B 01
01 09 01 0D 01 0B 01 0E
09 01 0D 01 0B 01 0E 01
01 0D 01 0B 01 0E 01 09
0D 01 0B 01 0E 01 09 01
01 0B 01 0E 01 09 01 0D
0B 01 0E 01 09 01 0D 01
01 0E 01 09 01 0D 01 0B

KeyScheduler Round
------------------
1. Multiple of 512
1. W(i)=RotQuadWord W(i-1)
2. W(i)=SubBytes W(i-1)
3. W(i)=W(i-1) XOR W(i-512) XOR Rcon(i)
2. Multiple of 64
1. W(i)=RotQuadWord W(i-1)
2. W(i)=SubBytes W(i-1)
3. W(i)=W(i-1) XOR W(i-512) XOR Scon(i)
4. ShiftRows
3. Not a multiple
1. W(i)=W(i-1) XOR W(i-512)


_________________
I am open to PMs.
GitHub: https://github.com/gabemaiberger/