I'm writing a utility to convert md5 (or sha1) digest to a distinguishable image, something like ssh-keygen -lv. Usually, similar messages can have digests very different, but hackers can modify the message bit by bit to try to get a similar but still different md5 digest to mock the original one. When matching is done by machine, the trick will certainly fail. But when matching is done by human eye, user could be fooled.
To avoid of such trick, the convert program can generate the image from a modified digest as follow:
image = generateImage( md5(md5 + Random_Secret) )
The Random_Secret will reshape the digest, the similarity introduced by hacker will be removed after the transformation.
Now comes the question, since the final md5() take input of another md5 variable, which is only 128-bit length, (here ignore the Random_Secret which is a constant in all) is it safe to generate enough different values for feeding generateImage()?
Question also for other digest algorithms: sha1, etc.
A hash function should have the following properties, among others:
In cryptography, the avalanche effect is the desirable property of cryptographic algorithms, typically block ciphers and cryptographic hash functions, wherein if an input is changed slightly (for example, flipping a single bit), the output changes significantly (e.g., half the output bits flip).
see https://en.wikipedia.org/wiki/Avalanche_effect
Thus, hackers should not be able to slightly modify the message to obtain a similar digest unless the hash function is broken. Also it should not be possible to create a message that results in a specific hash value (so it should resist preimage attacks, see https://en.wikipedia.org/wiki/Preimage_attack).
md5 is cryptographically broken
So would the use of a simple md5 hash already be sufficient?
No. Although md5 is a widely used hash function, it has the problem that it is cryptographically broken and therefore insecure.
One basic requirement of any cryptographic hash function is that it should be computationally infeasible to find two distinct messages that hash to the same value. MD5 fails this requirement catastrophically; such collisions can be found in seconds on an ordinary home computer.
see https://en.wikipedia.org/wiki/MD5
Therefore, it is generally recommended to stop using md5 in a cryptographic context.
Since such a collision would result in the same hash in the first inner hash operation in your approach, the repeated hash with an additional constant random secret would also be the same. This means that this attack can successfully exchange the message or file with a different one.
The other hash algorithm you mentioned, SHA-1, is also cryptographically broken.
In this context, there is a worth reading article from Arstechnica from 2008 about the exploitation of md5 collisions to create bogus CA intermediate certificates.
Example of a hash collision
Finally to illustrate a hash collision, here are two .jpg files with the same md5 hash. The collision was created using the following open source project published on Github: https://github.com/cr-marcstevens/hashclash.
The following small Python program writes the files yes.jpg and no.jpg into the current directory to be able to compare the files visually, and then calculates the md5 hash for them - which results in exactly the same value for both files.
import binascii
import hashlib
yes = b'ffd8ffe000104a46494600010101012c012c0000ffe100a04578696600004d4d002a000000080005011a0005000000010000004a011b0005000000010000005201280003000000010002000001320002000000140000005a87690004000000010000006e000000000000012c000000010000012c00000001323032323a31313a31392032323a35373a3133000003a00100030000000100010000a00200030000000100800000a0030003000000010080000000000000ffe10c3b687474703a2f2f6e732e61646f62652e636f6d2f7861702f312e302f003c3f787061636b657420626567696e3d22efbbbf222069643d2257354d304d7043656869487a7265537a4e54637a6b633964223f3e203c783a786d706d65746120786d6c6e733a783d2261646f62653a6e733a6d6574612f2220783a786d70746b3d22584d5020436f726520352e352e30223e203c7264663a52444620786d6c6e733a7264663d22687474703a2f2f7777772e77332e6f72672f313939392f30322f32322d7264662d73796e7461782d6e7323223e203c7264663a4465736372697074696f6e207264663a61626f75743d222220786d6c6e733a64633d22687474703a2f2f7075726c2e6f72672f64632f656c656d656e74732f312e312f2220786d6c6e733a70686f746f73686f703d22687474703a2f2f6e732e61646f62652e636f6d2f70686f746f73686f702f312e302f2220786d6c6e733a786d703d22687474703a2f2f6e732e61646f62652e636f6d2f7861702f312e302f2220786d6c6e733a786d704d4d3d22687474703a2f2f6e732e61646f62652e636f6d2f7861702f312e302f6d6d2f2220786d6c6e733a73744576743d22687474703a2f2f6e732e61646f62652e636f6d2f7861702f312e302f73547970652f5265736f757263654576656e7423222070686f746f73686f703a436f6c6f724d6f64653d2233222070686f746f73686f703a49434350726f66696c653d22735247422049454336313936362d322e312220786d703a4d65746164617461446174653d22323032322d31312d31395432323a35373a31332b30313a30302220786d703a4d6f64696679446174653d22323032322d31312d31395432323a35373a31332b30313a3030223e203c64633a7469746c653e203c7264663a416c743e203c7264663a6c6920786d6c3a6c616e673d22782d64656661756c74223e7965733c2f7264663a6c693e203c2f7264663a416c743e203c2f64633a7469746c653e203c786d704d4d3a486973746f72793e203c7264663a5365713e203c7264663a6c6920786d704d4d3a616374696f6e3d2270726f64756365642220786d704d4d3a736f6674776172654167656e743d22416666696e6974792044657369676e657220312e31302e352220786d704d4d3a7768656e3d22323032322d31312d31395432303a34343a33372b30313a3030222f3e203c7264663a6c692073744576743a616374696f6e3d2270726f6475636564222073744576743a736f6674776172654167656e743d22416666696e6974792050686f746f20312e31302e35222073744576743a7768656e3d22323032322d31312d31395432323a35373a31332b30313a3030222f3e203c2f7264663a5365713e203c2f786d704d4d3a486973746f72793e203c2f7264663a4465736372697074696f6e3e203c2f7264663a5244463e203c2f783a786d706d6574613e2020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020203c3f787061636b657420656e643d2277223f3effed005050686f746f73686f7020332e30003842494d04040000000000171c015a00031b25471c0200000200041c02050003796573003842494d0425000000000010acd1c50e9eee8829b1943af6ed4ce40dffe202644943435f50524f46494c45000101000002546c636d73043000006d6e74725247422058595a2007e6000b0013000f00240031616373704150504c0000000000000000000000000000000000000000000000000000f6d6000100000000d32d6c636d7300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b64657363000001080000003e63707274000001480000004c77747074000001940000001463686164000001a80000002c7258595a000001d4000000146258595a000001e8000000146758595a000001fc000000147254524300000210000000206754524300000210000000206254524300000210000000206368726d00000230000000246d6c756300000000000000010000000c656e5553000000220000001c0073005200470042002000490045004300360031003900360036002d0032002e003100006d6c756300000000000000010000000c656e5553000000300000001c004e006f00200063006f0070007900720069006700680074002c002000750073006500200066007200650065006c007958595a20000000000000f6d6000100000000d32d736633320000000000010c42000005defffff325000007930000fd90fffffba1fffffda2000003dc0000c06e58595a200000000000006fa0000038f50000039058595a20000000000000249f00000f840000b6c358595a2000000000000062970000b787000018d9706172610000000000030000000266660000f2a700000d59000013d000000a5b6368726d00000000000300000000a3d70000547b00004ccd0000999a0000266600000f5cffdb004300100b0c0e0c0a100e0d0e1211101318281a181616183123251d283a333d3c3933383740485c4e404457453738506d51575f626768673e4d71797064785c656763ffdb0043011112121815182f1a1a2f634238426363636363636363636363636363636363636363636363636363636363636363636363636363636363636363636363636363ffc00011080080008003012200021101031101ffc4001b00010002030101000000000000000000000005060102030407ffc40035100002020102040306030803000000000000010203040511122131410651611314223271e152a1b116344262818291926372f0ffc4001a010100020301000000000000000000000000020501030406ffc40023110101010002010401050000000000000000010203110412213151131432414252ffda000c03010002110311003f00fa00000000000000000020752d7ecc3cf9515d519c21b716ef9b64be1e5579b8d1beaf965d9f54fc884de756c8d58e6c6f5732fbc7700136d000000000000000000000d6728c20e5269452ddb7d84e71ae0e73928c62b76df62a7aceb52cc6e9a1b8d0babef3fb1af939262775a39f9f3c39eefca3b3eff79cdbae5d2726d7d3b161f09efee97f971adbfc1572efa2e27b9e9d5c24b69cbe397d59cbc12eb7ea56f852eb9bd4f7800ee5c800000000000000006b39c6b839cda8c62b76df636203c4da82854b0eb97c53e73dbb2f223bd4c67bad5cdc938b175517abead667d8eb8371c78be4bf17ab23002b35ababdd506f7adebd5a7b349a617ea745767cae5bbf5db99793e769b8b4e2da6b9a6892a75ecfaa1c3ed2334bbce3bb37f0f2e713aaebf17c8c714b351730543f6933ff00e2ff005fb9df17c4d72b12caae1283eae0b668df3c8c576cf3b8ade96806232528a945ee9add1937bb0000000003593e18b93e896e6c70cd970e15f25dab97e82b1abd4b555cad7f36f93f67354c37e4a2b9ff00922e5294e4e5393949f56deed980556b5ad7cd79cdf26b77bd5ec001140000036842564e3082de527b25ea6a7b747ba18fa9d13b229c78b6fa6fcb72599dd92a5992ea4abae3d6eac7aeb7d6314bf23a18325abd249d4e800064000038e5c78b12e8f9c24bf23b1ceffddecffabfd0c5f8475fb6be7a002a5e68000000003dda3e27be6a35d6e4928fc6fd52ec78493f0f46c7ab54e09b4b7e27e4b627c73bd46de292f2665fb5c8c805a3d100000000073bd6f8f625de2ff43a180c59dce9f3a05b323c378b75b2b236595f13df65b34709785a1fc39525f5815f7c7da92f85cd3f85681607e16b3b6547fd3ee693f0be42f92faa5f54d18fc3c9f48df179a7f5410261f86f3974753feefb185e1bce6f9ba97f77d88fe2dfd23fa7e5ff00351318b949462b76dec92ee5f30712ac3c78d75414797c4fbb7ea47699a057896abaf9ab6c8fca92e4993475f0715c7bd58f87e3de3ef5b9ee000e8778000000000000693b6baf6f6938c37e9c4f6dcdcf06b3a6c354d3ecc796ca7f3572fc32ec07b6528c22e53928c5756dec8d1e4d1149caead26b75bc97329d56466eb8b1b45ba33add127ef537dd45f2ff00de7b1d3c495e1d1af69f5e45129e2c28e17557befb7c5b6db35e805b619145925185d5ca4fa2524d8b3229a5a56dd5c1be8a524b72bda22d127a941e0e9f914df14dc676716cb96cfac9f99199355387a9e5cb5ec0bef8dd6375e4464f64bb6dcfe9f402f09a6b74f74cc90fe198515e97c38b992caa78df0b947670fe5dbf3fea4c000000000000000000000109a5e064e3ebfa964db5f0d376dece5c49effd3a9c75ac4d45ebd899f838aaf54d6d34e718addefe6fd4b0802230f335ab32ab8656995d34b7f14d5d17b72f2dcf1463afe9d75f54295a8d1649b84ecb79c7d1eecb20021bc37a65fa7635d2c9e18db7d9c6e10e90f426400000000003ffd9c4b3388e3f1f25df001a62f92687ecd5a5e418c4696dc90500000000189c71a5bddcd3a76b848dfd728e06107cfc7c58590457b174269b47a819677378d674e75717b38cb4c1d899c835393e77ef8ac23a6906f23d7a1ca0c44587a1a53265b96bedce9336efec51ff4915b409013aaceb0063ca664f64f24b8aa1845f0ad97a608304e6bdd2dbf22402569ab6d864ed484f1328cba836c425d8bf1a3c5cd8fd2a4e73fe5cb6359576f0e08597d74cc34405281ff880335050a3aecd75509ea44f847da805e2e5f2b51f05af0d1832d8905e7a7dd7a2227c412e241bf800fdb09c97bc11f6c412842e7102a793a894527be3a7ab503784dc33138fd2b2fc13ff48af9abd222c17c218f4d79f2b4a736622d67efad4e6e2794eeca6cae5983eb5eef36704a91578ec5f82c5dd9efb87e5e51b289c05eb6aefa9ca7b4e252839d299dcb24711aa196fd5b6a9af9147e137e1df9e778ccb8e8eede6a4814e59c957402cd6684eabf560277fe6195d635331a55005dd639de303c51d5ca468e6de7d5718f48a00dc4cce9476feda338a6b65bf702c368df0cdc71676b44c829a1054a3c7585dc3927bd9dca3660b6b4f078a85663f7ad5e0157412dd0d17aa43f5983441a66ed6900672f35bf14515698b98d173b7bdfc639c5cbcab9eec9ab30bb3f055536f'
no = b'ffd8ffe000104a46494600010101012c012c0000ffe100a04578696600004d4d002a000000080005011a0005000000010000004a011b0005000000010000005201280003000000010002000001320002000000140000005a87690004000000010000006e000000000000012c000000010000012c00000001323032323a31313a31392032323a35363a3331000003a00100030000000100010000a00200030000000100800000a0030003000000010080000000000000ffe10c3b687474703a2f2f6e732e61646f62652e636f6d2f7861702f312e302f003c3f787061636b657420626567696e3d22efbbbf222069643d2257354d304d7043656869487a7265537a4e54637a6b633964223f3e203c783a786d706d65746120786d6c6e733a783d2261646f62653a6e733a6d6574612f2220783a786d70746b3d22584d5020436f726520352e352e30223e203c7264663a52444620786d6c6e733a7264663d22687474703a2f2f7777772e77332e6f72672f313939392f30322f32322d7264662d73796e7461782d6e7323223e203c7264663a4465736372697074696f6e207264663a61626f75743d222220786d6c6e733a64633d22687474703a2f2f7075726c2e6f72672f64632f656c656d656e74732f312e312f2220786d6c6e733a70686f746f73686f703d22687474703a2f2f6e732e61646f62652e636f6d2f70686f746f73686f702f312e302f2220786d6c6e733a786d703d22687474703a2f2f6e732e61646f62652e636f6d2f7861702f312e302f2220786d6c6e733a786d704d4d3d22687474703a2f2f6e732e61646f62652e636f6d2f7861702f312e302f6d6d2f2220786d6c6e733a73744576743d22687474703a2f2f6e732e61646f62652e636f6d2f7861702f312e302f73547970652f5265736f757263654576656e7423222070686f746f73686f703a436f6c6f724d6f64653d2233222070686f746f73686f703a49434350726f66696c653d22735247422049454336313936362d322e312220786d703a4d65746164617461446174653d22323032322d31312d31395432323a35363a33312b30313a30302220786d703a4d6f64696679446174653d22323032322d31312d31395432323a35363a33312b30313a3030223e203c64633a7469746c653e203c7264663a416c743e203c7264663a6c6920786d6c3a6c616e673d22782d64656661756c74223e7965733c2f7264663a6c693e203c2f7264663a416c743e203c2f64633a7469746c653e203c786d704d4d3a486973746f72793e203c7264663a5365713e203c7264663a6c6920786d704d4d3a616374696f6e3d2270726f64756365642220786d704d4d3a736f6674776172654167656e743d22416666696e6974792044657369676e657220312e31302e352220786d704d4d3a7768656e3d22323032322d31312d31395432303a34343a32332b30313a3030222f3e203c7264663a6c692073744576743a616374696f6e3d2270726f6475636564222073744576743a736f6674776172654167656e743d22416666696e6974792050686f746f20312e31302e35222073744576743a7768656e3d22323032322d31312d31395432323a35363a33312b30313a3030222f3e203c2f7264663a5365713e203c2f786d704d4d3a486973746f72793e203c2f7264663a4465736372697074696f6e3e203c2f7264663a5244463e203c2f783a786d706d6574613e2020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020203c3f787061636b657420656e643d2277223f3effed005050686f746f73686f7020332e30003842494d04040000000000171c015a00031b25471c0200000200041c02050003796573003842494d0425000000000010acd1c50e9eee8829b1943af6ed4ce40dffe202644943435f50524f46494c45000101000002546c636d73043000006d6e74725247422058595a2007e6000b0013000f00240031616373704150504c0000000000000000000000000000000000000000000000000000f6d6000100000000d32d6c636d7300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b64657363000001080000003e63707274000001480000004c77747074000001940000001463686164000001a80000002c7258595a000001d4000000146258595a000001e8000000146758595a000001fc000000147254524300000210000000206754524300000210000000206254524300000210000000206368726d00000230000000246d6c756300000000000000010000000c656e5553000000220000001c0073005200470042002000490045004300360031003900360036002d0032002e003100006d6c756300000000000000010000000c656e5553000000300000001c004e006f00200063006f0070007900720069006700680074002c002000750073006500200066007200650065006c007958595a20000000000000f6d6000100000000d32d736633320000000000010c42000005defffff325000007930000fd90fffffba1fffffda2000003dc0000c06e58595a200000000000006fa0000038f50000039058595a20000000000000249f00000f840000b6c358595a2000000000000062970000b787000018d9706172610000000000030000000266660000f2a700000d59000013d000000a5b6368726d00000000000300000000a3d70000547b00004ccd0000999a0000266600000f5cffdb004300100b0c0e0c0a100e0d0e1211101318281a181616183123251d283a333d3c3933383740485c4e404457453738506d51575f626768673e4d71797064785c656763ffdb0043011112121815182f1a1a2f634238426363636363636363636363636363636363636363636363636363636363636363636363636363636363636363636363636363ffc00011080080008003012200021101031101ffc4001b00010001050100000000000000000000000006020304050701ffc40038100002020102030406060b000000000000000102030405110612213141517113142281a1b13242526191d1151623344472a2c1d2e1f0ffc4001a010100020301000000000000000000000000040501020306ffc40029110100020103020309010000000000000000010203041131125105214113141522324281a1b1e1ffda000c03010002110311003f00e80000001e01e835193c47838f64a1bd964a2f67cb1eff00798ef8af17bb1eef87e6739cb48f548ae973da378a4b7e08ecb8b29fa98b37e7248b32e2d9fd5c38fbe7fe8d673e3eee91a1d44fdbfc4a01139f15e4bfa18f547cdb6790e2bc95f4f1ea7e5ba31ef18fbb6f876a3b7ee12d06a34bd7a8cfb15528ba6e7d89bdd4bc99b73ad6d168de113263be3b74de3690006cd0000000002ddf2e5c7b24bb545bf8170b791fbbdbfc8fe42598e5cdfb7b400533d9000000002a84e55ce3383da517ba7e0ce8789935e563c2daa6a69a5bb5e273a36dc356db0d5ab85726a13df9d7735b1234f93a6db775778869fdae3ebdfcea9b000b179d000000000b3972e5c4ba5e15c9fc0bc63e72e6c0c84bbeb97c8c4f0cd79873b0014ef64000000001b0d0b2e387a9d739c778cbd8f2dfbcd799da363acad528ae4d28f3733ebdbb75d8de9bf546ce39e2b38add5c6d29e9e9e1e96cf240000000014ce3cd0945f7ad8a80104cbd0f3b1652fd8cac82ec943aefee35cd34da6b668e9846b8a74d5cab3aa8ecd74b36f8320e5d3c563aaabcd2f88cdef14c91cfaa3000222dc00cfab46d46e82943167cafb39b65f3331599e21a5f2529f54ecc02ba6d9d1742daded383dd3360f87f535fc3ff005afccc9c4e19cbb2c8fac38d55efd7aeecde315f7f2871beab045677b4259459e9b1ebb3edc54bf145c2984542118456ca2b64545abcac8000000000000516d70baa95762e68496cd78a2b0041357d2add36e7d1ca893f627fd9fde6b8e917535e4552aad829c24b66990dd6b46b34f9bb2bde78edf47df1fb995f9b074fcd5e17fa3d7464da9939feff00ac6d1acaebd5b1e56a5c9cdb75f17d9f127c73427da3667aee9b55adfb6972cbcd1d34b6e6ae3e2b8a77ae4fc338004c53000000000000000000000516d70b6b9576454a125b34fbcac01ceb3b1fd5736ea3ec4da5e5dc493841bf53c85dde917c8b7aaf0fe4e5ea53be99d6abb366dc9f55dc6ef4ec2af4fc48d15f5dbaca5e2fc4878b15ab9267d16faad5d3269eb589ded3b6eca001315000000000000000000000a1590763ad4e2e6bab8efd57b8f7d243d27273c79f6df977ebf8108d52dc9c4e2ccccec65cdeadc92b23e30718a7f33674645797c618f914cb9abb30f993fc40915b7554adedb2105e3292455194671528c94a2fb1a7b914d13069e20bb2f51d479ae5e95d75c1c9a515dbdde68bb835fe86e2a5a763ce5eab935f3c6b6f7e47d7fc58128000000000000000000000001a4c7d3aefd64d4726ea53c5bea8c22db4d4ba4535b76f7330747d072b4de22958a2e58718c9573725d13ea96dbee4a40119af0755d132f21e9d4432f12e973a839a8b83f7991a569b9b66ab3d57545085dcbc95d507bf22ff00be66f800000000000001ffd9037527a862a8e061ce54b290f08b2542358ec9d82b5909f87d37c425a383f7991a569b9b66ab3d57545085dcbc95d507bf22ff00be66f800000000000001ffd9037527a862a8e061ce54b290f08b254235000000006a9bf440bd18cc346b848dfd728e06107cfc7c58590457b174269b47a819677378d674e75717b38cb4c1d899c835393e77ef8ac2366906f23d7a1ca0c44587a1a53265b96bedce9336efec51ff4915b409013aaceb0063ca664f64f24b8aa1845f0ad97a608304e6bdd2dbf22402569ab6d864ed484f3328cba836c425d8bf1a3c5cd8fd2a4e73fe5cb6359576f0e08597d74cc34405281ff880335050a3aecd75509ea44f847da805e2e5f2b51f05af0d1832d8905e7abdd7a2227c412e241bf800fdb09c97bc11f6c412842e7102a793a894527be3a7ab503784dc33138fd2b2fc13ff48af9abd222c17c218f4d79f2b4a736622f67efad4e6e2794eeca6cae5983eb5eef36704a91578ec5f82c5dd9efb87e5e51b289c05eb6aefa9ca7b4e252839d299dcb24711aa196fd5b6a9af9147e137e1df9e788ccb8e8eede6a4814e59c957402cd6684eabf560277fe6195d635331a55005dd639de303c51d5ca468e6de7d5718f48a00dc4cce9476feda338a6b65bf712c368df0cdc71676b44c829a1054a3c7585dc3927bd9dca3660b6b4f078a85663f7ad5e0157412dd0d17aa43f5983441a66ed6900672f35bf14515698b98d173b9bdfc639c5cbcab9eec9ab30bb3f055536f'
def write_file(filename, data):
with open(filename, 'wb') as f:
f.write(data)
if __name__ == '__main__':
yes_data = binascii.unhexlify(yes)
write_file("yes.jpg", yes_data)
no_data = binascii.unhexlify(no)
write_file("no.jpg", no_data)
md5_yes = hashlib.md5(yes_data).hexdigest()
md5_no = hashlib.md5(no_data).hexdigest()
print("yes.jpg, md5 =", md5_yes)
print("no.jpg, md5 =", md5_no)
I am looking for a commutative cipher - that is
E(K₁,E(K₂,P)) = E(K₂,E(K₁,P))
but is not associative - that is
E(K,P) ≠ E(P,K)
That rules out XOR, which otherwise would have been ok.
A symmetric cipher would be preferable, but an asymmetric cipher would work too.
The basic protocol I want to implement is:
Alice has a list of tokens (32-bit integers) and she encrypts each token with the same key (K0)
Alice sends the list of encrypted tokens to Bob
Bob randomises the list, encrypts each token with a separate key (K1 - Kn), labels each token and returns the list to Alice.
Alice decrypts each token with K0, leaving her a list of tokens, each encrypted with a separate key (K1 - Kn)
Sometime later, Bob sends Alice a key for a specific label (Kx)
Alice decrypts the token with Kx giving her the plaintext for the token labelled x
Bob may see the plaintext, so he must not be able to derive K0 from it given the information he was previously given.
Can someone suggest a cipher I can use and also point me to an implementation of that cipher?
I have an understanding of cryptographic protocols and applications but I don't really grok the mathematics of most of the ciphers out there. Step-by-step mathematical guides would be ok though.
I plan to implement this in Clojure so any Java libraries are also good. However, any code is good because I understand code.
It sounds like you're trying to implement "Mental Poker" (or if not, you should look up the research into it, since it's analagous to your problem).
The SRA algorithm has the properties you desire. It's a bit hard to find information on, but it is essentially just RSA except that both the e and d exponents are kept secret. Trivially:
(Pe1)e2 == (Pe2)e1
below refers to my hobbiest solution using my own cipher program in C#. program and source are free and available.
Remember the 'locked box puzzle' recounted on an SECURITY NOW podcast?
here's the episode...
Episode #33 | 30 Mar 2006 | 43 min.
Symmetric Block Ciphers
https://www.grc.com/sn/sn-033.txt
Steve says...
...Leo and I answer last week's Puzzler/BrainTeaser which explored the idea
of using two private
one-time pad "keys," like two padlocks, to securely convey a message between
two parties, neither of
whom would have the other's key. Then we continue our ongoing tour of
fundamental crypto technology by
describing the operation of Symmetric Block Ciphers...
Steve and Leo agreed that an eavesdropper seeing ALICE's cipher text before
and after encryption could
XOR both together and derive her secret key.
However, if a complex, commutative cipher which doesn't use simple XORing
to encrypt is used then I
think the key exchange would be secure and the key exchange would work.
for example...
BOB encrypts msg with his key.
ALICE encrypts BOB's encrypted above msg with her key.
ALICE sends above encrypted msg back to BOB.
BOB decrypts ALICE's above msg with his key.
BOB sends above to ALICE.
ALICE decrypts above with her key.
ALICE can now read BOB'S original decrypted cipher text and they didn't need
to exchange keys.
An eavesdropper attack will not work if the algorithm is not a simple
'xor'ing of plain text and key.
this cipher is a commutative , complex algorithm.
starting with notepad text file containing one character, an 'm'.
m is hex 6d 01101101.
 is hex c2 11000010 is 'm' encrypted by bob and then sent to alice.
