Your homework is stored on a file server here, but the file server is using the User Login Network Authentication protocol (ULNA) to prevent unauthorized access. To download your homework, you'll need a token from a separate server called the ULNA server, available at https://cse207b.nh.cryptanalysis.fun/hw4/ulna/login. (You can interact with these servers via the client demo code in the ``framework.zip`` file linked below.) There is a user testuser with password testpass, but this user only has access to the file kitten.jpg, and not to your homework.
The User Login Network Authentication (ULNA) protocol lets a file server outsource authentication/authorization decisions to a separate server called the "ULNA server". When a user wants to access a file, the user first sends a request to the ULNA server with their username, password, and requested filename. If the username and password are correct, and if the user is authorized to access the requested file, the ULNA server responds with a "token" granting access to that file for a limited time. The user then presents this token to the file server to download the file. Thanks to ULNA, the file server never needs to handle usernames or passwords; it just needs to verify ULNA tokens.
In more detail, the ULNA server makes an "ULNA response packet" pkt containing the filename, a validity period, and optionally other information. (The exact format of ULNA request and response packets is described further below.) Then a 32-byte MAC is computed as follows, using a secret key S known only to the ULNA server and the file server:
mac = MD2000(pkt || S)
where MD2000 is the MD2000™ hash function, a Merkle-Damgård hash function with 256-byte block size and 32-byte output size.
The token is the concatenation
token = pkt || mac
When a user requests a file from the file server and sends the token obtained from the ULNA server, the file server verifies the MAC on the ULNA response packet in the token, then checks that the ULNA response packet is still valid and is for the requested file. If these checks all pass, it serves the file.
Fortunately for you, the MD2000™ hash function was recently broken by a cryptographer named Starc Mevens. In particular, chosen-prefix collisions are now easy to compute, although MD2000™ is still believed to be second-preimage resistant. (If you can break MD2000's second-preimage resistance, we'll give you extra credit! But be warned that it might or might not actually be possible; we haven't tried.) Your task is to forge an ULNA token that grants you access to the file hw4.pdf so that you can download the rest of your homework. This archive contains some useful files:
A similar (but more complicated) protocol called RADIUS is widely used in the real world. It uses essentially the same MAC construction but with MD5 instead of MD2000™. A recent paper shows how to break RADIUS using MD5 chosen-prefix collisions; some of the techniques in the paper may be useful for your attack.
Here are some excerpts from the ULNA RFC describing the packet formats:ULNA packets have the following format. The parenthesized number after each field denotes the length of the field in bytes, or * for variable-length fields. Packet = Code(1) Timestamp(4) Attribute-List(*) Code: The Code field is one octet. It is 0x01 for ULNA requests and 0x02 for ULNA responses. All other values are reserved. Timestamp: The Timestamp field is four octets, interpreted as a 32-bit little-endian unsigned integer. When sending an ULNA request, clients MUST use the current UNIX time as the Timestamp. ULNA servers SHOULD reject ULNA requests whose Timestamp is not within 30 seconds of the time the request is received. For responses, servers MUST use the Timestamp value of the corresponding request, not the time the request was received. Attribute-List: The Attribute-List is a sequence of zero or more Attributes. Each attribute has the following format: Attribute = Type(1) Length(2) Value(*) Type: The Type field is one octet. A list of values for this field is given in the next section. Length: The Length field is two octets, interpreted as a 16-bit little-endian unsigned integer. It MUST NOT exceed 1024. Value: The Value field has length determined by the Length field, which may be as small as 0 or as large as 1024. An Attribute-List MUST NOT contain more than one Attribute of a given Type. A server MAY reject requests that contain Attributes of unknown Type. Attributes: The following attribute types and their meanings are specified: 0x66 Filename 0x75 Username 0x70 Password 0x78 Expires 0x73 Session-State Filename: This attribute MUST be present in both requests and responses. In requests, the value is the name of the file that the user is requesting access to. In responses, the value is the name of the file that the user is granted access to. Username: This attribute MUST be present in requests and SHOULD NOT be present in responses. Used for authentication. Password: This attribute MUST be present in requests and MUST NOT be present in responses. Used for authentication. Expires: This attribute MUST NOT be present in requests and MUST be present in responses. The length of this attribute MUST be 4. Its value is interpreted as a little-endian 32-bit unsigned integer number of seconds since the UNIX epoch. A response is considered valid during the time window between Timestamp and Expires. A reasonable default for this field is the value of the Timestamp field plus 300, giving a 5 minute validity period. Session-State: This attribute MAY be present in requests and MAY be present in responses. If present in a request, an ULNA server MUST include it unmodified in the response. ULNA servers MUST NOT attempt to parse the value of the this attribute in any way; it should be treated as an opaque blob. Usage of the Session-State attribute is implementation dependent. A description of its function is outside the scope of this specification.
Please submit your code and a short description of how you solved the problem to Gradescope. You may discuss this assignment in small groups with classmates, but please code and write up your solutions yourself. Please credit any collaborators you discussed with and any references you used.
Note: This decryption challenge is relatively new! It may still have some bugs. Please let your TA know if...
Submission requirements summary:
You can assume that the autograder...