Cryptography I designed a block cipher for fun |
- I designed a block cipher for fun
- Approximate quantum cloning (PQC): The new way of eavesdropping in quantum cryptography
- Is using a VPN for VoIP calls more or less secure?
I designed a block cipher for fun Posted: 20 Feb 2018 03:37 PM PST This is a block cipher I made in my spare time over the past few weeks. It's a sort of hybrid Feistel network that encrypts 128-bit blocks, currently only using 128 bit keys. The cipher alternates between four rounds of Feistel-like operations ("subrounds") and a substitution round, where all bytes in the block are replaced with their corresponding byte in an S-box. (Excuse my poor diagrams) The subround operation looks like this: diagram where f is a function, specifically called the remap function, that takes in two 32-bit words and outputs a third 32-bit word. Subrounds always appear in chunks of four. Overall the subround routine is performed twenty times, requiring twenty 32-bit subround keys. The key expansion uses the same remap function, and looks like this: diagram It continues to create words and append them to the expanded key using the same pattern: assuming there were 4 words provided by the original key. Finally, the actual remap function looks like this: diagram Input words i and w create output word o. The K values are a set of 32 unique byte constants, intended to prevent repetitive input words like (1a1a1a1a, 3b3b3b3b) from producing patterns in output words. Their actual values do not matter. In my implementation, they are initialized to Pi converted to hexadecimal, with duplicates and 00s removed. This diagram is actually pretty difficult to follow, so here is the function in C: The whole cipher works like this: for a total of twenty subrounds and four substitution rounds. The last substitution round is omitted because it adds no extra security. Blocks should be padded to 128 bits using PKCS#7 padding. Here is a walkthrough of encrypting a block: pastebin To test the design, I made an executable that encrypts infinite 0x00s in CBC mode with a key of all 0x00s and piped this into dieharder. The results are available here: pastebin Then I did the same test using counter mode starting from { 0 } instead, the output for this is here: pastebin Next, I encrypted 100MB of 0x00s with a key of 0x00s using CBC with an IV of all 0x00s, and tried to compress the output file with 7zip, xz, and the Windows default zip tool. For all of them, the size of the file increased after compression. Here are some test blocks: (Thanks to /u/naclo3samuel for these test ideas) The C header file I made is available here: pastebin And here's a simple program to run it: Disclaimer, I'm aware of Schneier's Law, this was all done for fun/learning, and I'd love to see somebody smarter than me break it. My possible concerns are the remap function being invertible, predictable, or biased in some way, but I myself can't see a way to exploit this. [link] [comments] |
Approximate quantum cloning (PQC): The new way of eavesdropping in quantum cryptography Posted: 20 Feb 2018 10:26 AM PST |
Is using a VPN for VoIP calls more or less secure? Posted: 20 Feb 2018 02:32 AM PST I use a mobile app called I am trying to work out if it is worthwhile for me to use a VPN to place VoIP calls, I don´t really need to hide my IP but since I already have a provider, the idea was that I might as well do it as long as call encryption is not weakened. [link] [comments] |
You are subscribed to email updates from Cryptography news and discussions. To stop receiving these emails, you may unsubscribe now. | Email delivery powered by Google |
Google, 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States |
No comments:
Post a Comment