Cryptography

Cryptography general I guess. I am working on something involving public key encryption. I would like to understand more about the possible uses of Elliptic Curve Cryptography. Do I understand correctly that it's only possible to derive a shared secret key between two people? That ECC algorithms do not allow you to create a public key that is analogous to an RSA public key? Ie. you cannot use an ECC public key in an of itself to encrypt. And does there exist any protocol that provides identical functionality? I know you can use ECDH to share an AES key between two people, but that is clearly less useful.

>>34035 >it's only possible to derive a shared secret key between two people I'm not sure what you mean by "only", this is what a public key encryption system does. You've basically described encrypting a message. In general, RSA and ECC have similar properties in terms of how the key exchange works, so you can do anything that you can do with RSA, though I'm not sure exactly what you mean. >I know you can use ECDH to share an AES key between two people, but that is clearly less useful. Less useful than what? In basically every case it's not really worth doing any more than the minimal required asymmetric encryption, even for asynchronous stuff like pgp or whatever. AES is fast.

>>34055 Hmm yeah maybe my use case is really specific. Say you want to do something like PGP to send a message to many people and use ECDH. You would need to use your private key and the public key of all the recipients to create an AES key. Then use that AES key to wrap the data encryption key, another AES key. This is fine, sure. But what if using your private key is for some reason a really expensive operation (eg. it's stored in a HSM and you can't access it in client software)? And you have thousands of recipients? Although I guess you could just generate a temporary EC pair on the client-side and share the public key but destroy the private key. Is there any reason why it would have to be your very own pair? Probably not. Maybe I'm just a big dummy

>>34071 You would make a random AES key and IV, encrypt it with their public key, and put that at the start of the message, then encrypt the content of the message symmetrically with that key. Optionally you could also have something in the message that says what encryption is used, how large the key is, what the block mode is, etc. This works for anything where people have public encryption keys, and private decryption keys, so while there is some property that RSA and ECC have that is useful, I don't think it applies here. (I'm not sure exactly what that property is, but I know that it's a current problem with post-quantum cryptography that could possibly mean changing cryptographic protocols would be necessary for some kinds of key exchange or whatever, like I said I don't know about this, consider this something to research -- it's something to do with diffie-hellman stuff)

>>34076 >encrypt it with their public key You cannot do this with EC public keys (as far as I know). They are not analogous to RSA. Here's what I managed to figure out. Something like this should work for PGP style key sharing using ECDH instead of RSA: 1) make a temporary EC key pair 2) Use the PRIV key of the temporary EC pair and the PUB of all recipients to derive a shared AES key encrypyion key (KEK), one for each recipient (each PRIV+PK produces unique curve params). 3) Generate a data encryption key (DEK) 4) Wrap this same DEK with the KEK of each recipient, attach KEK(DEK) to message with user ID 5) Attach the PUB portion of the temporary EC key pair to the message 6) destroy temporary EC private key, not needed anymore So now each recipient can 1) Get their KEK by derving an AES key with their PRIV EC key and the EC PUB in the message 2) Find their KEK(DEK) from the message 3) Access DEK, decrypt message

>>34077 >You cannot do this with EC public keys (as far as I know). They are not analogous to RSA. Yeah, seems correct. https://www.rfc-editor.org/rfc/rfc6637 might interest you.

>>34079 This is exactly what I was looking for, thanks. I love RFC so much it's unreal

>>34071 Checkout the AGE spec. It is basically made exactly for using ECC and chachapoly to encrypt to multiple recipients.

Nobody here has mentioned Elliptic Curve ElGamal, which I think is probably the way most analogous to unpadded RSA to encrypt a message, with the (downside/upside) that it's not deterministic, like unpadded RSA is.

thonks on winternitz one-time signatures, XMSS, and SPHINCS? Personally I'm dubious about the 'stateless' claims of SPHINCS, it seems like a needlessly complicated XMSS. But the basic ideas of WOTS and XMSS are very cool.

>>34035 I think cryptography is one of those research fields where nobody will teach you anything if you do not enter a secret society or similar. That is because most cryptographer lives by not sharing their researches, applying their know-how and getting paid for such knowledge. They eventually share their researches when they need academic recognition or funds. I think this is a case where knowledge is power, keeping it for yourself will get you a lot of money. On the other hand this may be seen as a toxic practice for the field of cryptography. I'm sorry, but I think you will not be able to create a "cryptography general" like there are other topics on this board. Not yet, I guess. Maybe this will create some starting points for a new general thread. On your question. >I am working on something involving public key encryption. Use libraries I guess, or follow RFCs. But I guess this also depends on what you are trying to achieve. Or I guess you found your answer in >>34079 --- >>34085 I'll append this RFC just because it contains enough information for other to follow. https://www.rfc-editor.org/rfc/rfc8391 Honestly I know nothing about those, will review later, hoping the post will be still alive once I'm done.

>>34220 >most cryptographer lives by not sharing their researches, applying their know-how and getting paid for such knowledge That sounds like security through obscurity. It's better if anyone can vet whether your magic tricks actually work.

