Re: [cryptography] Project C-43 and Public Key Encryption
Koenig's idea is interesting, and with a small twist I think could have worked. If instead of only applying noise at the receiving end, noise was first applied by the sender, then the recipient applies his own noise and sends it back to the sender, who then subtracts his original noise and sends it back encrypted with the recipient's noise who can now decrypt it Cheers, Leandro.- On Thu, Jun 13, 2013 at 3:31 PM, John Young j...@pipeline.com wrote: Old Mystery Solved: Project C-43 and Public Key Encryption: http://techpinions.com/an-old-**mystery-solved-project-c-43-** and-public-key-encryption/**18205http://techpinions.com/an-old-mystery-solved-project-c-43-and-public-key-encryption/18205 __**_ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/**mailman/listinfo/cryptographyhttp://lists.randombit.net/mailman/listinfo/cryptography -- Leandro Federico Meiners ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Project C-43 and Public Key Encryption
yes, should have thought it through ... On Thu, Jun 13, 2013 at 4:44 PM, Natanael natanae...@gmail.com wrote: Isn't that equivalent to sender doing XOR on the plaintext, recipient doing XOR on first ciphertext, sender doing another XOR on second ciphertext to create third ciphertext, and the recipient doing XOR again to get plaintext? That's key-reuse and breaks XOR/OTP. The middleman simply XORs the ciphertexts with each other to get the key and then decrypts the first ciphertext. He just simply needs to record all ciphertexts. The same basic method applies for the noise application/removal. Den 13 jun 2013 17:31 skrev Leandro Meiners lmein...@gmail.com: Koenig's idea is interesting, and with a small twist I think could have worked. If instead of only applying noise at the receiving end, noise was first applied by the sender, then the recipient applies his own noise and sends it back to the sender, who then subtracts his original noise and sends it back encrypted with the recipient's noise who can now decrypt it Cheers, Leandro.- On Thu, Jun 13, 2013 at 3:31 PM, John Young j...@pipeline.com wrote: Old Mystery Solved: Project C-43 and Public Key Encryption: http://techpinions.com/an-old-**mystery-solved-project-c-43-** and-public-key-encryption/**18205http://techpinions.com/an-old-mystery-solved-project-c-43-and-public-key-encryption/18205 __**_ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/**mailman/listinfo/cryptographyhttp://lists.randombit.net/mailman/listinfo/cryptography -- Leandro Federico Meiners ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography -- Leandro Federico Meiners ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] HMAC over messages digest vs messages
On 11/02/2011 06:13 PM, Jon Callas wrote: I think I understand where you're going. However, in the general case, as Marsh and Greg have pointed out, there are length issues, etc. that you'd want to at the very least hash the length + the message. Very likely more tweaks are needed, too. But I have to ask why you're bothering? The best way in the world to introduce a crypto flaw is to improve an existing, known construction. Really. Don't. If you don't have a specific problem you're trying to fix, or feature you need to enable, treat the standard set of constructions like a box of Legos. Just put them together, and you'll almost always be fine. When you're not fine, you'll have problems that lots of people will understand, too. The construction you have, an HMAC of a hash, computes three hashes, as opposed to the HMAC proper which only does two. So it's slower. On the security axis, we're now tweaking your contraction to remove flaws that wouldn't be there if you just used an HMAC. Ask yourself what problem are you trying to solve that HMAC doesn't solve? If you don't have a good answer to that question, just use an HMAC. Sure, I completely agree: I would have simply kept it at the basics (i.e. using an HMAC on the data). I am going over somebody else's design and came up with this which I found weird and wanted to double check if it was in fact non-standard or just something I wasn't aware of. Cheers, Lea.- -- Leandro Federico Meiners ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] HMAC over messages digest vs messages
Hi List! I was wondering if anybody could give me some pointers as to papers or books that discuss the advantages/disadvantages of computing an HMAC of a message versus previously computing a hash of the message and then calculating the HMAC of the hash. My initial thoughts are that there isn't any additional security provided by either method. What about calculating the HMAC of the message concatenated to the hash? This seems more secure but I have no idea how to prove either statement. Any helps is greatly appreciated. Cheers, Leandro.- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
