This challenge is simulating the infamous Logjam attack on many internet protocols like HTTPS, SSH, IPsec, SMTPS and protocols rely on TLS that uses Diffie-Hellman key exchange. The Logjam attack allows a man-in-the-middle attacker to downgrade vulnerable TLS connections to 512-bit export-grade cryptography, as there is an option for clients back when the paper is published to use DHE_EXPORT level of security. There is no indication of the cipher suites the server has chosen, so a MiTM can easily modify the client’s ciphersuite to be DHE_EXPORT.

The title of the challenge hints at a clue - the modulo used in the challenge is a smooth prime. There are no obvious weakness in the encryption scheme given in the source code. Again, revising the old lesson - Pohlig-Hellman algorithm is insane at solving DLP with primes of smooth order. Otherwise, the challenge is simply a matter of figuring out the proper Sage syntax to solve the challenge. discrete_log of Sage is powerful when it comes to solving DLP, as the underlying implementation of Sage involves both Pohlig-Hellman and BSGS.

Tricky challenge. The description is trying to throw me off from “My counter can go both upwards and downwards to throw off cryptanalysts”, which is not the case. The given code for encryption given is trying to simulate AES-CTR mode by doing AES-ECB block-by-block with the given IV. However, in the code of increment(), the method for changing the IV, there is a very sneaky bug: def increment(self): if self.stup: self.

The task is to find the generator of the finite field. There are multiple ways to do this: Naive implementation (brute-force). Credits to Landryl @ Cryptohack. ''' Rather than using a set and checking if every element of Fp has been generated, we can also rapidly disregard a number from being a generator by checking if the cycle it generates is smaller in size than p. If we detect a cycle before p elements, k can't be a generator of Fp.

The challenge is straightforward - just factor out the modulus used N. There are two approaches, one using FactorDB and one using the intended way of using Sage. Credits to pdro solution on Cryptohack: n = 580642391898843192929563856870897799650883152718761762932292482252152591279871421569162037190419036435041797739880389529593674485555792234900969402019055601781662044515999210032698275981631376651117318677368742867687180140048715627160641771118040372573575479330830092989800730105573700557717146251860588802509310534792310748898504394966263819959963273509119791037525504422606634640173277598774814099540555569257179715908642917355365791447508751401889724095964924513196281345665480688029639999472649549163147599540142367575413885729653166517595719991872223011969856259344396899748662101941230745601719730556631637 ''' Key observation: the number is 2033 bits and it has 30+ factors. The smallest factor will be ~2033/30 = 68 bits in the worst case (i.e. the size of all factors is even) This means we should look for algorithms whose time complexity depends on the size of their smaller factor.