ø is hex d8 11011000 is alice's encryption of 'Â' which bob decrypts to '£'
and sends to alice.
£ is hex a3 10100011 which alice decrypts to 'm' with her key.
m is alice decrypt result
an eavesdropper sees  alice's msg before her encryption.
the eavesdropper sees ø alice's msg after her encryption.
the eavesdropper xors  and ø.
11000010 'Â'
11011000 'ø'
00011010 the eavesdropper's xor result = 1a in hex.
if an eavesdropper attack worked he would have found 'E' hex 45 01001001
which is first letter of
alice's key.
this seems a simpler key exchange than PGP etc. All that's needed is that
both parties use the same
crypto program and agree on an authenticator.
I confess to being a hobbiest. If anyone wants the WINDOWS C# .NET program
and/or the source code for the cipher they
may have it/them.
below is example with longer, random keys.
PLAIN TEXT
this is a test.
BOB'S KEY
kZtOfS0kKqcRLjTNPh7OjcJKZZFLjmm5OVm02YlrBQN0zI9SxOD1zJjQcpetUbX
BOB'S CIPHER TEXT TO ALICE.
1IÎ.8Ío#"ëìAùJ'
ALICE'S KEY
O1yfuV7MpX3n4wtefUhr6YctRaeCcrrzH7LqLNRUQCMVZuL5Mr0Bw3qMeIT92hg
ALICE'S CIPHER TEXT TO BOB
µRÖ³#ïÓO,fzkÆaå
BOB DECODES ALICE'S ABOVE WHICH = BELOW.
øqqøð<ª>P¸&#<,
AND SENDS ABOVE BACK TO ALICE WHICH ALICE DECODES YIELDING...
this is a test.
I'm doing something similar and I'm using AES in OFB (output feedback) mode. In this mode, an IV (publicly known random value) is encrypted with AES using some key. The output of this is then XORed with your data. The output (before being XORed with the data) is then encrypted again to get another output to XOR with more data. This is not only commutative but reciprocal in the sense that the encryption and decryption algorithms are identical.
http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Output_Feedback_.28OFB.29
I know the question was asked long ago, but nobody seems to have suggested Massey-Omura, so here it goes. It satisfies the original requirements exactly. The original description (also adopted in Wikipedia) used the multiplicative group of GF(2^m), but any secure group (like elliptic curves) will do.
Here is a page with commutative encryption algorithms :
https://xianmu.github.io/posts/2018-09-19-commutative-encryption.html
I'm trying to encrypt some date using a public key derived form the exchange key pair made with the CALG_RSA_KEYX key type. I determined the block size was 512 bits using cryptgetkeyparam KP_BLOCKLEN. It seems the maximum number of bytes I can feed cryptencrypt in 53 (424 bits) for which I get an encrypted length of 64 back. How can I determine how many bytes I can feed into cryptencrypt? If I feed in more than 53 bytes, the call fails.
RSA using the usual PKCS#1 v.1.5 mode can encrypt a message that is at most k-11 bytes, where k is the length of the modulus in bytes. So a 512 bit key can encrypt up to 53 bytes and a 1024 bit key can encrypt up to 117 bytes.
RSA using OAEP can encrypt a message up to k-2*hLen-2, where k is the modulus byte-length and hLen is the length of the output of the underlying hash-function. So using SHA-1, a 512 bit key can encrypt up to 22 bytes and a 1024 bit key can encrypt up to 86 bytes.
You should not normally use a RSA key to encrypt your message directly. Instead you should generate a random symmetric key (f.x. an AES key), encrypt your message with the symmetric key, encrypt the key with the RSA key and transmit both encryptions to the recipient. This is usually called hybrid encryption.
EDIT: Although this response is marked as accepted by the OP, please see Rasmus Faber response instead, as this is a much better response. Posted 24 hours later, Rasmus's response corrects factual errors,in particular a mis-characterization of OAEP as a block cipher; OAEP is in fact a scheme used atop PKCS-1's Encoding Primitive for the purpose of key-encryption. OAEP is more secure and puts an even bigger limit on the maximum message length, this limit is also bound to a hash algorithm and its key length.
Another shortcoming of the following reply is its failure to stress that CALG_RSA_KEYX should be used exclusively for the key exchange, after which transmission of messages of any length can take place with whatever symmetric key encryption algorithm desired. The OP was aware of this, he was merely trying to "play" with the PK, and I did cover that much, albeit deep in the the long remarks thread.
Fore the time being, I'm leaving this response here, for the record, and also as Mike D may want to refer to it, but do remark-me-in, if you think that it would be better to remove it altogether; I don't mind doing so for sake of clarity!
-mjv- Sept 29, 2009
Original reply:
Have you check the error code from GetLastError(), following cryptencrypt()'s false return?
I suspect it might be NTE_BAD_LEN, unless there's be some other issue.
Maybe you can post the code that surrounds your calling criptencryt().
Bingo, upon seeing the CryptEncrypt() call.
You do not seem to be using the RSAES w/ OAEP scheme, since you do not have the CRYPT_OAEP flag on. This OAEP scheme is a block cipher based upon RSAES. This latter encryption algorihtm, however, can only encrypt messages slightly less than its key size (expressed in bytes). This is due to the minimum padding size defined in PKCS#1; such padding helps protect the algorithm from some key attacks, I think the ones based on known cleartext).
Therefore you have three options:
use the CRYPT_OAEP in the Flag parameter to CryptEncrypt()
extend the key size to say 1024 (if you have control over it, beware that longer keys will increase the time to encode/decode...)
Limit yourself to clear-text messages shorter than 54 bytes.
For documentation purposes, I'd like to make note of a few online resources.
- The [RSA Labs][1] web site which is very useful in all things crypto.
- Wikipedia articles on the subject are also quite informative, easier to read
and yet quite factual (I think).
When in doubt, however, do consult a real crypto specialist, not someone like me :-)
In standard use of asymmetrical cryptographic system, encryption is done with public key, decryption with private key.
Inversing the process, "encryption with private key" is called "signing".
Standard tools, despite terminology and lack of direct tools, allows to implement encryption system that would use the private key for encryption.
Could anyone explain clearly why such solution is vulnerable?
User Case:
Consider that Alice wants to send to Bob some stuff in a non-traditional way:
Alice and Bob once met and Alice gave Bob a "public key" generated from a private key she created BUT she warned Bob to keep it secret. AND she kept secret the private key, and didn't ever give to anyone else the public key.
Could Bob be sure that messages he receives from Alice (provided these are encrypted by Alice private key) are only readable by him (provided he really kept his copy of Alice's public key secret)?
And how compares this encryption solidity to the traditional way, which would, in our case, be Bob sending messages (encrypted by the public key of Alice) to Alice?
What the question is about
The fact that asymmetrical keys are named "private" and "public" doesn't help understanding my question. Keys have underlying properties, and it's me broadcasting the "public key" that gives it its "public" property. Please make this distinction clear before answering: I'm not considering the "public" and "private" properties of these keys but the solidity of the "private key" encryption versus "public key" encryption.
I cannot use another terminology even if it is misleading in this special case.
I know that this case is non-traditional, and could lead to several inconsistency, or is not the point of the asymmetrical crypto systems as Bob and Alice here share some sort of a common secret and that's not the point of asymmetrical crypto.
I saw several Stackoverflow answers which suggest that "private key" and "public key" are exchangeable (just read below answers). This is not true for RSA as it is trivial to generate the public key from the secret key and this is guaranteed not to be computationally feasible in the other way round. For non-believers, the process of key generation in openssl with RSA is:
generate a secret key
extract the public key from the secret key.
If there are so big differences between "private key" and "public key", is there a solidity difference between "private key" encryption versus traditional "public key" encryption?
Short answer from long selected answer
Misunderstanding on what exactly is the "private key" wasn't helping me.
There's two different definition of "private key". The "practical private key", and the "theoretical private key".
Theoretical private key from RSA theory shares mathematical symmetricity with public key:
You cannot deduce one from the other
Encryption is equally solid in either way
Practical private key from RSA tools (like openssl) contains additional information for efficiency reason, and often, a part of the public key is even set by convention. These assumptions breaks the symmetricity:
It is trivial to get public key from "pratical private key"
But encryption remains equally solid
For more detail, see the selected answer ! Please comment if misconceptions remains...
Edit note:
Asymmetrical crypto system key pairs are frequently advertised as swappable (even in current stackoverflow answers), I try to bring reflexion around the fact that it could be dangerous misunderstanding as it isn't the case in REAL life tools.
Added the user case, I hope this will clarify my question
Added final 'short answer'
In standard use of asymmetrical cryptographic system, encryption is done with public key, decryption with private key.
It depends on who is doing what. Suppose Alice wants to send a message to Bob that only Bob can decode. Alice encrypts the message using Bob's public key (under the standard definition of 'public key', meaning the one that is known to people other than its owner). Now only someone who knows Bob's private key (presumably, the only person who knows Bob's private key is in fact Bob) can decrypt Alice's message to Bob.
If Alice wants Bob to know that only she could have sent it, she can encrypt the message with her own private key, assuming Bob knows her public key, either before or after encrypting the message with Bob's public key. Let's assume she encrypts the message with her private key, then the result with Bob's public key. To read the message, Bob has to decrypt the message with his (Bob's) private key, and then decrypt the result again with Alice's public key. If what he reads is now sensible text, he knows that someone who knows both Alice's private key (presumably Alice) and his public key (could be anyone at all) sent the message.
In practice, the asymmetric algorithms are expensive to compute, so what you really do is choose a random session key of an appropriate length and an agreed upon standard symmetric encryption algorithm such as AES. Then the main message is encrypted with the (relatively fast) symmetric algorithm and sent as one part of the message. The other part of the message is the encrypted - or doubly encrypted - random session key. Bob can decrypt the session key section of the message to obtain the session key; he then uses that to decrypt the main part of the message.
Note that if you are sending a message to many people, you can use one encryption of the message proper, and then encrypt the session key once for each recipient, using the recipient's public key. Each recipient can only decrypt the session key information using the key that belongs to them, but all can actually decrypt it. If the message is substantial (say 2 MB of PDF), then this is much more economical than separately encrypting the message with each recipients public key.
Inversing the process, "encryption with private key" is called "signing".
No; signing is a separate operation. If you read Schneier's "Practical Cryptography", you'll see that the authors suggest using one public/private key pair for encryption, and a second pair for signature work. For example, a signature encrypts a fixed length hash of the original message using the private key from the signing key. Anybody who knows the public key part of the signing key can then decrypt the signature to obtain the hash of the original message. Presumably, the same recipient can also decrypt the message (using the public key of the signature key pair), and then can check that the hash of the message received matches the hash derived from the signature. Any mismatch indicates a problem and the message should be discarded.
There are many ways to do these things - depending on the security requirements.
But the basic point is that one person knows the private key of an asymmetric key, and potentially many people know the public part of the asymmetric key (and this is perfectly safe). Data can be encrypted by the sender using the recipients public key; it may also be encrypted by the sender using their own private key. The recipient can decrypt the received message using their own private key and, if necessary, using the sender's public key.
The question, even as amended at about 2009-09-05T13:00-07:00, is not completely coherent, IMNSHO.
You should read chapter 13 "RSA" in "Practical Cryptography" (probably after reading some of the earlier chapters too - most notably section 3.3 Public-Key Encryption).
Notation for Encryption and Decryption
Let's define a bit of notation for discussing orthodox public key cryptography. Let's start with basic symmetric encryption:
C = E(K,m) is the encrypted message (cipher text, C) generated by encryption algorithm E using key K on (plain text) message m.
P = D(K,C) is the plain text message (plain text, P) discovered by decryption algorith D using key K on (encrypted) message c.
To be a working system, m = P, so D(K,E(K,m)) = m.
So far, this notation applies to symmetric encryption because the same value K is used in both encryption and decryption. Anyone who knows K (and the algorithm, but Kerckhoff's Principle that 'secrecy is in the keys' means that you assume the attackers know the algorithm - any contrary assumption is cryptographic 'snake oil') can decrypt the message.
With an asymmetric encryption system, Ea and Da are the encryption and decryption methods for algorithm A. The key distinguishing feature of an asymmetric cryptographic cipher is that the key Kencrypt used by Ea is different from the key Kdecrypt used by Da. Further, to be practical, it must be computationally infeasible to deduce Kdecrypt even if you know Kencrypt and vice versa.
With asymmetric encryption, Alice creates a pair of keys, (Salice, Palice). Conventionally, Salice is the secret key and Palice is the public key. Note that Alice knows both keys. All that matters is:
Salice and Palice are different.
Alice does not let anyone else know about one of the keys (Salice); it is crucial that this information is not known to anyone else.
Alice can let other people know about the other key (Palice) without compromising the security of the system.
Similarly, Bob will create a pair of keys, (Sbob, Pbob). Note that:
Bob knows the keys Sbob, Pbob, and Palice.
Alice knows the keys Salice, Palice, and Pbob.
Alice sends a message to Bob
Now, when Alice wants to send a message, Malice-bob, to Bob so that Bob can read it (but no-one else can), she has to encrypt it with Bob's key Pbob. So, she creates a message:
Calice-bob = Ea(Pbob, Malice-bob)
Bob knows (from external evidence) that the message was encrypted with Pbob, so he knows that he must decrypt it with Sbob:
Malice-bob = Da(Sbob, Calice-bob)
However, at this point, all he knows about the message is that it came from someone who knew his Pbob key. He does not know that it came from Alice except via extrinsic evidence.
If Bob and Alice agree that their messages must be encrypted such that they are both confident that the message received came from the other, then both must be confident that no-one other than Alice knows Salice and that no-one other than Bob knows Sbob. They must also be confident that Palice is known to Bob and Bob must be confident that Palice really does belong to Alice, and that Pbob is known to Alice and Alice must be confident that Pbob really does belong to Bob. Establishing these trust relationships is a lot of what PKI (public key infrastructure) is about.
Assuming that these criteria are met, then Alice can send her message to Bob in such a way that Bob is confident that only Alice could have sent it. As outlined previously, the mechanism is a double encryption:
C1alice-bob = Ea(Salice,Malice-bob)
C2alice-bob = Ea(Pbob,C1alice-bob)
Alice sends C2alice-bob to Bob (along with some signature or MAC to confirm that it was not corrupted in transit), and then Bob computes:
D1alice-bob = Da(Sbob,C2alice-bob)
D2alice-bob = Da(Palice,D1alice-bob)
If everything has gone according to plan, D2alice-bob = Malice-bob.
Mechanics of RSA Key Pairs
The RSA encryption algorithm is based on the fact that if you have two publicly known numbers (which are two parts of one public key), the exponent e and the modulus n, then given a message m, it is easy to compute c = me mod n. However, it is computationally infeasible to deduce m given just c (and e and n). If, however, you know another exponent, d, then you can magically calculate r = cd mod n, and r = m if you have computed e, d and n appropriately. It is not feasible to compute d from e and n without knowing some other information.
Under the RSA encryption scheme, you start work with two (large) randomly determined prime numbers, p and q, and their product is n. The RSA algorithm is predicated on the fact that it is extremely difficult to factor n (determine p and q given just n); if anyone ever finds an easy way of factoring large numbers, then the RSA algorithm is instantly broken.
Once you have n, you need to determine exponents e and d such that:
ed = 1 mod t where t = LCM(p-1, q-1), and LCM is the least common multiple.
You can choose one of the two values as a small odd number - Schneier and Ferguson suggest e = 3, for example. You then calculate d using some computations that they cover in about 6 pages of their book. Typically, d will be a rather large number. You can then publish the pair (e, n) as the composite public key, keeping the values (p, q, t, d) secret as the private key. Given e and n, it is not computationally feasible to deduce d without first factoring n. "Practical Cryptography" suggests using two different pairs (e1, d1) and (e2, d2), derived from the same value n, where you use e1 to encrypt messages, and e2 for digital signatures; they even suggest using the values 3 and 5 for these.
OpenSSL and Key Generation
Your description of how the RSA keys are generated by OpenSSL is confused, I believe.
The generation process first has to generate to large random prime numbers, p and q in the notation above. There are stochastic methods for determining whether a given large number is (probably) prime; it takes a little while to compute two such prime numbers. Taken together, these are used to compute first n, and then d (assuming e is established by some convention). The two stages you see in OpenSSL are determining n, and then determining d.
Dissection of User Case
The question says:
Consider that Alice wants to send to Bob some stuff in a non-traditional way:
Alice and Bob once met and Alice gave Bob a "public key" generated from a private key she created BUT she warned Bob to keep it secret. AND she kept secret the private key, and didn't ever give to anyone else the public key.
So far, so good. The 'public key' isn't very public, but there's no harm in that.
Could Bob be sure that messages he receives from Alice (provided these are encrypted by Alice private key) are only readable by him (provided he really kept his copy of Alice's public key secret)?
If the encryption technology is of any use, then yes; only Alice and Bob can read the message that Alice encrypted with her secret key because only Alice and Bob know the public key that goes with her secret key.
And how compares this encryption solidity to the traditional way, which would, in our case, be Bob sending messages (encrypted by the public key of Alice) to Alice?
Confusion: the section started by discussing Alice sending messages to Bob; now you've switched to Bob sending messages to Alice.
When Bob and Alice met, Alice gave Bob her Palice public key. Presumably, Bob also gave Alice his Pbob public key. And both public keys have very limited public circulation - that's good, but not crucial to the security of the system.
Now, when Bob wants to send a message to Alice, he can encrypt it with her Palice public key, and Alice (and only Alice) can decrypt the message using her Salice secret key. Alternatively, Bob could encrypt the message with his Sbob secret key, and Alice could decrypt it with Bob's Pbob public key. Both sets of encryption and decryption would work.
What the question is about
The fact that asymmetrical keys are named "private" and "public" doesn't help understanding my question. Keys have underlying properties, and it's me broadcasting the "public key" that gives it its "public" property. Please make this distinction clear before answering: I'm not considering the "public" and "private" properties of these keys but the solidity of the "private key" encryption versus "public key" encryption.
It is equally reliable to encrypt with the correct private key and decrypt with the correct public key as it is to encrypt with the correct public key and decrypt with the correct private key. The difference is in who can do which operation. If you understand clearly who is doing the encrypting and who is doing the decrypting, and who knows which keys, then the secrecy of the methods become fairly clear.
I cannot use another terminology even if it is misleading in this special case.
Well, the 'public keys' in your case are not all that widely known, but that's all that's unusual about it.
I know that this case is non-traditional, and could lead to several inconsistency, or is not the point of the asymmetrical crypto systems as Bob and Alice here share some sort of a common secret and that's not the point of asymmetrical crypto.
The whole point of asymmetric encryption schemes is that it does not matter whether the attackers (classically called Eve, the eavesdropper) knows the public key. As long as the private keys are kept private by Alice and Bob, the messages can be sent securely. However, you must understand that if Alice sends a message to Bob that is encrypted only by Alice's secret key, then anyone (such as Eve) who knows Alice's public key can read the message. Eve can't create a fake message that purports to come from Alice unless she also knows the secret key - if Eve discovers Alice's secret key, Eve can pretend to be Alice at any time she likes. But she can read it. If Alice sends a message to Bob that is encrypted only by Bob's public key, then only Bob can read the message (using his secret key), but Bob has no way of knowing whether it actually came from Alice or whether Eve sent it pretending to be Alice. That's why you have to work hard to ensure that Bob knows that only Alice could have sent the message, and Alice knows that only Bob can read the message.
Simply because when you encrypt something, you are masking it so that only one person can read it (the person with the private key). You do not possess that person's private key, all you have is their public key.
If you are encrypting it with your private key, anyone can decrypt it with your public key - this is the principle of signing - they can tell that it was encrypted by your private key!
To put it a little more explicitly, 'encryption with a private key' means that to decrypt you need to use the public key. This isn't an issue, except that anyone can then decrypt your [insert item here], since the public key is just that: public. It isn't useful to protect data, this system is used to verify data.
For instance, Alice wants to send a file toBob (yea, yea, shoot me). Alice doesn't care if anyone else can read her file, it's not confidential, but she wants Bob to be sure that what she sent is what he recieved. She can then encrypt her file with her private key, and Bob can decrypt the file on his end with her public key, ensuring that the file hasn't been tampered with. But if someone else is listening in to the transaction, they can also decrypt and read the file. They just can't change it.
For the case you provide, a better way would be exchanging keys when they meet so that there are actually two keypairs. You yourself mentioned that RSA in particular doesn't actually workr if you try to encrypt with the public key because of optimisations made in the algorithm. I wouldn't be entirely surprised if this is a common case with other algorithms. They are designed to be run one way (private/encrypt, public/decrypt) and are a known "expensive" operation, therefore they likely to be heavily optimised in reality.
Other than that, I don't see any security concerns with your plan... As long as the keys are truely kept private. Private/public are just common names based on typical usage. There's nothing forcing you to make a public key fully public. In your case you may like to term them 'encryption key' and 'decryption key', but I wouldn't use each key for both. Infact, I'd recommend you did term them such inside your program, for the reasons given by Jonathan Leffler in his comments:
A 'public key' is something that can be shared by multiple people. That's the definition of 'public key'. Anything else is very confusing
I think that you are missing the point of public/private key encryption (at least as I understand it).
In the situation you have, symmetric encryption would work just as well. The reason to use non symmetric encryption is a matter of scale.
Say you have, not just Bob and Alice, but imaginary people for every letter of the alphabet. These people want to be able to send messages to anyone, ensuring sure that only the recipient can read it. Using a normal, symmetric encryption, this would require a shared key between every person, so if we have the 26 people from the alphabet town, that is 26x25 keys, with every person having to remember and secure 25 secret keys.
Enter symmetric (aka public/private key) encryption. Now every person has a private key, and a public key, with the normal rules. To send a message to Fred, you look up his (and there is only one) public key. Then you send him the message. Only Fred can read this message. In this scheme, you have 26x2 keys, and each person only needs to remember and secure 1 secret key. There also needs to be a source of public keys, but this is easy.
Using asymmetric encryption the way you describe, with a pair of keys for every set of people, would then require 26x25x2 keys.
So again, it is about scalability. The number of keys needed for symmetric schemes is N^2-N, where in asymmetric schemes, it is only 2*N.
I don't know if there are some copyright concerns but I'll quote "Valery Pryamikov"
from this forum.
Signature and Encryption are two different prototypes with different
security requirements that among other require different padding
modes. Use phrase "decrypt with public" key was the biggest obuse of
terminology in history of cryptography that was widespread by Bruce
Schneier's book "Applied Cryptography". The phrase it self were
supposed to be used to describe signature schemes with message
recovery (such as RSA). This phrase was also used to adjust asymmetric
encryption and signature to old protocol verification models such as
BAN. However, by it self this is just a missnomer - public key is
known to everybody and decrypt operation has meaning of providing
privacy to the content - which is impossible if decryption key is
known to everyone.
Even so raw RSA allows interchange of public and private key, but in
reality they can't be interchanged. Private key decryption is
implemented with using CRT (chinese remainder theorem) to provide 4x
better performance of private key operation. For that - you need not
only exponent, but also factorization of modulus and multiplicative
inverses of some product these factors. Public key has only modulus
and exponent and can't be used with such calculation.
You're misusing the terms here.
If the keys are truly private and public, then yes, anything encrypted with the private key can only be decrypted by the public key, but if the key is truly public, anyone can decrypt that.
Let's disregard that.
The problem here is what Bob knows. Does Bob actually know if Alice sent her public key to anyone else? If not, he can not ensure that only he can decrypt the message. There is nothing in the technology that ensures this. Anything encrypted by Alices private key can be decrypted by her public key, and thus by anyone in possession of that key. By the very nature of public keys, that should be anyone.
The only way to ensure that a message for Bob is only decryptable by Bob is for Bob to give Alice his public key, and make Alice encrypt everything she wants to send to Bob by his public key, which will make the data un-decryptable by anyone except Bob. Whether she also encrypts the same data by her private key (ie. signs the data) is besides the point.
Of course, again, Bob, cannot know that Alice did not send the exact same message to anyone else, encrypting it for others public keys.