Cryptohack

Same problem as the previous similar name challenge. But there is a twist this time. There is a check of (3*d)**4 > N, which effectively renders Weiner’s attack useless. We can use Boneh-Durfee Attack. Awesome script at this link. The Github repo contains some useful scripts. Boneh-Durfee Attack limit: $$ d < N ^ {0.292} $$ From the retrieved d, we can easily recover the plaintext. Seems like there is another solution by aloof, which I am too lazy to type so here’s the screenshot of the math involved....

The primes are generated using the primorial and the sieve. This is known to be ROCA, the vulnerability CVE-2017-15361. More details can be found at this link. This article is also a great start for understanding a bit of Coppersmith-Howgrave method for finding roots of polynomial. Again, an unintended solution is the fact that we can use FactorDB for a quick hack at the factorisation. Python Implementation: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 from Crypto....

From the code, we can observe that the way that the primes are generated is a bit weird - the primes are very close to each other. This is a very classic problem which happens in real life - some RSA modulus is cracked because of the distance of the primes being too small. The code opens up a vector for an attack - the Fermat’s factorization method when the prime difference is small....

The primes used for the modulus N is of the form 2 ^ x - 1. Such primes are called Mersenne’s primes, named after French mathematician Marin Mersenne. A quick hack for factorisation is to lookup FactorDB, as I assume the primes are studied extensively. The result from FactorDB shows two primes $2^{2203}-1$ and $2^{2281}-1$ Another solution involves a bit of math. Suppose the two primes used are $2 ^ a - 1$ and $2 ^ b - 1$, and $a \leq b$....

We need to recover the plaintext from the incorrectly generated RSA parameters, in this case, e = 16 and the modulo n is a prime. As the public exponent and the totient of n is not coprime, this implies The first, and intended solution is to take advantage of the fact that e = 2 ^ 4, hence we only need to calculate the square root of the plaintext in the finite field four times....

Straightforward, and perhaps classic challenge. This takes advantage of the fact that both images are encrypted using the same xor key. We can leak information of the flag by xor the two ciphertext, or the two files given. There are different snippets of code which can do this, which weirdly is not available online. The following is to do xor on RGB values of pixel by pixel. daneallen from Cryptohack:...

We are given a public RSA key that is used in the X509 certificate for the HTTPS connection to a Cryptohack domain. I solve it in the easy way, and uses a subdomain lookup site. A good one to use is crt.sh, and the query is https://crt.sh/?q=cryptohack.org, or https://subdomains.whoisxmlapi.com/. We can go over the list of subdomains to find the correct subdomain for the solution. We can instead solve this without using this comprehensive list of subdomains....

The name of the challenge is the name of the vulnerability CVE-2020-0601 on the crypto32.dll utility on the Microsoft Windows operating system. This vulnerability only targets ECC, and that an adversary can specify their own generator, private key and curve used, as Windows allows for this specifying arbitrary curve behavior. The same idea applies for this challenge. From the source code of the challenge, 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 def search_trusted(self, Q): for host, cert in self....

Title suggest the use of MOV attack, which is a mapping from ECC to Bilinear Maps to solve DLP. More information can be found on Crypto StackExchange. The code is based on this writeup on HackTheBox by WizardAlfredo, which the following solution uses the implementation from. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 from Crypto....

Big kudos to ConnorM on the Cryptohack Discord for the help. This challenge is super sneaky, as the implementation looks very sound, and it bears great resemblance to the example of the Python-ecdsa module. I learnt two lessons from this. First, please do code fuzzing carefully - I was very close to the actual solution but simply missed the crucial idea. Second, do not make assumptions about one’s code - vulnerabilities can start from something very silly....