>>34220 > That is because most cryptographer lives by not sharing their researches This is probably the least intelligent post I have read on any website ever.

Anyway, some stuff on lattice cryptography (currently the most appealing family of post-quantum cryptosystems): http://web.eecs.umich.edu/~cpeikert/pubs/lattice-survey.pdf is a "basic" mathematical introduction and overview to lattice crypto there's also this course https://2017.pqcrypto.org/school/schedule.html about post-quantum cryptography in general this course https://www.isogenyschool2020.co.uk/schedule/ about isogeny-based crypto (though less complete than the previous link) also various other stuff exists, daniel j bernstein and johannes buchm's book (attached), this game which seems to correspond to the short(est) vector problem https://cryptris.nl/ gonna try and get more into the mathematics of this, I think it's a bit more accessible to me now than it was when this thread started

>>34401 >seems to correspond to the short(est) vector problem I'm not confident that this is the case. If anyone knows whether it's this or LWE, pls post

>>34220 any decent cryptography is pretty much entirely published publicly, what the fuarrrk are you talking about?

Can someone post their public key for me to try encrypting a message with? I want to try using Kleopatra. Online PGP tools don't work for some reason. Please send me an encrypted message too. This is my RSA key. -----BEGIN PGP PUBLIC KEY BLOCK----- mQGNBGPxqVQBDADt63cSZpMUW+8Wn3hFsY11/LakaqAUNqk1BoS74tmRdfyrnWq+ gc0kWUAejbabLDiXuzSKLZhIXO0sFJVTeYhcz3d5Kgf88+IJ1f3NlOT3MlEDNWMX SBNSzv+wollNouDbwUiDCD9joKaoLO+YZ6f+DM7rVT5XWLmVMa8jTVVAuSAH1Yef xi+dggqqRHeOkRy6k78NZnVRvcSYQmxfRmm6F6gW8sFYsq3fGkJ7MAzrfXqeTHj6 gMja/WmbJIITu/AqYYtYp8jZr/dJNTS19OWyp/wGoY+Nj1vHDrFuPSTbyEnLXtww 1anKvW206s0lDkXaLWWRFhOyISZoWWOWS6/y+F9cVOzYYB+0t7cXGLlgNWsPFFDW wXGnXHmGYv4azt+WC0uL5D7LT5I/c5rfNivj/IKxf8/IHUB7byGRmEPdrZv/1qfZ PsKugAU5H4VA3G5HP5gKNas5S6ZAIt3xW0fxCXStF8NDEFVnqM26R5oufz+hFnLE 2p39DFDZQS+UhuUAEQEAAbQ6Tm9uZU9mWW91ckJ1c2luZXNzIDxOb25lT2ZZb3Vy QnVzaW5lc3NATm9uZU9mWW91ckJ1c2luZXNzPokB1wQTAQgAQRYhBPE31em5cmYQ qXj34gMNboB7gHcGBQJj8alUAhsDBQkDwxM8BQsJCAcCAiICBhUKCQgLAgQWAgMB Ah4HAheAAAoJEAMNboB7gHcGg0gL+wfF+mctHkfP7/LFKKumW79pRE7GXBTgcF1M tAD3TyGfOFAj35MC/o95R2Q1o4K/F/yKpZNCC49N2M4pcmUrfSNtq757/ngl7ivd aTP/enmbLldZ5pvrE3lEDqYJOFuSmhKHbui52zbHIcBtzKkiZA6Xk5+aB7SmJoKy gTdfbyoRHPtl/2sJbkZfAWy5gr+2Oxz4c7rM6OZ/0IK7tdNTgwaCWT+aVOH003FS bMgmqZFEz83xcKTdwZ5iFdXmjJ1wwkBrtUQvwAiT0VUVoMeVQGh3Uw5TCzZcl+Rn tgtHCptDojbSA+srbdw8CuIInI0z17cMuQ6RsjBUFbzgfgg7kqRBhHKYViTfJqcM GI3WA6wQT+235qPz6CdGwkhLql5HJjnbPT2gquAdVvc8FlqvTzIzfCA+q+V6zU6/ cD91N+LSLxWSNPp8NAkM3y9Lz74RK7MuYcjn7e8rdhjGpLMvNtUVa8N78xLnbH4s mywI266AWtHCL6sdAl2W96s6i2sF6LkBjQRj8alUAQwAzehrBrHrvecyFLgzPFq/ SytlcfpnFtq/0CG5H0n0QPhWBTXBDqOOZAWZ86KeuUvtyKo52k4/D3BYgUxg1Y8g WRmTGyADNkDzdPXQLmRJ6Xm+pjFa4sBlVTkh6yo1RDKdh27uBwJGMopCg4YhyXrl lBAVWhl6DrK/CLsPVHKGYlS/gx8zbvqbf0I9QuDXwXrERIx3AhfbB20VmReWAnyQ 3lm0UAv5/1t/MdpOX7He5ZfO7gCQx3C7eOmFEhNWuTLq9FlvmbcrXHUowIIrH/eE W1x9NcDbRACPQMDpLiD9r40mjOVsniLtc8gUptyIzUv6P04Z2GQdhHYq/EMvPcTq b9/KcZPAJOR/Ki1f/Ba/Bfx+eBCPGsQMeVYTTaRrH1sEOD1KMKOggST24Uym3YLt Az1PS9vpxrRdlbaUrOHopeCDwhTD5zmRVTZftcBtNcBqgGsUzqJaZ1gNfkjdBkJZ YFkba9s3i12UAFTVuWNyZ/sEacSf3Bh0vUpB/sKs35kDABEBAAGJAbwEGAEIACYW IQTxN9XpuXJmEKl49+IDDW6Ae4B3BgUCY/GpVAIbDAUJA8MTPAAKCRADDW6Ae4B3 BvPdC/9g4oqhvHJ3TGQzfaXCLv8vZTMIcC2h815UAz5X76TABx5cymdIL11PwmMg k1FWXJxOQPw/iouOqsP9prRWX0L/pCD+874OGzFkB7wOG8ATL4MthDTRiVqIb4MV Ab9zMcdGr7fLKP9qhKnBOC4679PkeQ3yQFqzEvV0XydTqQ/+j1Mav86tpCR96ekr WktluS5lP95QPaxw6cK6o5edpUoq4I9MICkqDRgdmwQXmMe3rDO+HQfzQ8+6z53i oSxF6plDd/hDkWUsMq1PsPaXhTn2f/GYa/jLqz9ebrJE6QFP0GE8/b/cLIbYPfVV w3OzCL3yMLLoo4MtPStLSPhP+MaVgWKP8vMpU8aDBaBZK/ocXeGGys7zsrUikh2Y qHrFQtnbT0r6Gc8ISpKZvA4Q3HpoaZ7Htqb1jFzj8aonZX/LiI9QrRQ7HX2LyvPT mYTOXeFosIIF7frj7o6gueFw28vbjAUIytekXHOufpgjZyQ9wvTLL+Vk2wx8XeKF tKEq7j4= =COGr -----END PGP PUBLIC KEY BLOCK-----

