Re: New encryption block...
On Monday, 17 October 2016 at 08:46:36 UTC, Era Scarecrow wrote:
encrypting multiple times won't get you the original value
My impression is different. This is how decryption looks like for
chacha:
void ECRYPT_decrypt_bytes(ECRYPT_ctx *x,const u8 *c,u8 *m,u32
bytes)
{
ECRYPT_encrypt_bytes(x,c,m,bytes);
}
Re: New encryption block...
On Monday, 17 October 2016 at 08:20:23 UTC, Kagamin wrote: On Wednesday, 12 October 2016 at 10:34:52 UTC, Era Scarecrow wrote: Maybe it would be better for random number generation rather than secure encryption? Not sure. It's used in windows CRNG to compute a big hash of big amount of entropy. BTW if you encrypt something twice, isn't it decryption? No, not unless they are mapped in a way where x becomes y, and y becomes x. Like ROT13, that would result in decryption as encryption, or if the XOR is used twice then it's decryption or redundant. Trust me what I'm doing is considerably more complex, encrypting multiple times won't get you the original value (for a very very long time, unless you have a very poor set of RNG inputs) You know I can't help but remember the last time I got into encryption with Semeir, where it would create a number of circular chains of different lengths and then the rotation of where it would move to for encrypting would change based on not only the last character it encrypted but how far along in the stream it was. (Originally stream encryption, not block encryption). Alas breaking large data down into smaller and larger blocks (6 bit, 12 bit, 20 bit, etc) and encrypting each with a different set of keys was... time consuming, and it really was over my head... I doubt anyone uses it, although if they do I can almost guarantee no one can break it due to it's obscureness :P
Re: New encryption block...
On Wednesday, 12 October 2016 at 10:34:52 UTC, Era Scarecrow wrote: Maybe it would be better for random number generation rather than secure encryption? Not sure. It's used in windows CRNG to compute a big hash of big amount of entropy. BTW if you encrypt something twice, isn't it decryption?
Re: New encryption block...
On Wednesday, 12 October 2016 at 10:34:52 UTC, Era Scarecrow wrote: Anyways, 16bit replacement, extending to 64bit via reordering, and 8 unique xor's between stages. Once I get the 576 block finished (1 for salt) I'll probably publish my ugly code for consideration and to be torn apart for security issues. https://github.com/rtcvb32/Side-Projects/blob/master/block_shuffle.d Here's my ugly code, doing 2byte, 8byte, and 72byte blocks, (could do a 648byte block as well using the same pattern, or 520bytes), includes an RNG. Rather than 8 passes I reduced it to 3 passes. Currently no decided license, so... if anyone wants to glance it over.
Re: New encryption block...
On Sunday, 9 October 2016 at 20:33:29 UTC, Era Scarecrow wrote: Something coming to mind is the idea of making a small algorithm to be used with other already existing encryption functions to extend the blocksize of encryption with minimal complexity growth. For fun I'm experimenting with this. So far seems fairly promising, although I'm sure I'm writing it very insecurely. Maybe it would be better for random number generation rather than secure encryption? Not sure. Anyways, 16bit replacement, extending to 64bit via reordering, and 8 unique xor's between stages. Once I get the 576 block finished (1 for salt) I'll probably publish my ugly code for consideration and to be torn apart for security issues.
Re: New encryption block...
On Monday, 10 October 2016 at 09:54:32 UTC, Era Scarecrow wrote: The largest portion would be that much like a hash, one small change will change the entire thing rather than a smaller portion (with the original blocksize). The multiple re-arranging and encryption steps is to ensure small changes affects every other block it was part of. With CBC block mode, for example, all blocks later in the data stream are changed if one block is changed. Earlier blocks aren't changed because CBC processes data in a single pass (which is an important practical requirement for a lot of applications). If you wanted all the blocks to change, two passes would be enough. Just thinking that if someone makes a database of say the first 4 bytes expected in a file format (like gzip, bzip2, others, etc) then they can map most of the keys and immediately know how to decrypt it (assuming it's of a particular file/stream type). Yep, this is one of the many reasons all secure block modes must use an IV (or equivalent). BTW, if anyone's interested, here's a explanation of a real attack on short block size ciphers that doesn't assume background knowledge: https://blog.cryptographyengineering.com/2016/08/24/attack-of-week-64-bit-ciphers-in-tls/ (The defence is to stop using crypto that was looking bad in the 90s.)
Re: New encryption block...
On Monday, 10 October 2016 at 03:15:07 UTC, sarn wrote: End users won't want to permute+encrypt multiple times unless you can show there's a benefit in the speed/security tradeoff, so you'll need to think about that in the design. The largest portion would be that much like a hash, one small change will change the entire thing rather than a smaller portion (with the original blocksize). The multiple re-arranging and encryption steps is to ensure small changes affects every other block it was part of. Just thinking that if someone makes a database of say the first 4 bytes expected in a file format (like gzip, bzip2, others, etc) then they can map most of the keys and immediately know how to decrypt it (assuming it's of a particular file/stream type). The larger block size also allows for multiple keys so you could push past far past the limitations of a single block cipher. As for a specific example, not really. Something fairly small, so personal documents and the like or archives, unlike say multi-media where it doesn't contain any personal data (probably). The only other idea is another multi-step process used for when generating hashes/keys or the like which is to slow down or make it annoyingly difficult to brute force passwords from a hashfile. Alternatively with the salting having it for encrypted communication would help hide sentences/replies where you reply the same thing over and over again. Y>Do you have the stuff? M>Yes Y>Did you stash it in the place? M>Yes Y>Do you like Lasagna? M>Yes or something like that :P Oh well. My question was mostly an idea, having something to look over for block ciphers will be an interesting read (when I get to it)
Re: New encryption block...
On Sunday, 9 October 2016 at 20:33:29 UTC, Era Scarecrow wrote: Something coming to mind is the idea of making a small algorithm to be used with other already existing encryption functions to extend the blocksize of encryption with minimal complexity growth. In theory this would extend a blocksize of 4 or 8 bytes, to say 64 bytes. Not only that each stage could use a different encryption type (or all the same). Do you have an application in mind? There are plenty of good algorithms to choose from today that already have a block size that's big enough (unlike, e.g., DES, which was too small). Then encrypted again. Preferably a the rearranging is complex enough to do several steps before calling it done. Remember, you have a few baselines to compare against for speed and security: 1. Encrypting once with something well accepted like AES-GCM or AES-CBC 2. Encrypting multiple times using other algorithms End users won't want to permute+encrypt multiple times unless you can show there's a benefit in the speed/security tradeoff, so you'll need to think about that in the design. Lastly there could be an optional salt block. Such a block would allow multiple instances/results of the same encrypted data and plenty of dummy data too, helping to hide identically encrypted data up to the combinations of the size of the salt. This sounds like the IV in off-the-shelf block modes: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation It's really not optional, though, because there are many attacks on encryption with poor IVs. If you're interested in this stuff, I strongly recommend these challenges: http://cryptopals.com/
