GOST R 34.12-2015: Block Cipher "Magma"
draft-dolmatov-magma-06
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-08-26
|
06 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-08-17
|
06 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-05-02
|
06 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2020-03-23
|
06 | (System) | RFC Editor state changed to EDIT |
2020-03-23
|
06 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2020-03-23
|
06 | (System) | IANA Action state changed to In Progress |
2020-03-23
|
06 | Adrian Farrel | ISE state changed to Sent to the RFC Editor from In ISE Review |
2020-03-23
|
06 | Adrian Farrel | Sent request for publication to the RFC Editor |
2020-03-22
|
06 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2020-03-22
|
06 | Dmitry Baryshkov | New version available: draft-dolmatov-magma-06.txt |
2020-03-22
|
06 | (System) | New version approved |
2020-03-22
|
06 | (System) | Request for posting confirmation emailed to previous authors: Vasily Dolmatov , Dmitry Eremin-Solenikov |
2020-03-22
|
06 | Dmitry Baryshkov | Uploaded new revision |
2020-03-04
|
05 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Not OK |
2020-02-27
|
05 | (System) | IANA Review state changed to IANA - Not OK |
2020-02-27
|
05 | Amanda Baber | (Via drafts-eval@iana.org): IESG/Authors/ISE: The IANA Functions Operator has completed its review of draft-dolmatov-magma-05. If any part of this review is inaccurate, please let us … (Via drafts-eval@iana.org): IESG/Authors/ISE: The IANA Functions Operator has completed its review of draft-dolmatov-magma-05. If any part of this review is inaccurate, please let us know. IANA has two questions about this document: Should this document be listed as an additional reference for the IKEv2 Transform Type 1 - Encryption Algorithm Transform ID registrations made by draft-smyslov-esp-gost? Should be listed as an additional reference for the TLS Cipher Suites registrations made by draft-smyshlyaev-tls12-gost-suites or draft-smyshlyaev-tls13-gost-suites? See https://www.iana.org/assignments/ikev2-parameters and https://www.iana.org/assignments/tls-parameters. If not, we understand that this document doesn't require any IANA actions. Thank you, Amanda Baber Lead IANA Services Specialist |
2020-02-17
|
05 | Adrian Farrel | IETF conflict review initiated - see conflict-review-dolmatov-magma |
2020-02-17
|
05 | Adrian Farrel | draft-dolmatov-magma has been presented to the ISE for publication as an Independent Submissions Stream Informational RFC. An important note about this document is that the … draft-dolmatov-magma has been presented to the ISE for publication as an Independent Submissions Stream Informational RFC. An important note about this document is that the body of the document is supposed to be a technical translation of a Russian language document and is not a restatement of that Russian document as a technical specification. That means that any unclearness or errors that is found by reviewers can be fixed where it is the result of the translation, but not where it is present in the original material. The latter type of issue can be raised with the Russian Federal agencies to be fixed in a future release of the specification, and could be addressed in a further RFC that provides commentary on the specification, but cannot be resolved in the body of this document. (It could be noted in an Appendix to this work, but the authors are unwilling to mix direct translation with interpretive or speculative work.) Appendix B brings out the point that this is a translation. Along the way, this document was subject to several reviews and sent to the Crypto Review Panel for opinions - Russ Housley provided a review in response to that request. Most of the review comments (supplied below) focused on English usage and clarity of the translation, There are no requests for IANA action. This document formally updates RFC 5830 (a previous Independent Submissions Stream RFC). I enquired about this in my initial review and received the reply: > It updates RFC 5830 with fixed S-BOX and changes in key and data > schedule. It is expected that new software should use this updated > cipher instead of old version unless bound by compatibility issues. This is now explained to some extent in the Abstract. == ISE first review == Thanks, it is a relatively easy read, even for someone with no security clue like me. You have clearly put work into presenting it clearly. I do have a couple of high-level questions and a number of small editorial issues. Can you help me understand how this updates RFC 5830. I think it is not intended to be a complete replacement of 5830, but the Abstract is not clear on this point. I think that, maybe the Abstract could do with some work. I am making a suggestion here, but it is possible that I have the facts wrong and you'll need to fix that... The Russian Federal standard for electronic encryption, decryption, and message authentication algorithms (GOST 28147-89), which is one of the Russian cryptographic standard algorithms is described in RFC 5830. Since its publication, an update to the Russian Federal standard was published as GOST R 34.12-2015 that includes the specification of the block cipher known as "Kuznechik" which has been described in RFC7801. GOST R 34.12-2015 also includes an updated version of the block cipher with block length of n=64 bits and key length k=256 bits, which is also referred as "Magma". This document is intended to be a source of information about the updated version of Magma. It may facilitate the use of the block cipher in Internet applications by providing information for developers and users of GOST 28147-89 with the revised version of Magma for encryption, decryption, and message authentication. Section xxx of RFC 5830 described the previous version of Magma. This document updates RFC 5830 by describing the updated version of Magma that can be used as a block cipher in the procedures described in RFC 5830. Compared to RFC 5830, this document seems to be missing a description of how to use the block cipher. This may be addressed by your answer to my previous question, or it may be something that needs to be clarified. === Smaller points follow Section 1 This section is missing at least some text similar to the Abstract. A pointer to Appendix B would be highly useful. Paragraph 2 s/Standard/specification/ --- Section 2 Paragraph 1 s/Federal/Russian Federal/ --- Section 3 s/standard/specification/ --- Section 3.1 Can you look at the ordering of these terms. Either make them alphabetical or try to put thm in order so that the reader can learn the meanings in the order they read them. --- Section 3.2 s/standard/specification/ --- Section 4 Is this really all you wanted to say in this section? It's really odd! Apart from the Abstract, this is the only mention of Kuznechik in the document, and so it reads as a complete irrelevance. Either leave out the section completely (what would be lost?) or make some better reference. --- I think RFC 7836 is an Informative reference because you only use it in the non-normative Appendix. == Russ Housley - CFRG Crypto Review Panel == I do not see any obvious problems, but I did not try to write code ... I do not understand Section 4; I cannot figure out why it is in a document that describes the Magma block cipher. Section 3.2 says: A<<<_11 cyclic rotation of string A belonging to V_32 by 11 components in the direction of components having greater indices Since components are enumerated from right to left starting from zero, can't this be greatly simplified by saying "left cyclic rotation". Also, a comma is missing at the end of the definition. == Annon == In the Abstract, s/RFC7801/RFC 7801/ s/cipherwith/cipher with/ s/cipherfor/cipher for/ There isn't any introductory applicability statement. Perhaps it's obvious (but see below). Not a fan of what they did with Section 4. I get the incorporation by reference, but it doesn't seem clear to me (a non-cryptographer) exactly how Sections 5 and 6 amend the missing Section 4 (i.e. there are no actual references to particular sections of the missing text.) The Security Considerations section stinks. (It is however identical to the one in RFC 7801.) It could say something generic about block ciphers requiring mode selection appropriate to the application, and the need for good key generation. As I (again, a non-cryptographer) understand it, 64-bit block ciphers are considered passe - not quite unsafe at any speed, but certainly inappropriate for general use. The draft should address this (e.g. by saying this is only for highly constrained applications). == ISE final review == We've reached the stage in the process where I do my "final" review as ISE with the objective to mop up any last concerns before we pass your document to the IESG and RFC editor. The good news is that I only find silly and trivial issues. If you could have a look (and disagree with me if you like) and post a new revision, then I can ask the IESG for their review. Thanks, Adrian === Abstract s/referred as "Magma"/referred to as "Magma"/ s/version of older/version of an older/ s/updated version of 64-bit cipher/updated version of the 64-bit cipher/ --- Section 1 Can you please repeat the two sentances from the Abstract? This document is intended to be a source of information about the updated version of 64-bit cipher. It may facilitate the use of the block cipher in Internet applications by providing information for developers and users of GOST 64-bit cipher with the revised version of the cipher for encryption and decryption. --- 3.2 V* the set of all binary vector-strings of a finite length (hereinafter referred to as the strings) including the empty string, V_s the set of all binary strings of length s, where s is a non-negative integer; substrings and string components are enumerated from right to left starting from zero, I see some mismatch in conventions here... "binary vector-strings" hereinafter "the strings" But then, "binary stings" And "substrings" --- OLD 4.3. Key schedule NEW 4.3. Key Schedule END --- OLD 5. Basic encryption algorithm NEW 5. Basic Encryption Algorithm END --- 5.1 (and similar in 5.2) Depending on the values of round keys K_1,...,K_32, the encryption algorithm is a substitution E_(K_1,...,K_32) defined as follows: I looked at this several times. While (of course) it is true that the result depends on the K_1,...,K_32, the algorithm itself does not vary based on those values. So I think you need to say... The encryption algorithm is a substitution E_(K_1,...,K_32) defined as follows: --- Section 7 You have: Unlike [RFC5830] (GOST 28147-89) and like [RFC7801] this specification does not define exact block modes which should be used together with updated Magma cipher. One is free to select block modes depending on the protocol and necessity. I think this should be: Unlike [RFC5830] (GOST 28147-89), but like [RFC7801], this specification does not define exact block modes which should be used together with updated Magma cipher. One is free to select block modes depending on the protocol and necessity. It would also be nice to give some hints on where to look for how to decide which block mode to use depending on the protocol and necessity. I agree that you should not describe that process here, but are there references you can add? --- App A Thank you for the text at the top of the Appendix: helpful. A.1 and A.2 seem a bit abrupt and terse. could they include a line of text saying what they are doing (like A.3 does). --- |
2019-11-17
|
05 | (System) | Revised ID Needed tag cleared |
2019-11-17
|
05 | Dmitry Baryshkov | New version available: draft-dolmatov-magma-05.txt |
2019-11-17
|
05 | (System) | New version approved |
2019-11-17
|
05 | (System) | Request for posting confirmation emailed to previous authors: Vasily Dolmatov , Dmitry Eremin-Solenikov |
2019-11-17
|
05 | Dmitry Baryshkov | Uploaded new revision |
2019-11-13
|
04 | Adrian Farrel | Tag Revised I-D Needed set. |
2019-11-13
|
04 | Adrian Farrel | ISE state changed to In ISE Review from Finding Reviewers |
2019-10-31
|
04 | Dmitry Baryshkov | New version available: draft-dolmatov-magma-04.txt |
2019-10-31
|
04 | (System) | New version approved |
2019-10-31
|
04 | (System) | Request for posting confirmation emailed to previous authors: Vasily Dolmatov , Dmitry Eremin-Solenikov |
2019-10-31
|
04 | Dmitry Baryshkov | Uploaded new revision |
2019-09-26
|
03 | Adrian Farrel | ISE state changed to Finding Reviewers from In ISE Review |
2019-09-26
|
03 | Dmitry Baryshkov | New version available: draft-dolmatov-magma-03.txt |
2019-09-26
|
03 | (System) | New version approved |
2019-09-26
|
03 | (System) | Request for posting confirmation emailed to previous authors: Vasily Dolmatov , Dmitry Eremin-Solenikov |
2019-09-26
|
03 | Dmitry Baryshkov | Uploaded new revision |
2019-09-24
|
02 | (System) | Revised ID Needed tag cleared |
2019-09-24
|
02 | Dmitry Baryshkov | New version available: draft-dolmatov-magma-02.txt |
2019-09-24
|
02 | (System) | New version approved |
2019-09-24
|
02 | (System) | Request for posting confirmation emailed to previous authors: Vasily Dolmatov , Dmitry Eremin-Solenikov |
2019-09-24
|
02 | Dmitry Baryshkov | Uploaded new revision |
2019-09-24
|
02 | Dmitry Baryshkov | Uploaded new revision |
2019-08-27
|
01 | Adrian Farrel | Tag Revised I-D Needed set. |
2019-08-27
|
01 | Adrian Farrel | ISE state changed to In ISE Review from Submission Received |
2019-07-27
|
01 | Adrian Farrel | Notification list changed to Adrian Farrel <rfc-ise@rfc-editor.org> |
2019-07-27
|
01 | Adrian Farrel | Document shepherd changed to Adrian Farrel |
2019-07-27
|
01 | Adrian Farrel | ISE state changed to Submission Received |
2019-07-27
|
01 | Adrian Farrel | Intended Status changed to Informational from None |
2019-07-27
|
01 | Adrian Farrel | Stream changed to ISE from None |
2019-06-26
|
01 | Vasily Dolmatov | New version available: draft-dolmatov-magma-01.txt |
2019-06-26
|
01 | (System) | New version approved |
2019-06-26
|
01 | (System) | Request for posting confirmation emailed to previous authors: Vasily Dolmatov , Dmitry Eremin-Solenikov |
2019-06-26
|
01 | Vasily Dolmatov | Uploaded new revision |
2019-06-25
|
00 | Vasily Dolmatov | New version available: draft-dolmatov-magma-00.txt |
2019-06-25
|
00 | (System) | New version approved |
2019-06-25
|
00 | Vasily Dolmatov | Request for posting confirmation emailed to submitter and authors: Vasily Dolmatov , Dmitry Eremin-Solenikov |
2019-06-25
|
00 | Vasily Dolmatov | Uploaded new revision |