>>34407 -----BEGIN PGP MESSAGE----- hQGMA9uGMHDkCJVVAQv+KN0ApOGbI/Eu3XobHYZSlNEoLWNMC0ImIF2ka+78pEVv Y0Xxaa4uQLvRvHDK6DJPlxBPai/8g2obrVn39y9jMv+5uy2IpTmhYqxdbY/Qg0VL NBPx7Ljaq3EXcscJPqKPmZfLNg2ewU3Y8JfvaZsbpVGOZR/BQ9EWu/YxI/AQ8+TK tQni73nKpzw+6JiginCtN4UINIcdIZNU074WhyKdebujBBDuufU8rJVpxExfIIU3 K8tGTW2r1ZBUIXaeM0uhBE1cD7CbSZyqpb6udGsZAtAd+wR7ii99QpA5cc3+htEj k22lDjKLb7hQGv/nmsqdPbC/WQcxbpsi1L7rgdu8Hk01uG1ReEStZ55MK9wWmZcu t8waODcAHLnfERTe4KBUxUQ4ctiS8VDGB0K87V9JqSh2OhHLjsbTEX7ynicTDDZg hdqatlTYU8jBzt+iC5//OwcE5LMiFFElS/nsFF0ySaBPjPdf0g6XVyeYeNJCgEhF 13Ny2mzJlHT7+f6ATOvn0ukBqgwFewbo6q7aPurJjAzEk1eRsyNBQIof8lJexhyr WVJbH4lNptdn3Wi0rdy81iviYFaoqB2uS3n68T3j69xQlPKra60go9dhD+DSuKki B0oP9h2mKn5Ghc2P+qxWAREaJJur8nWgAwP+aqrJJZn7P5npWM/YdRDcxSvtPsIw fj2Jf6vID2bHUss5mwa+UEB8VgFpCBxIJ2Hx982byZf0ooffumT2J3xYSGvOmIXv +Z4GHlAPtJ9nglHjS1EIKUCDrDNOnyoXNcLbh7aw/hXebYko1z2qua1zRr4Ee2wJ +pfdsZa1LckGYVGWNpwTrOnLQMczn6j2KI3gepHRGYrK1+cKBd0baBNULXvENU/6 dLo8WQ3exKPYpCRxEjPEMmPN9n6pUfZYnubmd8HdujTn9pjbj0IRTwP+nuqAIw0k IBje3NDVVcDaBXaFh52RFmIzlDPQC6k6BkU+tAzSnSxXCQ8ZwEvRjSkP7ts/II2+ l2KxvNpOwWI7WORJ2gYuGUATI0CUZK59N8qBiubgqrROifUSj47AbXFa22MRMzVP jAEbc3W2BklbwSeD9x3VsSyDgZDoqxb2jqffasVyv8MeMDE24vsRMrP29OO5YMnU QSuEc1FTXFIFGcly2D+dqudSndx6jCukioKCz5bzQXqFxpHXoH4qd/jiKF3cCONT x6feikv0MXRj1gJF0ZdDjXy8MWrasrUXpnD1dy9iBazdkbBcybu7lAVxNEOAZqzo E6lU85Ni1HXexEsimDBHWzfasn6UlX0ldFT+pgaZ9T3iBq24RxwUYakriIQJmhPy ZIytt01KhmHQnEJw4ITewieDYYD5D0/NYRQMFKsICu3ocCFIfddU2biAnbaocHUc VbZo2zYjHCZS+QWqFJIeMjaEb3GsljKT/A== =LYkj -----END PGP MESSAGE----- -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBGP0HQkBEADzHfDZr7ylPfFzLFCd4CEsbA+wwKTwq1VqC5ajbRjaCBRVx7Y/ fg1F6vQA/5Kp/I/uR3aFSNSD0qxxe+uwxT2/b0/0pcZ3cuREGg8DqcIh6mc7L7N2 SV+wnGYI5XQ7ABxvbA+Ucai+Xkfqi8EsYVn/Zr89xUHVMTSnPj/zdLsnqVmu/CXW rdm57uUjvsk3ytXbWt6nNFnuUZdrhW94e+Ut5I9pWbYvQ0Ik091gH4O/IiGODidy Ww6wC2spk4k9QiudPumLie3FMVGXVio5ys5Fl6qItawYcrf09p4busLncy/dIhHd u33MG5JdwT4xlTHnHLsC/Ep8QvE4vvbNEDQkECRejE9aI8CO4BHTjOw0pjC/zvee datBq3jA3gg2V3a+Jfk6S3+/1gbwZ9vHBALDLfRLsP4XsKu8VKIFZoJgiWqicl5M TKs7m1DoB963ezeHXbNf7736jWwu1pSRl9cfH6w0VTgKzwJ4zOPLaPfig5B9+d4W RuXuTi5ca14P2F+Rxjf0J7k0ag3Cno0r6KWjIZF+U1g+CH3Ye3JSLtnrImY+PZNA /MOPh9mL2Db1ktJ4ISVG+6m5hqr3sQr+68tXMRbovpgePaLxch0AjZNwoG1Xbxcw G/IDcMsW3LQkwkIFQpHqLK46iP8JBFGbSoiDRPJ049nD2cxUUdUdLpTGywARAQAB tB5Kb2UgU21pdGggPGpvZXNtaXRoQGdtYWlsLmNvbT6JAlQEEwECAD4WIQQcqPGT /vBiHTM0gCilKbKSCrbDEAUCY/QdCQIbAwUJACeNAAULCQgHAgYVCgkICwIEFgID AQIeAQIXgAAKCRClKbKSCrbDELKTD/4uIdCfDXNGdD1dVmIx6LNjotnM3j7uPjbq fNYXo+CnJn0wHJNjaoELxXcuTF1Uso90U3tBqdXWRSGkLQ0HejrWbIiY9OlZ/sZl 4pWjkpVxbCcR62F7pbW50t5x+dxsKz3NtS3xoy3+A3CsXcbnR0IC5hpcPykAPTuN nRc+NO47mWn4G6bisJ79Ty3hv6e6V1JorhdP1LZi3GXwKdlys/RQrX2g4+3l5Mbi +Q0PROBxbriP9HKxmJ+Lh+nkWr/RWSk4Y7pzaWhtspB+bEeGNN/WO1zQokQa8p1s gwpsMQcE+RNx+AIwCwmXjia5bdg6lRQpZBH+Io+BRTl5jNxiGvvWVn8C9GQK2YYc 4BbN9irhCxzITUbuALT88O9FqBbyLJuIehXU5U4UkrmtlLPq5YPkPw9woiDhwp05 Kjc8t8YWCFPGBWWd+EhlvAcWghS9jCCQjcccdggofNK8xwCnelPkHisPAEbYp10Y NLQWrnD6kqYwMUKsHPP8bmA1ySRbzj/VwUCKPQhsgVscXCjWCroAiakvhtHGL4yX eC21sfazrRnfz9UM3bGW0zCPRE/x+IuObXsBaqdHGfm2s3c/VxDVFmp+A2usMIAc TSW0hSzNcalZMfbP+632os3+v0OoXLinksrrGXXcmWTQuzT3hgR/d8sydDW/+2Ci Kbht4UYCSLkCDQRj9B0JARAAyV8jZXa4PKt5GOGRdnN4QB+p85XsoC1IrgWZeNtL Q5Ybd44MOfWAwo03FqhMsa6mcOaI17c7z9gwOieR7J733CBxZo3oDpfENqGAZS4+ eWpt/Iboo7eQLSbBSHLf07ONYtM21PmLkhhP6UJHOinwYxwoSquvXcskYeTzi8my g1q8auFaOeAL+i98CU0UiiU4KYu+6Xm39pDyekLeCsZgi74aUPyEl44hjV5msIGW eu4QsAfN8SUqGo7zGohbQjboZRrnz2D5eML13BwajXZK0Rfq+WDQZGQHQiZQqmQr LfH3/+yrfyLYhWPPvBFv2Ar3KlOEBEsqkqXaFoIQFQQaxDO4GB5YyqulfSlgnEVZ XWigzzoKM/NNdHZCLxD4BIEAJtkgsBEK4blndE/4u8IJnBx5Dn3KVKcF5Oz/HTGk 4/8W94lx7A5XFS5gp/IvhBtBD/m5QAV4e9kbAdA4gpNxvZmXmuHX9sd42bPU/Afs E3e6vpW5GdjAwKKW1k4oE1/iFRa968eBi6uPadKjgvEIHB75grA7W/CmvJrneiEx V8aF73g9IF+GblJs6bgZPjXpZw0OR/hZNoakrpVwz+35BO6N2ajiHE2UoYc57jt3 7Qr2ief/F8EA1sW3HouVL6bko8N1IXHWPI+X7duZxtsdy3VGKBUnwSPN1i5IR+he df8AEQEAAYkCPAQYAQIAJhYhBByo8ZP+8GIdMzSAKKUpspIKtsMQBQJj9B0JAhsM BQkAJ40AAAoJEKUpspIKtsMQdoAQANsH/OUznwi5B4kbu3lNXhnN+2MnLoikvY8S onCuzA95qmNAY+XUxMnw+Oe/223E08Jzj/AACxF09zGbqqxo8mR6yoXdey7opWrx 13G3OuylSij7WHuvH/tkT7ogzovTSaApikEM3T9N619mNhqdNpclTvLzgUkiy685 Jnakzfo1FBfCM8uT66+Z3ZQnLK7OqS/c3hF5cneWT6wUcRlrWz0r7ZoDZQgkuW5i QkBXYrvapTHn7wL3y6Sj6VSLGgRKFf9klnR6yeRJEE2X7leZd3vnkmaotCkbafMp 5sYhpaxsWfk9fLbv5yyYrJdihFZTYiX1htTUZDJr41UvwZfGL6gYws//s8YRt1gm bXcw+AqHHnHYdRvZdJ7KHF69BYVNMs+71AaAOLZMSef3y5Ba9ob36CeXqVDRqEn+ 5QHWnkIAu3lv/pDA+C37tU5/bLwwPjCZV9Sx5iyqEN+elFfwhn/wUW6ro2zQkdAt MbU/nEeAJYuB28AMmWHMmDXFrg5gSD2Pigyj6mU0hL8jmDyRJqu/uwgObrTorLo9 V2MpSnNzK6jxFFlNCcKkpW+oxv/2mCLNGgPCyqWBAExB/tbMPVM0SU11OxhzuByB 0k39i613cpZLPJ8SAnL0ccz72vDj4lBmAHKzZwzJldo04TXNycRSICa2kBb1eVZq SfV6vJsh =V36+ -----END PGP PUBLIC KEY BLOCK-----

