![]() ![]() Does the IND-CCA attack invalidate the security guarantees of MTProto? (the authors admit not, at least tentatively).Is MAC-then-encrypt used improperly in MTProto? (no).Does the known problem with IGE lead to a break in MTProto? (no they're not depending on the authentication).Would a break in SHA1 lead to a break in MTProto? (it would probably allow an attacker to forge a single chat message per collision but we're not quite there yet as of 2016).Bad primitives can still be secure as long as you side-step the parts of them that are broken. ![]() Anecdotally, bad primitives have probably lead to insecure protocols more often than good primitives have lead to secure protocols, but that's beside the point. However - I'll point out that, just like choosing good primitives doesn't necessarily guarantee a secure protocol, choosing bad primitives doesn't necessarily guarantee an insecure protocol. Those are the sorts of decisions that give cryptographers the willies - and rightfully so. A non-standard padding algorithm (which is to say, "append whatever bytes catch your fancy").Vulnerability to a chosen-ciphertext attack (which may not have been a choice as such).An old attempt at authenticated encryption (IGE), of which the authentication part has long-since been broken, but which MTProto doesn't actually use to provide authentication.A hash algorithm that's reaching the tail-end of its life (SHA1).You pointed out several in your question. MTProto makes what many cryptographers would consider odd choices. Actually, the diagram from the spec makes much more sense. Finally, the auth_key_id, "msg key" (MAC) and encrypted data are concatenated to produce the final message. The salt, session ID, payload, and 0-15 bytes of arbitrary padding are then encrypted with AES in IGE mode. This also gets mixed with the auth_key (SHA-1 based KDF) to produce a per-message encryption key (256 bit) and initialization vector (256 bit). Briefly, it takes the payload, prepends a salt and session ID, hashes that (SHA-1), and uses that as the "msg key" (MAC). The meat of the specification hinges on the message envelope. The session key ("auth_key") is derived from this original key (see the spec for particulars). There was a theoretical vulnerability where the original image wasn't large enough (and hence the key-exchange could be man-in-the-middled by someone with sufficient resources), but that's reportedly been fixed by increasing the size of the images / hex printout. Users can compare a hash of the generated key, exposed as either an image and hex code, for the two parties to exchange over an existing secure channel (preferably, in person). The protocol starts with a standard Diffie-Hellman key exchange. (Full specification for those interested: spec v1 ) ![]() Let's quickly review the basics of MTProto 1.0: I would also encourage any sufficiently-motivated, enterprising individual to write a new answer that takes into account updates to the protocols. I encourage people to read the new spec (the url is the same the content has been updated). they migrated from sha1 -> sha256), while others have not seen updates (ex. Some of the potential problems discussed below have been fixed (ex. MTProto 2.0 has since been released, in late 2017. There's a surprising amount of vitriol floating around the internet on those points, NONE of which is germane to the discussion at hand.ĮDIT: the following is specific to MTProto 1.0. who is talking to whom, which is pretty much the same between the two protocols)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |