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).
---