>>34428 -----BEGIN PGP MESSAGE----- hQIMA05/OL+4QAUNAQ/9FX/Z3KW1XQEN/EisNSfe+iNIOcfhxxccHO7JOdCTSxqD 9quWDHjY166/0QyPWZ05xEmmqmJGGrWioHm4yA+LiaKSpP6OY3QkJm9PtHjeS7Fe +ay3NYT/bNc2Acdyk6qc6+5uh0crvQol7aKtpRAH66xAMFObeMw0GwLFKgV8PWHp RIyp2qH5ybGvWwslivnMrZLsxKKA3fgvbRSHlQ2rdTMi2sWwhq/K9hXtz+aiqdEp jcYWUjW1v9xpevbl47z4F3SX+2xYrXHsJDczy8JyluESuzF/qRgLGwoRfwrToXID ja+7o3KO1JFbYxzYwfpJOLPiCUPafAbmcxdeexgWiJKS/yMcLbvgvDpjU3uxCNmE tkQ11R0EwLkEeMZl/5Noju3oXoJh5ZzgEnIwYO7H7JXuiHj5gxPQs+9LRAjjM8Fr iFKbbKLclOtyVJzi9DRYgkuysXm2xRb9YZ2xgMnUiY8vH1+1wWc1R+8haR4RULsp +JMyHBcH5GniEYg5Kd1Ktq5cpBHlePPPARKU1x8DCyRnd5/Zk+4P+VvOqHjIeItK ICB8QhW3uW8daFu5y90t81/IPmfQSp2Tz8E8N+LGiOmSWUpnv7QEhuPEb5a1u3Yd flQ12bSFAGs0WGtqAVD0hZqTeS6dT/mxOfQYzu9FAw0qgRIwYCIjZAV4OY2lpeDS dQGWtmr/7VQrsMH2m/GI6jN13RcF9GNcuU4Y4qCkQ9DvNpJN9lvP/bwkjVuDdcHS +P6ENq+PxJ1sFbCntsJ33CzK2GFM43awTcBvwtxTETXUPb4M6A7WCkwAJBXH2e5h YyGH21/J80iSAr1iqQ7yi+XSO3bl6g== =OMNX -----END PGP MESSAGE-----

