Skip to main content

GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms
RFC 5830

Revision differences

Document history

Date Rev. By Action
2020-01-21
08 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2015-10-14
08 (System) Notify list changed from igus@cryptocom.ru, dol@cryptocom.ru, kdb@cryptocom.ru, irene@cryptocom.ru, draft-dolmatov-cryptocom-gost2814789@ietf.org, rfc-ise@rfc-editor.org to igus@cryptocom.ru, irene@cryptocom.ru, kdb@cryptocom.ru, rfc-ise@rfc-editor.org
2012-08-22
08 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2010-03-16
08 Cindy Morgan State Changes to RFC Published from RFC Ed Queue by Cindy Morgan
2010-03-16
08 Cindy Morgan [Note]: 'RFC 5830' added by Cindy Morgan
2010-03-15
08 (System) RFC published
2010-03-02
08 Cindy Morgan
2010-02-11
08 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2010-01-27
08 (System) IANA Action state changed to No IC from In Progress
2010-01-27
08 (System) IANA Action state changed to In Progress
2010-01-11
08 Amy Vezza IESG state changed to Approved-announcement sent
2010-01-11
08 Amy Vezza IESG has approved the document
2010-01-11
08 Amy Vezza Closed "Approve" ballot
2010-01-08
08 (System) Removed from agenda for telechat - 2010-01-07
2010-01-07
08 Cindy Morgan State Changes to Approved-announcement to be sent from IESG Evaluation by Cindy Morgan
2010-01-07
08 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk
2010-01-07
08 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk
2010-01-07
08 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2010-01-07
08 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2010-01-07
08 Pasi Eronen [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen
2010-01-07
08 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2010-01-06
08 Tim Polk
[Ballot discuss]
First, let me state that I strongly support publication of this document.  However...

One of my colleagues, a Russian mathematician, reviewed the original …
[Ballot discuss]
First, let me state that I strongly support publication of this document.  However...

One of my colleagues, a Russian mathematician, reviewed the original Russian-language
specifications and the Internet drafts side-by-side.  His summary is that the textual translations
were very well done, and quite accurate, but that the translation of the mathematical expressions
from a format that supported subscripts, etc. into the IETF's ascii-format had introduced a
number of ambiguities.  As a result, I do not think the document is sufficient to produce
interoperable implementations.
2010-01-06
08 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2010-01-06
08 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks
2010-01-05
08 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2010-01-05
08 Jari Arkko
[Ballot comment]
This may need editorial clarification:

4.7. The keys defining fillings of KDS and the substitution
    box K tables are secret elements …
[Ballot comment]
This may need editorial clarification:

4.7. The keys defining fillings of KDS and the substitution
    box K tables are secret elements and are provided in accordance
    with the established procedure.

    The filling of the substitution box K is described in GOST 28147-89
    as a long-term key element common for a whole computer network.
    Usually K is used as a parameter of algorithm, some possible sets
    of K are described in [RFC4357].

Here KDS is clear -- its the key. But what about K, the substitution
box? Is it a missing part of this standard, a negotiated value between
two peers, or a part of a standard for some context (e.g., when using
this algorithm in S/MIME K = something specific)?

Which established procedure are you referring to? Regular key management
procedures? Some other procedures to obtain secretly defined additional
standards for K?

Perhaps this is just ambiguous words in the document. If so, it would
be great to see the text be clearer about how it expects K to be
defined.
2010-01-05
08 Jari Arkko [Ballot discuss]
2010-01-05
08 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko
2010-01-05
08 Jari Arkko
[Ballot discuss]
I'm glad to see these specifications as RFC. My main reason for reviewing
these specifications was to ensure that the specifications are complete, …
[Ballot discuss]
I'm glad to see these specifications as RFC. My main reason for reviewing
these specifications was to ensure that the specifications are complete,
i.e., that interoperable implementations can be done based on the RFCs
alone. I don't think we should publish RFCs on any track if they
do not provide complete information. However, I have now became uncertain
if this particular draft has all the necessary pieces. The draft says:

4.7. The keys defining fillings of KDS and the substitution
    box K tables are secret elements and are provided in accordance
    with the established procedure.

    The filling of the substitution box K is described in GOST 28147-89
    as a long-term key element common for a whole computer network.
    Usually K is used as a parameter of algorithm, some possible sets
    of K are described in [RFC4357].

Here KDS is clear -- its the key. But what about K, the substitution
box? Is it a missing part of this standard, a negotiated value between
two peers, or a part of a standard for some context (e.g., when using
this algorithm in S/MIME K = something specific)?

Which established procedure are you referring to? Regular key management
procedures? Some other procedures to obtain secretly defined additional
standards for K?

Perhaps this is just ambiguous words in the document. If so, it would
be great to see the text be clearer about how it expects K to be
defined.

I would like to discuss this issue on the IESG telechat before
recommending the approval of these RFCs.
2010-01-05
08 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2010-01-04
08 Amanda Baber IANA comments:

As described in the IANA Considerations section, we understand this document
to have NO IANA Actions.
2010-01-01
08 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel
2009-12-28
08 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov
2009-12-22
08 (System) New version available: draft-dolmatov-cryptocom-gost2814789-08.txt
2009-12-22
07 (System) New version available: draft-dolmatov-cryptocom-gost2814789-07.txt
2009-12-20
08 Russ Housley State Changes to IESG Evaluation from AD Evaluation by Russ Housley
2009-12-20
08 Russ Housley [Ballot Position Update] New position, Yes, has been recorded for Russ Housley
2009-12-20
08 Russ Housley Ballot has been issued by Russ Housley
2009-12-20
08 Russ Housley Created "Approve" ballot
2009-12-20
08 (System) Ballot writeup text was added
2009-12-20
08 (System) Last call text was added
2009-12-20
08 (System) Ballot approval text was added
2009-12-20
08 Russ Housley Placed on agenda for telechat - 2010-01-07 by Russ Housley
2009-12-20
08 Russ Housley State Changes to AD Evaluation from Publication Requested by Russ Housley
2009-12-20
08 Russ Housley Note field has been cleared by Russ Housley
2009-12-09
08 Cindy Morgan
These documents were submitted to the RFC Editor to be published as
Informational Independent Submissions:

draft-dolmatov-cryptocom-gost34102001-07.txt
draft-dolmatov-cryptocom-gost341194-06.txt
draft-dolmatov-cryptocom-gost2814789-06.txt

Please let us know if these documents …
These documents were submitted to the RFC Editor to be published as
Informational Independent Submissions:

draft-dolmatov-cryptocom-gost34102001-07.txt
draft-dolmatov-cryptocom-gost341194-06.txt
draft-dolmatov-cryptocom-gost2814789-06.txt

Please let us know if these documents conflict with the IETF standards
process or other work being done in the IETF community.

Five week timeout expires on 12 January 2010.
(Note that we included an additional week for review because of the
upcoming holidays.)

I-D: draft-dolmatov-cryptocom-gost2814789-06
Title: GOST 28147-89 encryption, decryption and MAC algorithms
Abstrac:
This document is intended to be a source of information about the
Russian Federal standard for electronic encryption, decryption,
and MAC algorithms (GOST 28147-89) [GOST28147], which is one of the
official standards in the cryptography used in Russian algorithms
(GOST algorithms). Recently, Russian cryptography started to be
used in applications intended to work with the OpenSSL
cryptographic library. Therefore, this document has been created as
information for users of Russian cryptography.
2009-12-09
08 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2009-12-03
06 (System) New version available: draft-dolmatov-cryptocom-gost2814789-06.txt
2009-12-03
05 (System) New version available: draft-dolmatov-cryptocom-gost2814789-05.txt
2009-11-10
04 (System) New version available: draft-dolmatov-cryptocom-gost2814789-04.txt
2009-09-25
03 (System) New version available: draft-dolmatov-cryptocom-gost2814789-03.txt
2009-09-23
02 (System) New version available: draft-dolmatov-cryptocom-gost2814789-02.txt
2009-08-05
01 (System) New version available: draft-dolmatov-cryptocom-gost2814789-01.txt
2009-08-05
00 (System) New version available: draft-dolmatov-cryptocom-gost2814789-00.txt