Skip to main content

GOST R 34.12-2015: Block Cipher "Magma"
RFC 8891

Revision differences

Document history

Date Rev. By Action
2020-09-14
06 (System)
Received changes through RFC Editor sync (created alias RFC 8891, changed abstract to 'In addition to a new cipher with a block length of …
Received changes through RFC Editor sync (created alias RFC 8891, changed abstract to 'In addition to a new cipher with a block length of n=128 bits (referred to as "Kuznyechik" and described in RFC 7801), Russian Federal standard GOST R 34.12-2015 includes an updated version of the block cipher with a block length of n=64 bits and key length of k=256 bits, which is also referred to as "Magma".  The algorithm is an updated version of an older block cipher with a block length of n=64 bits described in GOST 28147-89 (RFC 5830).  This document is intended to be a source of information about the updated version of the 64-bit cipher.  It may facilitate the use of the block cipher in Internet applications by providing information for developers and users of the GOST 64-bit cipher with the revised version of the cipher for encryption and decryption.', changed standardization level to Informational, changed state to RFC, added RFC published event at 2020-09-14, changed ISE state to Published RFC, created updates relation between draft-dolmatov-magma and RFC 5830)
2020-09-14
06 (System) RFC published
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