Computing desk
< January 23	<< Dec \| January \| Feb >>	January 25 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

January 24

Cryptographic primitives

Is there a cryptographic primitive process/method for creating cryptographic tools like symmetric encryption/decryption, Hash code generator, MAC generator and Random number generator?

Or

Is it possible to create cryptographic tools like symmetric encryption/decryption, Hash code generator, MAC generator and Random number generator using the same cryptographic primitive process/method? — Preceding unsigned comment added by 112.79.40.92 (talk) 08:48, 24 January 2013 (UTC)[reply]

One can construct a MAC with a symmetric block cipher using a number of schemes, as described at Message authentication code#Implementation. Cryptographic hash function#Hash functions based on block ciphers discusses schemes for building secure hash functions from block ciphers. This NIST document discusses ways of implementing PRNGs using other crypto operations, including block ciphers like AES. It's worth mentioning that composing cryptographic operations can appear very straightforward, but it's extremely easy to do so in an insecure way, producing a system that's much less secure than any of its parts. So producing such a system is not just a matter of engineering. -- Finlay McWalterჷTalk 13:56, 24 January 2013 (UTC)[reply]

Here's a great, and very topical, example of that last point I made. This posting is an analysis of the client-side security used by high-profile new file-hosting service Mega. It says Mega uses a home-brewed AES-based hashing scheme, rather than a robust standard like bcrypt. With a fast cipher like AES and no cryptographic salt, it looks like it'd be far too tractable for someone to compute rainbow tables and compromise the hash. -- Finlay McWalterჷTalk 17:22, 24 January 2013 (UTC)[reply]

Conversely, as Cryptographic hash function#Use in building other cryptographic primitives says, cryptographic hash functions can be used to create MACs, PRNGs, and block and stream ciphers. And as stream cipher notes, stream ciphers essentially have a PRNG inside them, which generates a stream of material used to encrypt their data. -- Finlay McWalterჷTalk 14:10, 24 January 2013 (UTC)[reply]

There is an article Cryptographic primitive and a Category:Cryptographic primitives. Not sure if that helps... Ssscienccce (talk) 15:36, 24 January 2013 (UTC)[reply]

This is fairly common. Skein (hash function) for example is based on Threefish. Shadowjams (talk) 21:18, 24 January 2013 (UTC)[reply]

Super-symmetric Stream Cipher

What I want to know is,

Is there a stream cipher with two modes Mode-1 (encrypt/decrypt) and Mode-2 (decrypt/encrypt)

i.e. it should be possible to encrypt and decrypt using Mode-1 and Mode-2 respectively and also it should be possible to encrypt and decrypt using Mode-2 and Mode-1 respectively. And two outputs from two modes for same Plain-Text and Key (password) is entirely different.

Is it possible? if so let me know such stream cipher? — Preceding unsigned comment added by 112.79.41.219 (talk) 17:11, 24 January 2013 (UTC)[reply]

Do you mean something like Homomorphic encryption? -- Finlay McWalterჷTalk 17:24, 24 January 2013 (UTC)[reply]

Not Homomorphic, my question is,

Is it mathematically POSSIBLE to have SINGLE stream cipher with the above mentioned behaviour (super-symmetry)?

i.e. Encryption: Mode-1: F(x, k) = y1; Mode-2: F-1(x, k) = y2; Decryption: Mode-2: F-1(y1, k) = x; Mode-1: F(y2, k) = x;

whereas F is Mode-1; F-1 is Mode-2; x is plain-text; k is password/key; and y1 and y2 are two entirely different outputs. — Preceding unsigned comment added by 112.79.41.219 (talk) 19:15, 24 January 2013 (UTC)[reply]

This is almost certainly possible. Whether it is cryptographically secure (or even whether it is useful at all) is a totally different question. Almost by definition, you've created an incredible susceptibility to hash collisions. Nimur (talk) 22:43, 24 January 2013 (UTC)[reply]

Any block cipher works like this—you can swap the "encryption" and "decryption" algorithms. Stream ciphers don't encrypt or decrypt things as such—they just produce quasirandom bits, which by convention are xored with the plaintext/ciphertext to get ciphertext/plaintext. You could use those bits in some other way that would accomplish your goal, but I'm not sure it would still deserve the name "stream cipher". -- BenRG (talk) 23:53, 24 January 2013 (UTC)[reply]