>>34232 >>34397 >>34403 Except they will not explain which part of algebra they used to make it work nor which test they made to figure out it is secure or not. So you have to start over every time and assess security on your own if there is not a paper on it.

Idk what people are talking about in this thread... So you want a C{A/CCA secure PKE using elliptic curves? Use Elgamal or Cramer-Shoup. Also, this nonsense about cryptographers keeping their systems secret. This is only true for the government cryptographers. Any cryptographic scheme should come with a reduction to either the security of an underlying primitive or to a supposed-hard problem. Don't touch anything that doesn't come with such a proof. In fact, don't trust most RFCs as they don't even come with proofs half the time and are insecure. (Source: I know quite a few professional cryptographers)

>>34442 Most RFC's refer to academic papers where such proofs are given. The purpose of the RFC is to provide a standard specification (as usually academic papers leave a lot of parameters up to choice) and describe how to implement the algorithm in detail.

>>34435 Eh? Have you just never tried to read the literature? Most of it is easily available online and there are tons of papers, textbooks, blog posts, etc. explaining how and why different cryptosystems work, and how to break them.

>>34443 Unfortunately “most” is doing a lot of work there. Take SASL or the XMPP rfc for instance which has trivially insecure building blocks and no proofs.

>>34447 XMPP is a chat protocol, not a cryptosystem. The encryption that's bolted on is called OMEMO and its specification here: https://xmpp.org/extensions/xep-0384.html#protocol-overview references documentation from the Signal group of the well-studied X3DH and double ratchet protocols, and references a lot of academic literature. The building blocks used are bog-standard ciphers and hash functions that are very well studied.

>>34449 Just because the double ratchet is secure doesn’t mean the rest is ? If I authenticate you by sending my secret key to you along with my normal key exchange messages, is it still secure? There are building blocks used in the XMPP core which are insecure, so I don’t trust the security of anything in it.

>>34435 It sounds like you haven't looked at any real cryptography papers. The math is always either directly in the paper or clearly cited. It's a rarity that there are unexplained pieces (but not entirely unheard of. Origin of the NSA's elliptic curve parameters comes to mind). Can you share one of these sources that hides the math? I'm wondering if my definition of cryptographic literature is different than yours. Maybe you just aren't looking in the right places for the information you want.

>>34450 >Just because the double ratchet is secure doesn’t mean the rest is ? The key is encapsulation, lain. As long as the assumptions of the double ratchet are not violated, any cryptosystem you build with it is just as secure as the double ratchet itself (excluding side-channel attacks).

>>34453 Not that lain, but this just isn't true. Matrix, for example, uses double ratchet, but because of bad design relating to device identities and home servers, it was possible (until a few months ago) to easily impersonate devices and gain access to chats arbitrarily (see "Practically Exploitable Cryptographic Vulnerabilities in Matrix" for greater detail). Using good cryptographic primitives does not guarantee that a cryptosystem is free of other design flaws.

>>34435 It looks to me like you don't understand the math and frankly never bothered, it looked like a spooky bunch of math symbols to you. The literature is abundant.

>>34464 So, software violated the assumptions of the cryptosystem and the result was insecure software? What a shocker.

Where does one learn about secure implementation of cryptosystems? I know the math, but as everyone knows you will fuarrrk up when rolling your own crypto, I have never even tried writing any code for it, kot even for educational purposes. But where do I actually learn about all these possible mistakes, are there any good books on this? Maybe more modern that Schneiers classic >>34442 >I know quite a few professional cryptographers) Interesting, can you go into detail a bit what exactly it is that they're doing? Because I can think of very few actual jobs where you could actually work as a cryptographer besides a few research positions. Btw, which institutions does most of todays crypto research happen at, besides intelligence agencies? Any famous groups I should follow to see current trends?

>>34484 No, in the case of Matrix, a flawed cryptosystem was designed using good crypto primitives, like double ratchet. I urge you to read the paper. The two or three main vulnerabilities in that paper are design flaws, not software flaws. None of the constraints of double ratchet were violated.

>>34574 Most of the people I know work in academia, but I also know people working in research groups at microsoft, cloudflare, visa, NTT, and fujitsu. The majority of them work on the protocols-from-assumptions side of things rather than the assumptions themselves, but the people I know at fujitsu are working on supersingular isogeny assumptions. As for implementation, I know a couple people working on secure implementations, but can't speak to that too well as they mainly focus on the protocol design side rather than the in-code side. I've written crypto code before benchmarking and PoC (proof of concept) but never for "real-world" use.

>>34586 Oh, and some people at algorand. They looks like a blockchain company, but they're doing interesting stuff as well. I think there's one interesting company whose name I've forgotten, so if I remember is soon I'll post it here.

>>34576 You are referring to this? https://matrix.org/blog/2021/09/13/vulnerability-disclosure-key-sharing/ >This is not a vulnerability in the Matrix or Olm/Megolm protocols, nor the libolm implementation. It is an implementation bug in certain Matrix clients and SDKs which support end-to-end encryption (“E2EE”).

>>34588 No, as mentioned in >>34464 the paper is "Practically Exploitable Cryptographic Vulnerabilities in Matrix" https://nebuchadnezzar-megolm.github.io/static/paper.pdf >Trivial confidentiality break: In Section III we start by reporting two trivial attacks breaking confidentiality of Megolm channels, the central object in Matrix secure messaging, thus breaking confidentiality of user messages. These attacks exploit the homeserver's control over the list of users and/or devices in a room. The attacks differ in whether they target the list of users in a room or the list of devices of a user. We note that this attack does not break confidentiality of the underlying Olm sessions, nor does it break the cryptographic guarantees of individual Megolm sessions. Instead, we use the homeserver's control over the room participants to force target clients into sharing decryption keys with devices under the attacker's control. These attacks are enabled by design flaws. Note that Olm is just Matrix's implementation of double ratchet and, as mentioned in that excerpt, it is not broken but rather a poor design decision allows malicious home servers to be given decryption keys. To put this back into clearer context since it's been several days, the reason I mentioned this was in support of the lain who said >>34450 as it is a real world and recent example of a design flaw in a similar system as XMPP with OMEMO.

>>34586 >>34587 Very interesting, thanks for the detailed reply!

Can every one-way-function be used to construct a cryptosystem? If not, what are the requirements?

>>34599 Well it depends on what you mean by > cryptosystem But in general? Not likely. Any key exchange protocol using only random oracles (idealized non-structured one-way functions) in a black-box way can be broken in polynomial time. (https://arxiv.org/pdf/0801.3669.pdf, https://dl.acm.org/doi/pdf/10.1145/73007.73012, https://eprint.iacr.org/2016/812.pdf) The second question is an open problem, but maybe this paper will help orient you: https://eprint.iacr.org/2017/365.pdf

Hello, lainons. I've been looking into learning Zero Knowledge cryptography, Fully homomorphic encryption, verifiable computability and multi party computation.

>>38223 I cut up half of my post for no reason... Anyways, I was wondering if someone would like to talk about this stuff? At least briefly. I've been looking into https://zkhack.dev/whiteboard/ for starters.

I've been trying to come up with a way to send data through my app encrypted. So far, what I came up with is something among the lines of: 1) I send my client a public RSA key 2) My client generates a AES key and encrypts it with the RSA key 3) The encrypted AES key is sent to the server 4) All data sent through my API is encrypted with this AES key Is this approach good? Am I overcomplicating things?

>>38227 If you can, use X25519 instead of RSA. It's way smaller and faster and is just as secure. For your usecase you should look into Diffie-Hellman key exchange, preferably with ephemeral(temporary) keys. With X25519 it works like this: - Client sends public key pA to server, server sends public key pB to client - Client computes kS=pB*kA, server computes kS=pA*kB Since pA=kA*G and pB=kB*G, we get kS=pB*kA=kB*G*kA and kS=pA*kB=kA*G*kB Ideally you don't use long-term keys for encrypting the data but short-term, throwaway keys which are signed with the long-term keys instead. Since the private bits of the throwaway keys are discarded it's impossible to recover data from old sessions if the long-term keys are leaked somehow.

>>38229 This is an awesome solution. This morning I started thinking more about my proposed solution and I could still see some problems, like if an attacker managed to send the client his own public key, he would in exchange receive the AES key. Your idea is pretty neat, and I will most definitely look more into it. Is there any paper or article you would recommend me reading?

>>38232 There was a blog that explained elliptic curves well, though I don't remember which it was. I did find this though https://x25519.xargs.org/ which seems like a very good resource. The ephemeral keys thing is related to "forward secrecy". >like if an attacker managed to send the client his own public key Normally the client should already have the server's public key or have some other way to prove the key comes from the server (certificates + chain of trust). Without starting from something you already trust you're pretty much blind.

>>38232 >>38234 This is the catch22 or paradox of authentication. If you don't have a pre-shared value or a PKI/TTP then an adversary can always pretend to be Bob and trick Alice into joining a session. Basically, you have to be previously authenticated to authenticate. I suggest using an AKE like (X)3DH / HMQV or a PAKE. However, this will require preshared secrets which is a requisite property of any AKE protecting against the attack you dsecribed.

>>38227 ideally you should use a key exchange mechanism that both the client and server have some influence on. otherwise a malicious (or poorly written) client can pick a weak key. depending on your use case, that may not matter. the bigger consideration here is that you'll need to ensure that you avoid any of the many pitfalls associated with encrypted your own data. For example, you said AES, but have you considered which mode? Some AES modes are not suitable for this. >overcomplicating? If this is for a serious project, yes. You should just use a TLS library instead of implementing this yourself. If it's for a hobby project, it's fine.

>>40912 Trick me into thinking a conversation is happening in the cryptography thread? No sir, this is a cyberpunk website where people don't talk about cryptography because we are all frauds.

So, I'm doing the Cryptography I course, from Dan Boneh on Coursera. I mostly want to learn cryptography stuff to develop payment systems. I will be honest, I'm kind of dumb in terms of math. I'm not even sure how I was able to graduate in computer science with all that math. And it was a lot. I'm still working on the math daily, to make sure I don't forget it. Training it like a muscle. Anyways, my intention is understanding cryptography for payment systems. Most will think this is just related to blockchain stuff, but there is much more to it. I'm more interested in the "verifying" part of cryptography. More than the "hiding" part of it. No one mentioned in the thread, but there are these things called FHE, SNARKs, TEEs, there is a bunch of soykaf out there to be used in order to achieve what I want. I was wondering, is anyone here used to writing papers? Articles? I would like to try writing about my journey on this one. At the same time, I would like to make papers to help me achieve my masters degree in my university. But doing this alone, I think I wouldn't be able to publish anywhere significant. I don't know what to do honestly. I want to produce something cool with cryptography that I could publish, however, seems that all cool ideas are either taken, or way too hard for me to understand and make something out of it.

>>41175 Hello. I am professional cryptographer. I publish papers in top conferences. My suggestion. Write blog posts about all the cool stuff you learn about. Try to write your blog posts so that if you found them before you learned all the cool stuff, you would have benefitted from reading your blog! Also, later when you forget how everything works, you will have your blog post to start with next time. Fundamental protocol design is hard and I wouldn't suggest writing those kinds of papers on your own. Try engineering a system and documenting how it goes. Try auditing the system yourself and read the literature on known attacks on similar implementations. Eventually you'll run into a scenario where you're like "huh, this would be useful, but I can't find any one else who has implemented this" and there you go, a paper.

>>41182 >Try to write your blog posts so that if you found them before you learned all the cool stuff, you would have benefitted from reading your blog! Thanks for the tips anon. Is there any form of blogging that is more common for people that work in cryptography? I also thought about publishing in multiple languages. Basically bringing the knowledge to my local peers here in Brazil. What kinds of published papers do you have? Not trying to doxx you, just want to know a general idea on what is there to do. In my country, if I want to have actual published somewhat relevant papers, I need to "follow" a system called CAPES. It is leveled as: A1, A2, B1, B2, B3, B4, B5 and C. Ideally, I would publish in A1 and A2. But that is too hard. Hell, I might not even be on the C level. I mean, I need these levels to boost my grades for my master's degree. Unfortunately, I weren't that good of a student in terms of grades. Anyways, I need to find ideas. I'm sure by reading other's people papers I will have ideas. Anon, also, what do you think about the abstract algebra necessary for some fields? For example, in the Moon Math manual (maybe you're familiar with it) there are LOTS of uses of this kind of math. It honestly scares me.

>>41187 Not that I know of. I read https://soatok.blog/, but they do more cryptographic engineering and less of what I do. If you want traffic, it has to be in English, but having in two languages would be best (but would mean double the writing for you). I have papers in a few areas like MPC and key exchange protocols. If you want to see what research is going on now, check out the eprint (and the associated RSS) https://eprint.iacr.org/ I'm not familiar with the more applied side of cryptographic research, but check out CCS, USENIX, and S&P. They are _usually_ more applied. Most of the moon math manual is not necessary to do work in the field. Very few cryptographers I know actually have a deep understanding of elliptic curves, but rather have a strong understanding of their associated abstraction. "Who cares *what* group we use as long as it's conjectured to be a DDH group" is a common sentiment. If you're implementing the math yourself, you should know what's going on, but most work is done on top of other people's libraries like libsodium and friends.

>>41199 >https://soatok.blog/ This is incredibly detailed. I like the the animal drawings too to be honest, remembers me times I spent playing Zelda. Incredibly detailed stuff too. >I'm not familiar with the more applied side of cryptographic research, but check out CCS, USENIX, and S&P. They are _usually_ more applied. Correct if I'm wrong, but isn't all cryptography applied? I lived until now under this assumption, because a lot of things that are cryptography come from math purely. And then I suspected that all we do is just try to find ways to hide information, verify authority and maintain integrity. In what sense what you do is not applied?

>>41200 Cryptography is applied math, but a lot of cryptography work is still about "feasibility" or is fairly theoretical. I compare to work which is generally meant to be efficient and applied to real-world scenarios.

>>41211 Interesting. What are your thoughts on SNARKs, MPC and TEEs? Do these things compete with each other? TEEs seem particularly vulnerable if you ask me.

>>41244 Snarks are cool, MPC is generally boring but very useful, TEEs are fraudulent. MPC and ZKP have interplay with "MPC-in-the-head" techniques: https://dl.acm.org/doi/pdf/10.1145/3460120.3484771 SNARKs and MPC additionally have overlap in areas with verifiable outsourced computation where an IoT device can send their computation to another server and then simply verify the proof (technically not a SNARK since there's not really any knowledge involved). There's a recent paper about doing this privately so that the IoT's data is not "seen" by the party doing the computation, but I can't remember the name of the paper at the moment. If you're curious, something along the lines of "verifiable private computation" is what the paper's about. This is where TEEs want to sit, but they're fraudulent. Otherwise, SNARKs and MPC achieve different goals so they're not really in competition.

>>41245 Thanks anon, I will be reading that later. Do you have any recommendation of online courses related to this topic? Specially courses that emit certificates. I need the certificates to get a higher chance to be accepted into the master's program I mentioned before. But anything you think is good, really, should be enough.