제안된 API에 대한 빠른 판단 피드백(도움이 되도록 노력):

• Span<T> 는 NetStandard2 에 없습니다.
• "Nonce"는 구현에 따라 매우 다릅니다. GCM의 냄새. 그러나 GCM 문서(예: NIST SP800-38D)에서도 이를 "IV"라고 부르며, 이는 GCM의 경우 임시로 발생합니다. 그러나 다른 AEAD 구현의 경우 IV는 nonce일 필요가 없습니다(예: CBC+HMAC에서 IV를 반복하는 것은 재앙이 아닙니다).
• 스트리밍 AEAD는 CryptoStream 과 원활하게 작동하거나 CryptoStream만큼 쉽게 스트리밍 인/아웃할 수 있는 자체 "AEADCryptoStream"을 제공해야 합니다.
• AEAD API 구현은 AAD(관련 데이터)를 기반으로 하는 내부 키 파생을 수행할 수 있어야 합니다. 순전히 태그 계산/검증을 위해 AAD를 사용하는 것은 너무 제한적이며 더 강력한 AEAD 모델을 방지합니다.
• "Get*" 메서드는 무언가를 반환해야 합니다(GetTag). void인 경우 무언가를 설정하거나 상태를 변경해야 합니다.
• "마무리"하기 전에 태그를 얻으려고 하는 것은 아마도 나쁜 생각일 수 있으므로 "IsFinished"가 도움이 될 수 있습니다.
• ICryptoTransform 을 설계한 사람들은 재사용, 다중 블록 지원 및 다양한 크기의 입력/출력 블록 크기에 대해 생각했습니다. 이러한 우려는 포착되지 않습니다.

AEAD API 온전함의 증거로 이러한 제안된 API의 첫 번째 구현은 AES-GCM이 아니라 HMAC 태그가 있는 클래식/기본 AES-CBC 여야 합니다 . 간단한 이유는 누구나 현재 잘 알려진 간단한 기존 .NET 클래스를 사용하여 AES-CBC+HMAC AEAD 구현을 구축할 수 있기 때문입니다. 새로운 AEAD API에 대해 작업하는 지루한 이전 [AES-CBC+HMAC]를 먼저 구해 보겠습니다. 모든 사람이 MVP 및 테스트 드라이브를 하기 쉽기 때문입니다.

nonce/IV 이름 지정 문제는 내가 결정하지 못한 문제였으며 IV로 변경되어 만족하므로 변경될 것입니다.

무언가를 반환하는 Get 메서드의 경우 할당을 방지합니다. 무언가를 반환하는 오버로드 Get()이 있을 수 있습니다. 이름 변경이 필요할 수도 있지만 전체 API가 기본적으로 할당이 없어야 한다는 생각에 꽤 동의했습니다.

스트림 등의 경우 하위 수준 기본 요소에서 쉽게 구성할 수 있는 상위 수준 API이므로 크게 신경 쓰지 않습니다.

완료하기 전에 태그를 가져오는 것은 허용되지 않아야 합니다. 그러나 완료를 호출한 시점을 알아야 하므로 API에 있어야 하는지 확신할 수 없지만 정의된 동작이어야 하므로 다음을 포함하도록 API 디자인을 업데이트했습니다. 행동 섹션을 통해 생각나는 다른 모든 것을 캡처할 수 있습니다.

어떤 암호에 관해서는 특정 암호가 유일한 목표가 되어야 한다고 생각하지 않습니다. 새로운 범용 API를 증명하려면 숫자에 맞아야 합니다. AES GCM 및 CBC는 모두 다루어야 합니다.

(주제 피드백에 대한 모든 것이 좋든 나쁘든 항상 도움이 됩니다! )

• 클래스 또는 인터페이스?
• 현재 SymmetricAlgorithm 클래스가 이 클래스와 어떻게 상호 작용합니까?
• TripleDESCng 및 AesCng가 할 수 있는 것과 같은 지속형 키에 이것을 어떻게 사용합니까?
• 이러한 Span 중 대부분은 ReadOnlySpan일 수 있는 것처럼 보입니다.

@Drawaes 이 API에서 공을 굴려 주셔서 감사합니다. 몇 가지 생각:

1. 태그를 잘못 사용하면 전체 목적을 무효화할 수 있으므로 태그 생성 및 확인은 이 API의 매우 중요한 부분입니다. 가능하다면 초기화 및 완료 작업에 태그가 내장되어 실수로 무시되는 일이 없도록 하고 싶습니다. 이는 암호화 및 암호 해독이 동일한 초기화 및 종료 방법을 사용하지 않아야 함을 의미합니다.
2. 태그가 확인될 때까지 데이터가 신뢰할 수 없기 때문에(모든 데이터가 처리될 때까지 수행할 수 없음) 암호 해독 중에 블록을 출력하는 것에 대해 만감이 교차합니다. 우리는 그 절충안을 매우 신중하게 평가해야 합니다.
3. 리셋이 필요한가요? 리셋만 하면 끝인가요? 증분 해시에서 수행합니다(그러나 새 IV가 필요하지 않음).

@bartonjs

1. 인터페이스가 있는 BCL에서 자주 볼 수 있는 클래스는 모든 것을 손상시키지 않고는 나중에 확장할 수 없습니다. 인터페이스는 평생 강아지와 같습니다... 기본 인터페이스 방법이 해당 문제에 대한 솔루션으로 간주될 수 없다면.
   또한 추상 유형의 봉인된 클래스는 실제로 더 빠릅니다(현재로서는) jitt가 이제 메소드를 가상화할 수 있기 때문입니다... 따라서 기본적으로 무료입니다. 인터페이스 디스패치가 좋지 않음(여전히 좋지 않음)
2. 어떻게 하면 좋을까? 현재 내용이 너무 혼란스러워서 관심이 거의 없습니다. 모든 합리적인 최신 알고리즘을 바로 패치할 것입니다(3DES는 다른 클래스에 남겨두세요. :) 하지만 모든 답을 갖고 있지 않으므로 이에 대해 더 생각하실 생각이 있으신가요?
3. 영구 키는 쉬워야 합니다. 키 메서드 또는 지속성 저장소에 확장 메서드를 만듭니다.

MyKeyStore.GetCipher();

초기화되지 않았습니다. 일회용이므로 일반 일회용 패턴으로 모든 심판을 삭제할 수 있습니다. 키를 설정하려고 하면 잘못된 작업 예외가 발생합니다.

예, 읽기 전용 범위에 대해서는 휴대전화를 사용하지 않을 때 조정할 것입니다.

@morganbr 문제없어요... 무엇보다 그런 일이 일어나길 바랄 뿐입니다 ;)

1. 어떻게 작동하는지에 대한 코드 스니펫을 제공할 수 있습니까? 확실하지 않지만 코드는 항상 명확성을 제공합니다.
2. 불행한 일이지만 블록을 일찍 뱉어내야 합니다. hmac 및 해싱을 사용하면 그렇지 않지만 상태만 임시 데이터가 없습니다. 따라서 이 경우 알 수 없는 양의 데이터를 버퍼링해야 합니다. 파이프라인 예제와 TLS를 살펴보겠습니다. 16k의 일반 텍스트를 작성할 수 있지만 파이프라인 버퍼는 오늘날 4k 페이지 크기입니다. 그래서 우리는 기껏해야 4*4k를 암호화/복호화하기를 원할 것입니다. 당신은 그 모든 것을 저장하기 위해 내부 메모리를 할당해야 하고 내가 결과를 얻었을 때 그것을 버릴 것 같습니까? 아니면 닦아줄까? 내가 10MB를 해독하고 잠재 메모리 사용에 대해 걱정해야 하는 후에 그 메모리를 보유하고 있다면 어떻게 될까요?
3. 초기화/재설정에 대해 100%는 아니지만(당신의 아이디어, 현재 API 모양이 아님) 그것은 나와 잘 어울리지 않으므로 새로운 제안에 열려 있습니다!

현재 내용에는 관심이 거의 없습니다. 너무 혼란스러워서 모든 합리적인 최신 알고리즘을 바로 패치할 것입니다(3DES는 다른 클래스에 남겨두세요)

문제는 EnvelopedCms(또는 EncryptedXml)와 같은 컨테이너 형식이 3DES-CBC, AES-CBC 등과 함께 작동해야 할 수도 있다는 것입니다. ECIES/AES-256-CBC-PKCS7/HMAC-SHA-2로 암호화된 것을 해독하려는 누군가 -256은 아마도 그들이 오래되고 추잡한 일을 하고 있다고 느끼지 않을 것입니다.

AE만을 위한 것이라면 이름 어딘가에 반영되어야 합니다. 지금은 일반적인 "암호화"입니다(저는 어느 시점에서 사전/용어집과 함께 앉아서 "작동 모드의 암호화 알고리즘"이라는 단어가 있는지 알아낼 것입니다. "암호" == "알고리즘", 따라서 "Aes").

:) 나는 그것이 내 주제 영역이 아니거나 나에게 많은 관심이 없다는 것을 지적한 것뿐이므로 이 주제에 대해 귀하와 커뮤니티에 기꺼이 미루고자 합니다.

이들을 빠르게 스캔한 후 한 가지 옵션은 "Cipher" 또는 클래스라고 하는 모든 인스턴스를 가져오도록 허용하는 것입니다. 이것은 첫 번째 물결에서 수행되지 않을 수 있지만 빠르게 후속 조치를 취할 수 있습니다. API가 매우 효율적이라면 내부적으로 자체 작업을 수행해야 할 이유가 없으며 정확히 이 API의 사용 사례입니다.

네이밍에 대한 사이드 바로서 ... 나는 그것이 힘든 것을 인정해야합니다.
Openssl = 암호
루비 = 암호
Go = AEAD 등을 위한 덕타입 인터페이스가 있는 암호 패키지
자바 = 암호

이제 나는 달라야 하지만... 트렌드가 있습니다. 더 나은 것이 가능하다면 멋지다.

아마도 "BlockModeCipher" ... ?

몇 가지를 변경했는데 더 나은 이름이 결정되면 이름을 변경하겠습니다.

질문에 답하려고 했을 때 API에 이미 암호화/복호화 구분이 누락되어 있다는 것을 깨달았습니다. 따라서 귀하의 예에서는 데이터를 암호화할지 복호화할지 알 수 없습니다. 그것을 넣으면 약간의 명확성이 추가될 수 있습니다.

API가 적절한 태그 사용을 적용할 수 있는 몇 가지 방법을 상상할 수 있습니다(이미 SymmetricAlgorithm/ICryptoTransform/CryptoStream이 있으므로 대칭 암호화가 아니라 AEAD API라고 가정). 태깅을 시행하는 예로서 이것을 규범적인 것으로 받아들이지 마십시오.
방법으로:

class Cipher
{
   void InitializeEncryption(ReadOnlySpan<byte> key, ReadOnlySpan<byte> iv);
   // Ensures decryptors get a tag
   void InitializeDecryption(ReadOnlySpan<byte> key, ReadOnlySpan<byte> iv, ReadOnlySpan<byte> tag);
   // Ensure encryptors produce a tag
    void FinishEncryption(ReadOnlySpan<byte> input, Span<byte> output, Span<byte> tag);
   // Throws if tag didn't verify
   void FinishDecryption(ReadOnlySpan<byte> input, Span<byte> output);
   // Update and properties are unchanged, but GetTag and SetTag are gone
}

수업별:

class Cipher
{
    // Has properties and update, but Initialize and Finish aren't present
}
class Encryptor : Cipher
{
    void Initialize(ReadOnlySpan<byte> key, ReadOnlySpan<byte> iv);
    void Finish(ReadOnlySpan<byte> input, Span<byte> output, Span<byte> tag);
}
class Decryptor : Cipher
{
   void Initialize(ReadOnlySpan<byte> key, ReadOnlySpan<byte> iv, ReadOnlySpan<byte> tag);
   // Throws if tag didn't verify
   void Finish(ReadOnlySpan<byte> input, Span<byte> output);
}
class AesGCMEncryptor : Encryptor {}
class AesGCMDecryptor : Decryptor {}
}

즉, 암호 해독 시 버퍼링되지 않는 경우 암호 해독이 실제로 완료되고 태그가 확인되는지 확인하는 것이 실용적입니까? 업데이트가 확인할 시간임을 어떻게든 알아낼 수 있습니까? 그것이 Dispose가 해야 할 일입니까? (Dispose는 객체를 폐기할 때 이미 데이터를 신뢰했을 수 있으므로 약간 위험합니다.)

명명에 관한 한 우리의 선례는 SymmetricAlgorithm 및 AsymmetricAlgorithm입니다. 이것이 AEAD를 위한 것이라면 일부 아이디어는 AuthenticatedSymmetricAlgorithm 또는 AuthenticatedEncryptionAlgorithm일 수 있습니다.

몇 가지 생각 및 API 아이디어:

public interface IAEADConfig
{
    // size of the input block (plaintext)
    int BlockSize { get; }

    // size of the output per input-block;
    // typically a multiple of BlockSize or equal to BlockSize.
    int FeedbackSize { get; }

    // IV size; CAESAR completition uses a fixed-length IV
    int IVSize { get; }

    // CAESAR competition uses a fixed-length key
    int KeySize { get; }

    // CAESAR competition states that typical AEAD ciphers have a constant gap between plaintext length
    // and ciphertext length, but the requirement is to have a constant *limit* on the gap.
    int MaxTagSize { get; }

    // allows for AE-only algorithms
    bool IsAdditionalDataSupported { get; }
}

public interface ICryptoAEADTransform : ICryptoTransform
{
    // new AEAD-specific ICryptoTransform interface will allow CryptoStream implementation
    // to distinguish AEAD transforms.
    // AEAD decryptor transforms should throw on auth failure, but current CryptoStream
    // logic swallows exceptions.
    // Alternatively, we can create a new AEAD_Auth_Failed exception class, and
    // CryptoTransform is modified to catch that specific exception.
}

public interface IAEADAlgorithm : IDisposable, IAEADConfig
{
    // separates object creation from initialization/keying; allows for unkeyed factories
    void Initialize(ArraySegment<byte> key);

    void Encrypt(
        ArraySegment<byte> iv, // readonly; covered by authentication
        ArraySegment<byte> plaintext, // readonly; covered by authentication
        ref ArraySegment<byte> ciphertext, // must be of at least [plaintext_length + MaxTagSize] length. iv is not part of ciphertext.
        ArraySegment<byte> additionalData = default(ArraySegment<byte>) // readonly; optional; covered by authentication
        ); // no failures expected under normal operation - abnormal failures will throw

    bool Decrypt(
        ArraySegment<byte> iv, // readonly
        ArraySegment<byte> ciphertext, // readonly
        ref ArraySegment<byte> plaintext, // must be of at least [ciphertext_length - MaxTagSize] length.
        ArraySegment<byte> additionalData = default(ArraySegment<byte>), // readonly; optional
        bool isAuthenticateOnly = false // supports Authentication-only mode
        );// auth failures expected under normal operation - return false on auth failure; throw on abnormal failure; true on success

    /*  Notes:
        * Array.LongLength should be used instead of Array.Length to accomodate byte arrays longer than 2^32.
        * Ciphertext/Plaintext produced by Encrypt()/Decrypt() must be determined *only* by method inputs (combined with a key).
          - (ie. if randomness or other hidden inputs are needed, they must be a part of iv)
        * Encrypt()/Decrypt() are allowed to write to ciphertext/plaintext segments under all conditions (failure/success/abnormal)
          - some implementations might be more stringent than others, and ex. not leak decrypted plaintext on auth failures
    */

    ICryptoAEADTransform CreateEncryptor(
        ArraySegment<byte> key,
        ArraySegment<byte> iv,
        ArraySegment<byte> additionalData = default(ArraySegment<byte>)
        );

    ICryptoAEADTransform CreateDecryptor(
        ArraySegment<byte> key,
        ArraySegment<byte> iv,
        ArraySegment<byte> additionalData = default(ArraySegment<byte>)
        );

    // Streaming AEAD can be done with good-old CryptoStream
    // (possibly modified to be AEAD-aware).
}

@sdrapkin , 생각을 제공해 주셔서 감사합니다. API에서 태그는 어디에 있어야 합니까? 암묵적으로 암호문의 일부입니까? 그렇다면 일부 알고리즘에는 실제로 없는 프로토콜이 있음을 의미합니다. 암시적 태그 배치가 허용되는지 또는 별도로 수행해야 하는지 여부를 확인하기 위해 사람들이 관심을 가질 수 있는 프로토콜을 이해하고 싶습니다.

@morganbr 암호화/암호 해독 문제도 발견했지만 오늘 밤에 수정할 시간이 없었습니다. 나는 더 적극적인 재활용을 허용하므로 클래스보다 방법을 선호합니다(키 및 IV에 대한 버퍼가 추가될 수 있음).

처분전의 확인도. 불행히도 작업의 끝을 말할 수 없습니다.

@sdrapkin 인터페이스는 앞에서 언급한 버전 문제로 인해 불가능하다고 말하고 싶습니다. 미래에 기본 이식에 의존하지 않는 한. 또한 인터페이스 디스패치는 더 느립니다. 배열 세그먼트도 범위가 더 다재다능한 하위 기본 요소이므로 우리의 것입니다. 그러나 나중에 수요가 있는 경우 arraysegment가 확장되도록 확장 메서드를 추가할 수 있습니다.

귀하의 속성 중 일부는 관심이 있으므로 휴대전화가 아닌 컴퓨터에 있을 때 업데이트됩니다.

좋은 피드백!

@morganbr 태그는 암호문의 일부입니다. 이것은 CAESAR API (AES-GCM 포함)를 모델로 합니다.

@Drawaes 저는 생각을 설명하기 위해 인터페이스를 사용했습니다. 저는 정적 메서드/클래스에 대해 완벽하게 괜찮습니다. 기간존재하지 않는다. 나는 무엇이 올지 모르나 신경쓰지 않는다 - 그것은 NetStandard2에 없고, 진지한 프로젝트에서 실제로 사용하는 일반 .NET에도 없다(예, 예, 나는 그것이 Core에 있다는 것을 알고 있지만 Core는 장난감입니다) 지금은). 나는 개인적으로 Span을 고려하게 되어 기쁩니다.내가 그것을 볼 때 - 그때까지 ArraySegment실제로 제공되는 가장 가까운 NetStandard API입니다.

유용한 CAESAR API를 자세히 살펴보겠습니다.

Span의 경우 이 API의 첫 번째 구현이 제공되는 것과 같은 시간(또는 최소한 가능한 가장 빠른 시간)과 같은 2.1 시간 프레임에 배송됩니다.

현재 시험판 nuget 패키지를 살펴보면 .net 표준 1.0까지 지원하며 릴리스 시 변경할 계획이 없습니다.

어쩌면 @stephentoub 는 우리가 말하는 것처럼 프레임워크 전체에 Span 기반 API를 추가하는 작업을 하고 있음을 확인할 수 있습니다.

(Span용 Nuget)[https://www.nuget.org/packages/System.Memory/4.4.0-preview2-25405-01]

그래서 저는 이것이 완전히 새로운 API를 위한 유일한 진정한 선택이라고 말하고 싶습니다. 그런 다음 선택한 경우 확장 메서드 등을 추가하여 ArraySegment를 사용할 수 있으며 충분히 유용하면 프레임워크에 추가할 수 있지만 ArraySegment를 Span으로 바꾸는 것은 간단하지만 다른 방법에는 데이터 복사가 필요합니다.

위의 API에서 볼 수 있는 문제는 "청크" 데이터의 성능에 재앙이 될 것이라는 것입니다. 예를 들어 네트워크 트래픽을 예로 들면 인증된 단일 블록이 기존 스트림의 여러 읽기에 걸쳐 분할되는 경우 이를 모두 단일 [데이터 구조 삽입]에 버퍼링하고 한 번에 모두 암호화/복호화해야 합니다. 해당 데이터에 대해 제로 복사를 수행하려는 모든 시도를 무효화합니다.

Pipelines가 제공하는 것과 같은 네트워킹 프레임워크는 거의 모든 사본을 피하도록 관리하지만 이 API에서 어떤 종류의 암호화에 도달하면 모든 것이 사라집니다.

별도의 구성 개체(또는 가방)는 실제로 내가 가지고 있는 다른 API에 대한 최근 토론에 포함되었습니다. 앞으로 커지면 메인 오브젝트에 많은 속성을 가지게 되면 엉망이 될 수 있다는 점에서 원칙적으로 반대하지 않습니다.

몇 가지 일이 나에게 일어났습니다.

• 현재 제안은 TagSize out 값(글쎄, get-only-property)을 호출합니다. 그러나 GCM과 CCM 모두 암호화에 대한 입력입니다(실제 태그를 제공했기 때문에 암호 해독에서 파생 가능).
• 제안은 입력과 출력이 동시에 단편적으로 발생할 수 있다고 가정합니다.
  
  
  
  • IIRC CCM은 스트리밍 암호화를 수행할 수 없습니다(일반 텍스트의 길이는 알고리즘의 첫 번째 단계에 대한 입력입니다).
  
  
  • 패딩 모드는 Final이 호출될 때까지 더 많은 데이터가 들어오는지/현재 블록에서 패딩을 제거해야 하는지 알지 못하기 때문에 (최소한 하나) 블록만큼 해독이 지연됩니다.
  
  
• 일부 알고리즘은 AD 요소가 작업 시작 시 필요하다고 간주하여 후기 바인딩된 연결보다 Init/ctor 매개변수와 더 유사하게 만듭니다.

컨테이너 형식(EnvelopedCms, EncryptedXml)이 키를 추출해야 하는지 아니면 키를 생성하고 기억하는 것이 단순히 키를 생성하고 기억하는 것이 중요한 것인지(기록해야 하는 한) 모르겠습니다.

(분명히 어제 "댓글" 버튼을 누르지 않았으므로 1910Z에서 "몇 가지 변경 사항을 적용했습니다" 이후에는 아무 것도 승인하지 않습니다.)

실제 태그 크기는 가변적이어야 합니다. 동의.

사용 사례를 단순화하기 위해 지금은 암호화만 살펴보겠습니다. 일부 암호는 더 적거나 더 많은 것을 반환하지 않는다는 것이 맞습니다. 충분히 큰 버퍼를 제공하지 않으면 어떻게 되는지에 대한 일반적인 질문이 있습니다.

span을 사용하는 새로운 TextEncoding 인터페이스에는 출력할 충분한 공간이 있는지 여부를 정의하기 위해 열거형을 반환하고 대신 실제로 "out" 매개변수에 크기를 쓰는 것에 대한 제안이 있었습니다. 이것은 가능성입니다.

CCM의 경우 아무 것도 반환하지 않고 전체 로트를 덤프하려는 시점에서 finish를 호출할 때까지 내부적으로 버퍼링해야 한다고 말하고 싶습니다. 단일 블록에 모든 데이터가 있는 경우(이 경우 더 나은 이름이 있을 수 있음) 첫 번째 호출로 finish를 호출하는 것을 막을 수 있는 것은 없습니다. 또는 해당 암호에 대한 업데이트를 시도하면 던질 수 있습니다. 예를 들어 CCM에서 계속 작업을 시도하면 CNG가 잘못된 크기 오류를 반환합니다.

태그가 복호화에 설정된 경우 전체 패킷을 읽을 때까지 종종 알지 못합니다. TLS를 예로 들면 태그 끝에 도달하기 위해 8 * 2k 네트워크 패킷을 읽어야 할 수 있습니다. 16k 블록의. 따라서 우리는 이제 해독을 시작하기 전에 전체 16k를 버퍼링해야 하며 중첩될 기회가 없습니다. 회로망).

@Drawaes re. 청크 스트림 및 버퍼링 제한:
당신은 당신의 전투를 선택해야합니다. AE 세계에서 하나의 좋은 목표와 일치하는 통합 API를 만들 수는 없으며 그러한 목표가 많이 있습니다. 전. Inferno 에는 적절한 청크 AEAD 스트리밍이 있지만 이는 표준이 아니며 그러한 표준도 존재하지 않습니다. 더 높은 수준에서 목표는 "보안 채널"입니다( this , this 및 this 참조).

그러나 지금은 더 작게 생각할 필요가 있습니다. 청킹/버퍼 제한은 표준화 노력의 대상이 되지 않습니다(" AEADs with large plaintexts " 섹션)..

암호화/복호화 작업은 기본적으로 변환에 관한 것입니다. 이러한 변환에는 버퍼가 필요하며 제자리에 있지 않습니다(출력 버퍼는 입력 버퍼보다 ​​커야 합니다 - 최소한 Encrypt 변환의 경우).

RFC 5116 도 관심을 가질 수 있습니다.

@Drawaes , TLS를 불러오는 것이 흥미롭습니다. SSLStream(이 API를 사용하는 경우)은 애플리케이션이 자체적으로 방어할 방법이 없기 때문에 인증되지 않은 결과를 애플리케이션에 반환해서는 안 된다고 주장합니다.

물론, 그러나 그것은 SSLStreams 문제입니다. 나는 파이프라인 위에 이 정확한 것(암호화 비트에 대해 CNG 및 OpenSSL을 호출하는 프로토콜 수준에서 관리되는 TLS)의 프로토타입을 만들었습니다. 논리는 매우 간단했습니다. 암호화된 데이터가 들어오고 버퍼를 제자리에서 해독하고 아웃바운드에 연결하고 태그에 도달할 때까지 반복합니다. 태그 호출이 끝나면...

던지면 파이프라인을 닫습니다. 던지지 않으면 다음 단계가 동일한 스레드에서 또는 디스패치를 ​​통해 작동하도록 플러시합니다.

내 개념 증명은 황금 시간대에 준비되지 않았지만 이것을 사용하고 많은 사본 등을 피함으로써 매우 괜찮은 성능 증가를 보였습니다.)

네트워킹의 문제는 파이프라인의 사물이 자체 버퍼를 할당하기 시작하고 이미 시스템을 통해 이동하는 버퍼를 가능한 한 많이 사용하지 않는 것입니다.

OpenSsl의 crypt와 CNG는 동일한 방법으로 Update, Update, Finish를 사용합니다. Finish는 논의된 대로 태그를 출력할 수 있습니다. 업데이트는 블록 크기(CNG의 경우)여야 하며 OpenSsl의 경우 블록 크기에 도달하기 위해 최소 버퍼링을 수행합니다.

그것들은 원시적이기 때문에 우리가 더 높은 수준의 기능을 기대할 수 있을지 확신할 수 없습니다. 우리가 그것들을 구성하기 위해 프리미티브가 아닌 "사용자" 레벨 API를 설계한다면 키 생성, IV 구성 및 전체 인증된 청크가 모두 구현되어야 한다고 주장할 것이므로 이 API의 대상 레벨이 실제로 무엇인지에 달려 있다고 생각합니다.

잘못된 버튼

@blowdart , 논스 관리에 대한 흥미로운 아이디어를 가지고 있습니다.

따라서 nonce 관리는 기본적으로 사용자 문제이며 설정에 따라 다릅니다.

그래서 ... 그것을 요구 사항으로 만드십시오. 넌스 관리를 연결해야 하고 ... 기본 구현이나 구현을 전혀 제공하지 마십시오. 이것은 단순한 것보다

cipher.Init(myKey, nonce);

사용자가 위험을 이해하는 특정 제스처를 취하도록 합니다.

@blowdart 의 아이디어는 논스 관리 문제와 알고리즘 간의 차이점 모두에 도움이 될 수 있습니다. 사용자가 nonce 관리가 해결해야 하는 문제라는 것을 이해하도록 하기 위해 기본 제공 구현이 없는 것이 중요할 수 있다는 점에 동의합니다. 어떻게 생겼습니까?

interface INonceProvider
{
    public void GetNextNonce(Span<byte> writeNonceHere);
}

class AesGcmCipher : Cipher
{
    public AesGcmCipher(ReadOnlySpan<byte> key, INonceProvider nonceProvider);
}

// Enables platform-specific hardware keys
class AesGcmCng : Cipher
{
    public AesGcmCng(CngKey key, INonceProvider nonceProvider);
}

// Example of AEAD that might not need a nonce
class AesCBCHmac : Cipher
{
    public AesCBC(ReadOnlySpan<byte> key)
}

class Cipher
{
    // As above, but doesn't take keys, IVs, or nonces
}

그러나 INonceProvider의 요점은 무엇입니까? Init가 아무 것도 사용하지 않고 블록을 시작하기 전에 호출해야 하는 경우 추가 인터페이스/유형이 없으면 추가 인터페이스/인터페이스가 없는 것과 동일한 것이 아닌가요?

또한 저는 암호 전문가는 아니지만 AES에는 IV가 필요하지 않습니다(nonce는 아니지만 사용자가 제공해야 합니까?)

추가 인터페이스/유형일 뿐입니다.

그게 요점입니다. 그것은 본질적으로 _nonce management_가 문제라고 말합니다. 단순히 0 또는 임의의 바이트 배열을 전달하는 것이 아닙니다. 사람들이 GetNextNonce 를 "지난번에 했던 것과 다른 것을 반환"하는 것으로 해석하면 부주의한 재사용을 방지하는 데 도움이 될 수도 있습니다.

nonce 관리 문제가 없는 알고리즘(예: AES SIV 또는 AES+CBC+HMAC)에는 필요하지 않은 것도 도움이 됩니다.

정확한 IV/nonce 요구 사항은 모드에 따라 다릅니다. 예를 들어:

• AES ECB는 nonce 또는 IV가 필요하지 않습니다.
• AES GCM에는 재사용해서는 안 되는 96비트 임시값이 필요하거나 키의 보안이 깨집니다. nonce가 재사용되지 않는 한 낮은 엔트로피는 괜찮습니다.
• AES CBC에는 무작위여야 하는 128비트 IV가 필요합니다. IV가 반복되면 이전에 동일한 메시지가 전송되었는지 여부만 나타냅니다.
• AES SIV는 다른 입력에서 파생되기 때문에 명시적 IV가 필요하지 않습니다.

AES CBC는 IV가 필요합니까? 그래서 InitializationVectorProvider가 있습니까? 뜬금없지만
iv를 예측할 수 있기 때문에 nonce를 좋아하고 마지막 블록을 재사용하면 tls 공격이 발생합니다. CBC에 대해 say 순차 nonce를 명시적으로 사용할 수 없습니다.

예, 하지만 IV는 nonce가 아니므로 nomce provider라는 용어를 사용할 수 없습니다.

AES CBC에 IV가 필요하지 않다는 의미는 아닙니다. 필요합니다. 나는 단지 다른 데이터에서 IV를 도출하는 몇 가지 계획에 대해 추측하고 싶었습니다.

물론 내 요점은 내가 일반적으로 그것을 좋아한다는 것입니다 ... 제공자를 풀링 할 수 있습니다 ;) 그러나 iv 제공자라고 부르거나 의도를 명확하게 할 2 개의 인터페이스

@morganbr INonceProvider 암호 생성자에 전달된 팩토리는 잘못된 디자인입니다. _nonce_가 그 자체로 존재하지 않는다는 사실을 완전히 놓치고 있습니다. "_... 한번 사용된_" 제약 조건에는 _context_가 있습니다. CTR 및 GCM(CTR 사용) 모드의 경우 _nonce_의 _context_는 _key_입니다. 즉. _nonce provider_는 특정 _key_ 컨텍스트 내에서 한 번만 사용되는 nonce를 반환해야 합니다.

제안한 API의 INonceProvider 는 키를 인식하지 않기 때문에 올바른 nonce를 생성할 수 없습니다(비트 공간이 통계적 임의성이 작동하기에 충분히 크더라도 nonce가 아닌 임의성을 통한 것 제외). 안전하게).

나는 이 토론 스레드가 달성하고자 하는 것이 무엇인지 완전히 확신하지 못합니다. 다양한 Authenticated-Encryption 디자인 아이디어가 논의됩니다... ok. 이미 .NET Core, 특히 ASP.NET API에 구축된 인증된 암호화 인터페이스는 어떻습니까? IAuthenticatedEncryptor 등이 있습니다. 이러한 모든 기능은 이미 구현되고 확장 가능하며 현재 .NET Core의 일부로 제공됩니다. DataProtection 암호화가 완벽하다고 말하는 것은 아니지만 무시할 계획입니까? 변경하시겠습니까? 동화 또는 리팩토링?

DataProtection 암호화는 @GrabYourPitchforks (Levi Broderick)가 구축했습니다. 그는 주제를 알고 있으며 그의 의견/입력/피드백이 이 커뮤니티에 가장 가치가 있을 것입니다. 저는 누구보다 암호화폐 관련 엔터테인먼트를 좋아하지만, 암호화폐 API 설계에 대해 진지하게 고민하고 싶은 사람이 있다면 이미 MS 팀에 있는 실제 전문가들이 참여해야 합니다.

@sdrapkin , 키 인식이 필요한 nonce 제공자는 좋은 지적입니다. 이를 시행하기 위해 이러한 API를 수정하는 합리적인 방법이 있는지 궁금합니다.

DataProtection은 훌륭한 API이지만 더 높은 수준의 구성입니다. 키 생성 및 관리, IV 및 출력 프로토콜을 캡슐화합니다. 누군가 다른 프로토콜의 구현에서 GCM을 사용해야 하는 경우 DataProtection은 이를 가능하게 하지 않습니다.

.NET 암호화 팀에는 @bartonjs , @blowdart 및 제가 포함됩니다. 물론 @GrabYourPitchforks 가 차임벨을 울리고 싶다면 환영합니다.

나는 이것이 낮은 수준의 원시적이어야 한다는 점에서 @morganbr 에 동의합니다(사실 제목에서 그렇게 말합니다). 데이터 보호 등은 사용자 코드에서 직접 사용하도록 설계되어 발에 총을 쏘는 능력을 감소시키지만, 내가 이 기본 요소를 보는 방식은 프레임워크와 라이브러리가 공통 기반에서 더 높은 수준의 구성을 구축할 수 있도록 하는 것입니다.

이러한 생각을 염두에 두고 키가 제공될 때마다 제공해야 하는 경우 공급자는 괜찮습니다. TLS를 사용하여 설명하겠습니다(네트워크 트래픽에 AES 차단 모드를 사용하는 것으로 잘 알려져 있음).

나는 "프레임"을 얻습니다 (인터넷의 MTU ~ 1500을 사용하는 2 + TU 이상). 여기에는 nonce(또는 4바이트가 "숨김"으로 남아 있는 nonce의 일부)가 포함되어 있습니다. 그런 다음 이 값을 셸 "제공자"에서 설정한 다음 암호 해독을 호출하고 버퍼 암호 해독 주기를 거쳐 단일 일반 텍스트를 얻습니다. .

당신이 그것에 만족한다면, 나는 그것으로 살 수 있습니다. 위의 디자인을 우리가 동의할 수 있는 것으로 업데이트하는 데 열심인 이 작업을 진행하고 싶습니다.

토론을 진행해 주셔서 감사합니다. 이에 대해 논의할 수 있는 자유 시간을 가지십시오. @Drawaes , 이 진화하는 대화의 황금 표준/타겟으로 최상위 게시물을 확인/업데이트할 수 있습니까? 그렇지 않은 경우 업데이트할 수 있습니까?

현재 제안에 치명적인 문제가 있고 너무 수다스러운 다른 문제가 있습니다.

// current proposed usage
using (var cipher = new AesGcmCipher(bitsize: 256))
{
    cipher.Init(myKey, nonce);
    while (!inputSource.EOF)
    {
        var inputSpan = inputSource.ReadSpan(cipher.BlockSize);
        cipher.Update(inputSpan);
        outputSource.Write(inputSpan);
    }
    cipher.AddAssociatedData(extraInformation); // <= fatal, one can't just do this
    cipher.Finish(finalBlockData);
    cipher.GetTag(tagData);
}

진정한 AEAD 프리미티브를 보면 프라이버시 데이터와 인증된 데이터가 혼합된 잠금 단계입니다. 인증 데이터 1 및 CipherText1에 대해서는 이것을 참조하십시오. 이것은 물론 1뿐만 아니라 여러 블록에 대해 계속됩니다.

전 세계의 밈이기 때문에 저항 할 수 없습니다, 죄송합니다 :)

또한 API는 new, init, update 등으로 수다스러워 보입니다. 이 프로그래머의 모델을 제안하겠습니다.

// proposed, see detailed comments below
using (var cipher = new AesGcmCipher(myKey, iv, aad)) // 1
{
    // 2
    while (!inputSource.EOF) 
    {
        var inputSpan = inputSource.ReadSpan(16411); // 3
        var outSpan = cipher.Encrypt(inputSpan); // 4
        outputSource.Write(outSpan); 
    }    
    var tag = cipher.Finish(finalBlockData); // 5
}

1. 일반적으로 AAD << 일반 텍스트이므로 전체 AAD가 버퍼로 전달된 다음 암호가 잠재적으로 기가바이트+ 스트림의 나머지 부분을 처리하는 cipher.Init(mykey, nonce, aad); 를 보았습니다. (예: BCryptEncrypts의 CipherModeInfo 매개변수 ). 또한 myKey의 크기는 이미 AES128, 192, 256을 설정하므로 다른 매개변수가 필요하지 않습니다.
2. 호출자가 기존 클래스, 기존 AES 상수를 재사용하고 AES 키가 동일한 경우 AES 하위 키 생성을 건너뛰기를 원하는 경우 Init는 선택적 API가 됩니다.
3. cipher의 API는 대부분의 다른 암호화 API 또는 기존 .NET API와 같은 블록 크기 관리 내부에서 호출자를 보호해야 합니다. 사용 사례에 최적화된 버퍼 크기와 관련된 호출자(예: 16K+ 버퍼를 통한 네트워크 IO). 구현 가정을 테스트하기 위해 16K보다 큰 소수로 데모
4. inputSpan은 읽기 전용입니다. 그리고 입력합니다. 그래서 outSpan이 필요합니다
5. Update()는 암호화 또는 암호 해독을 수행합니까? 개발자의 멘탈 모델과 일치하도록 암호화 및 암호 해독 인터페이스만 있으면 됩니다. tag 도 이 순간에 가장 중요한 원하는 데이터이니 돌려주세요.

사실 한발 더 나아가 왜 그냥

using (var cipher = new AesGcmCipher(myKey, iv, aad))
{
    var tag = cipher.EncryptFinal(inputSpan, outputSpan);
}

또한 INonceProvider 및 기타 종류를 피하십시오. 크립토 프리미티브는 이것을 필요로 하지 않습니다 byte[] iv(작은 데이터에 대해 제가 가장 좋아하는 것) 또는 Span (새로운 멋지지만 너무 많은 추상화 IMHO)를 고수하십시오. Nonce 공급자는 위의 계층에서 작동하며 그 결과는 여기에서 볼 수 있는 iv 수 있습니다.

프리미티브를 너무 원시적으로 만드는 것의 문제는 사람들이 단순히 그것들을 잘못 사용한다는 것입니다. 공급자와 함께 우리는 최소한 그들의 사용에 대해 약간의 생각을 강요할 수 있습니다.

우리는 일반적으로 GCM이 특정한 AEAD에 대해 이야기하고 있습니다. 따라서 먼저 일반화된 사례( iv )가 특정 사례( nonce )가 아니라 디자인을 주도해야 합니다.

둘째, 단순히 byte[] iv 에서 GetNextNonce(Span<byte> writeNonceHere) 로 이동하는 것이 실제로 nonce 문제를 해결하는 방법은 무엇입니까? 문제의 이름/레이블만 변경하면서 동시에 문제를 원래보다 더 복잡하게 만들었습니다.

셋째, iv 보호에 대한 정책을 시작하고 있으므로 주요 보호 정책에도 참여해야 합니까? 키 배포 정책은 어떻습니까? 그것들은 분명히 더 높은 수준의 우려입니다.

마지막으로 nonce는 상위 계층에서 사용하는 경우 매우 상황에 따라 다릅니다. 계층 간 문제가 함께 결합되는 취약한 아키텍처를 원하지 않습니다.

솔직히 말해서 누군가가 내가 무엇을 하는지 안다고 제스처를 취하지 않는 한 기본 요소를 숨길 수 있다면 그렇게 할 것입니다. 하지만 우리는 할 수 없습니다. 사람들이 "오, 이것이 사용 가능합니다. 사용하겠습니다"라고 말하지만 잘못된 암호 구현이 너무 많습니다. 젠장 AES 자체를 보세요. HMAC 없이 그냥 사용하겠습니다.

API가 기본적으로 안전하기를 원합니다. 그게 조금 더 고통스럽다면 솔직히 저는 찬성합니다. 99%의 개발자는 암호화와 관련하여 자신이 무엇을 하고 있는지 모르고 있으며 1%의 개발자가 이를 쉽게 수행할 수 있도록 하는 것이 우선 순위가 낮아야 합니다.

스팬이 존재하지 않습니다. 나는 무엇이 올지 모르나 신경쓰지 않는다 - 그것은 NetStandard2에 없다

@Drawaes 가 지적한 @sdrapkin Span<T> 는 .NET Standard 1.0 이므로 모든 프레임워크에서 사용할 수 있습니다. 또한 참조된 실제 창에만 액세스할 수 있으므로 ArraySegment<T> 보다 안전합니다. 전체 배열보다.

또한 ReadOnlySpan<T> 는 해당 창에 대한 수정을 방지합니다. 전달된 배열에 대한 참조를 수정 및/또는 유지할 수 있는 배열 세그먼트와 달리 전달됩니다.

Span은 sync apis의 일반적인 이동 경로여야 합니다(Span을 사용하는 api는 stackalloc'd, 기본 메모리 및 배열에 추가로 대처할 수 있다는 사실은 장식입니다)

즉
ArraySegment를 사용하면 문서를 통해 읽기 전용이 제안됩니다. 범위를 벗어난 읽기/수정이 방지되지 않습니다.

void Encrypt(
    ArraySegment<byte> iv, // readonly; covered by authentication
    ArraySegment<byte> plaintext, // readonly; covered by authentication
    ref ArraySegment<byte> ciphertext, // must be of at least [plaintext_length + MaxTagSize] length. iv is not part of ciphertext.
    ArraySegment<byte> additionalData = default(ArraySegment<byte>) // readonly; optional; covered by authentication
    );

그러나 Span에서는 읽기 전용이 api에 의해 시행됩니다. 뿐만 아니라 방지되는 배열의 범위를 벗어난 읽기

void Encrypt(
    ReadOnlySpan<byte> iv, // covered by authentication
    ReadOnlySpan<byte> plaintext, // covered by authentication
    Span<byte> ciphertext, // must be of at least [plaintext_length + MaxTagSize] length. iv is not part of ciphertext.
    ReadOnlySpan<byte> additionalData = ReadOnlySpan<byte>.Empty) // optional; covered by authentication
    );

매개변수로 의도를 훨씬 더 잘 전달합니다. 범위를 벗어난 읽기/쓰기와 관련하여 오류가 발생하기 쉽습니다.

@benaadams @Drawaes 는 Span<T> 가 NetStandard에 있다고 말한 적이 없습니다( 출시된 NetStandard ). 그가 말한 것은 (1) Span<T> 가 배송된 NetStandard에 없다는 데 동의합니다. (2) Span<T> 는 _"2.1 기간 내에 배송"_됩니다.

그러나 이 특정 Github 문제의 경우 (읽기 전용) Span<T> 논의는 현재 중단 되고 있습니다. 설계할 API의 범위나 목적에 대한 명확성은 없습니다.

원시 저수준 원시 AEAD API(예: CAESAR와 유사)를 사용합니다.

• 장점: AES-GCM/CCM에 적합, 좋은 소스(NIST, RFC)의 기존 테스트 벡터. @sidshety 는 행복할 것입니다. @blowdart 는 _"프리미티브를 매우 원시적으로 만들기"_에 대해 명상하지만, 프리미티브는 원시적이며 어린이를 보호할 방법이 없기 때문에 결국에는 음과 양을 보게 될 것입니다.
• 단점: 전문가 사용자(속담의 1%)는 저수준 API를 책임감 있게 사용하는 반면, 다른 비전문가 사용자(99%)는 이 API를 오용하여 대다수의 .NET을 담당하는 손상된 .NET 소프트웨어를 작성합니다. CVE는 .NET이 안전하지 않은 플랫폼이라는 인식에 크게 기여할 것입니다.

또는 높은 수준의 오용 불가능 또는 내성 AEAD API를 사용합니다.

• 장점: 비전문가 사용자의 99%는 계속해서 실수를 하겠지만 적어도 AEAD 코드에서는 그렇지 않습니다. @blowdart 의 _"기본적으로 API가 안전한지 확인하고 싶습니다."_ 생태계에 깊이 반향을 일으키며 보안, 번영 및 좋은 업보가 모두 닥칩니다. 많은 좋은 API 디자인 및 구현이 이미 사용 가능합니다.
• 단점: 표준이 없습니다. 테스트 벡터가 없습니다. AEAD가 높은 수준의 온라인 스트리밍 API를 대상으로 하는 올바른 목표인지에 대한 합의가 없습니다(스포일러: 그렇지 않습니다. Rogaway의 논문 참조).

아니면 둘 다 합니다. 또는 분석 마비 상태가 되어 지금 이 문제를 종료할 수도 있습니다.

핵심 언어의 일부인 암호화에는 견고하고 낮은 수준의 기본 API가 있어야 한다고 강력하게 생각합니다. 일단 가지고 있으면 핵심 또는 커뮤니티에서 상위 수준 API 또는 "학습 바퀴" API를 만드는 것을 빠르게 연결할 수 있습니다. 그러나 나는 누구에게나 우아하게 그 반대로 도전한다. 또한 주제는 " 암호화에 대한 일반 저수준 기본 "입니다!

@Drawaes 이것을 수렴하고 해결할 타임 라인이 있습니까? 그러한 GitHub 경고 외에 Microsoft 이외의 사람들을 포함시킬 계획이 있습니까? 30분 회의 통화를 좋아하시나요? 나는 토끼 구멍에서 벗어나려고 노력하고 있지만 .NET 핵심 암호화가 특정 수준의 성숙도와 안정성에 있을 것이라고 장담하고 있습니다. 그래서 그러한 논의를 분류할 수 있습니다.

우리는 여전히 이 문제에 주의를 기울이고 노력하고 있습니다. 우리는 Microsoft Cryptography Board(Microsoft의 암호화 사용에 조언하는 연구원 및 기타 전문가 집합)를 만났으며 @bartonjs 에서 곧 공유할 더 많은 정보를 갖게 될 것입니다.

약간의 데이터 흐름 낙서와 Crypto Board의 조언을 기반으로 다음을 생각해 냈습니다. 우리 모델은 GCM, CCM, SIV 및 CBC+HMAC였습니다(지금 SIV 또는 CBC+HMAC를 수행하는 것에 대해 이야기하는 것이 아니라 모양을 증명하고 싶었을 뿐입니다).

```C#
공개 인터페이스 INonceProvider
{
읽기 전용 범위GetNextNonce(int nonceSize);
}

공개 추상 클래스 AuthenticatedEncryptor : IDisposable
{
공개 int NonceOrIVSizeInBits { 가져오기; }
공개 int TagSizeInBits { 가져오기; }
공개 부울 SupportsAssociatedData { 가져오기; }
공개 읽기 전용 범위LastNonceOrIV { 가져오기; }
공개 읽기 전용 범위LastTag { 가져오기; }

protected AuthenticatedEncryptor(
    int tagSizeInBits,
    bool supportsAssociatedData,
    int nonceOrIVSizeInBits) => throw null;

protected abstract bool TryEncrypt(
    ReadOnlySpan<byte> data,
    ReadOnlySpan<byte> associatedData,
    Span<byte> encryptedData,
    out int bytesWritten,
    Span<byte> tag,
    Span<byte> nonceOrIVUsed);

public abstract void GetEncryptedSizeRange(
    int dataLength,
    out int minEncryptedLength,
    out int maxEncryptedLength);

public bool TryEncrypt(
    ReadOnlySpan<byte> data,
    ReadOnlySpan<byte> associatedData,
    Span<byte> encryptedData,
    out int bytesWritten) => throw null;

public byte[] Encrypt(
    ReadOnlySpan<byte> data,
    ReadOnlySpan<byte> associatedData) => throw null;

// some variant of the Dispose pattern here.

}

공개 봉인 클래스 AesGcmEncryptor : AuthenticatedEncryptor
{
공개 AesGcmEncryptor(ReadOnlySpan키 크기, INonceProvider nonnceProvider)
: 기본(128, 참, 96)
{
}
}

공개 봉인 클래스 AesCcmEncryptor : AuthenticatedEncryptor
{
공개 AesCcmEncryptor(
읽기 전용 범위열쇠,
정수 nonceSizeInBits,
INonceProvider nonceProvider,
int tagSizeInBits)
: 기본(tagSizeInBits, true, nonceSizeInBits)
{
알고리즘 사양에 대해 nonceSize 및 tagSize를 확인합니다.
}
}

공개 추상 클래스 AuthenticatedDecryptor : IDisposable
{
공개 추상 bool TryDecrypt(
읽기 전용 범위꼬리표,
읽기 전용 범위nonceOrIV,
읽기 전용 범위암호화된 데이터,
읽기 전용 범위연관된 데이터,
기간데이터,
out int bytesWritten);

public abstract void GetEncryptedSizeRange(
    int encryptedDataLength,
    out int minDecryptedLength,
    out int maxDecryptedLength);

public byte[] Decrypt(
    ReadOnlySpan<byte> tag,
    ReadOnlySpan<byte> nonceOrIV,
    ReadOnlySpan<byte> encryptedData,
    ReadOnlySpan<byte> associatedData) => throw null;

// some variant of the Dispose pattern here.

}

공개 봉인 클래스 AesGcmDecryptor : AuthenticatedDecryptor
{
공개 AesGcmDecryptor(ReadOnlySpan키) => null 던지기;
}

공개 봉인 클래스 AesCcmDecryptor : AuthenticatedDecryptor
{
공개 AesCcmDecryptor(ReadOnlySpan키) => null 던지기;
}
```

이 제안은 데이터 스트리밍을 제거합니다. 우리는 그 점에서 유연성이 별로 없습니다. 관련 위험(GCM의 경우 매우 높음) 또는 불가능(CCM)과 결합된 실제 요구 사항(낮음)은 이제 막 사라졌음을 의미합니다.

이 제안은 암호화를 위해 외부화된 nonce 소스를 사용합니다. 이 인터페이스의 공개 구현은 없습니다. 각 애플리케이션/프로토콜은 컨텍스트에 키를 연결하여 적절하게 정보를 제공할 수 있도록 자체적으로 만들어야 합니다. TryEncrypt에 대한 각 호출은 GetNextNonce에 대한 한 번만 호출하지만 특정 TryEncrypt가 성공한다는 보장은 없으므로 애플리케이션이 nonce를 다시 시도해야 한다는 의미인지 이해하는 것은 여전히 ​​애플리케이션에 달려 있습니다. CBC+HMAC의 경우 용어를 혼동하지 않도록 IIVProvider라는 새 인터페이스를 만듭니다. SIV의 경우 IV가 구성되므로 허용되는 매개변수가 없습니다. 그리고 사양에 따라 nonce(사용된 경우)는 relatedData의 일부로 간주되는 것 같습니다. 따라서 SIV는 최소한 nonceOrIV를 TryEncrypt에 대한 매개변수로 사용하는 것은 일반적으로 적용할 수 없다고 제안합니다.

TryDecrypt는 가장 확실하게 잘못된 태그를 발생시킵니다. 대상이 너무 작은 경우에만 false를 반환합니다(Try-method의 규칙에 따라).

피드백을 위해 확실히 열려 있는 것들:

• 크기는 비트(사양의 중요한 부분과 같이) 또는 바이트(어쨌든 %8 값만 합법적이므로 항상 나눌 수 있고 사양의 일부는 바이트 단위의 nonce 크기와 같은 것에 대해 이야기하기 때문에)여야 합니다. )?
• 매개변수 이름 및 순서.
• LastTag/LastNonceOrIV 속성입니다. (공개 TryEncrypt의 스팬을 (쓰기 가능)으로 만드는 것은 "Try"가 더 명확한 쪽에 앉게 함으로써 너무 작을 수 있는 세 개의 버퍼가 있음을 의미합니다. 너무 짧은 버퍼를 제공하지 마십시오.).
• 이것이 작동하지 않는 AE 알고리즘을 제공합니다.
• associatedData 를 기본값 ReadOnlySpan<byte>.Empty 으로 끝까지 이동해야 합니까?
  
  
  
  • 아니면 그것을 생략하는 오버로드가 만들어졌습니까?
  
  
• byte[] -returning 메서드에 대한 사랑이나 증오를 주장하고 싶은 사람이 있습니까? (낮은 할당은 Span 방식을 사용하여 달성할 수 있습니다. 이것은 단지 편의를 위한 것입니다)
• 크기 범위 방법은 결국 볼트로 고정되었습니다.
  
  
  
  • 그들의 목적은
  
  
  • 대상 범위가 min보다 작으면 즉시 false를 반환합니다.
  
  
  • byte[] -returning 메소드는 최대 버퍼를 할당한 다음 필요에 따라 Array.Resize합니다.
  
  
  • 예, GCM 및 CCM min=max=input.Length 의 경우 CBC+HMAC 또는 SIV에는 해당되지 않습니다.
  
  
  • 연관된 데이터 길이를 고려해야 하는 알고리즘이 있습니까?
  
  

확실히 바이트 - 비트가 아닙니다.
키를 인식하지 못하는 Nonce 공급자는 큰 실수입니다.

키를 인식하지 못하는 Nonce 공급자는 큰 실수입니다.

nonce 공급자를 원하는 대로 작성할 수 있습니다. 우리는 아무것도 제공하지 않습니다.

결정적 정리/ IDisposable 는 어떻습니까?

결정적 정리/IDisposable은 어떻습니까?

좋은 전화입니다. AuthenticatedEncryptor/AuthenticatedDecryptor에 추가했습니다. 나는 논스 공급자에 대한 폐기 가능성을 조사해야 한다고 생각하지 않습니다. 호출자는 using 문을 스택할 수 있습니다.

INonceProvider 개념/목적이 나에게 의미가 없습니다(다른 사람들에게 반향을 줌). 프리미티브를 프리미티브로 둡니다. 키를 전달하는 것과 같은 방식으로 nonce를 전달합니다(예: 바이트로 - 선언된 대로). AE/AEAD 사양은 nonce가 생성/유도되는 방법에 대한 알고리즘을 강제하지 않습니다. 이것은 더 높은 계층의 책임입니다(적어도 let-primitives-be-primitive 모델에서는).

스트리밍이 안되나요? 진짜? 핵심 기초 수준에서 AES-GCM과 같은 스트림 암호에서 스트리밍을 강제로 제거하는 근거는 무엇입니까?

예를 들어, 귀하의 암호화폐 위원회는 우리가 검토한 이 두 가지 최근 시나리오를 무엇을 권장합니까?

1. 클라이언트에는 10-30GB 사이의 대용량 의료 파일이 있습니다. 코어는 두 시스템 사이의 데이터 스트림만 볼 수 있으므로 하나의 패스 스트림입니다. 분명히 각 10GB 파일에 대해 새 키가 발급되지만 이러한 모든 워크플로를 쓸모없게 만들었습니다. 이제 a) 데이터 버퍼링(메모리, 파이프라인 없음) b) 암호화 수행(파이프라인의 모든 시스템은 이제 유휴 상태입니다!) c) 데이터 쓰기(및 b 다음에 작성된 첫 번째 바이트는 100%임) 완료) ? 농담이라고 말해주세요. 여러분은 고의로 "암호화는 부담입니다"를 게임에 다시 집어넣고 있습니다.

2. 물리적 보안 장치에는 미사용 시나리오에서도 암호화되는 여러 4K 스트림이 있습니다. 새로운 키 발급은 15GB 경계에서 발생합니다. 전체 클립을 버퍼링할 것을 제안합니까?

커뮤니티에서 실제로 실제 소프트웨어를 구축하고 스트리밍 지원을 제거하도록 요청하는 사람들의 의견을 볼 수 없습니다. 그러나 팀은 커뮤니티 대화 상자에서 사라지고 내부적으로 모여 있다가 아무도 요청하지 않은 것으로 돌아와서 실제 응용 프로그램을 종료하고 "암호화는 느리고 비용이 많이 듭니다. 건너뛰시겠습니까?"라고 다시 강조합니다.

전체 생태계에 대한 결정을 부과하는 대신 두 옵션을 모두 지원하는 Encrypt 및 EncryptFinal 를 제공할 수 있습니다.

우아한 디자인은 통제가 아닌 복잡성을 제거합니다.

핵심 기초 수준에서 AES-GCM과 같은 스트림 암호에서 스트리밍을 강제로 제거하는 근거는 무엇입니까?

나는 그것이 다음과 같았다고 생각한다.

이 제안은 데이터 스트리밍을 제거합니다. 우리는 그 점에서 유연성이 별로 없습니다. 관련 위험(GCM의 경우 매우 높음) 또는 불가능(CCM)과 결합된 실제 요구 사항(낮음)은 이제 막 사라졌음을 의미합니다.

GCM에는 키 복구를 허용하는 죄송스러운 순간이 너무 많습니다. 공격자가 선택한 암호문을 수행하고 태그 확인 이전의 스트리밍 출력을 볼 수 있으면 키를 복구할 수 있습니다. (또는 암호 분석가 중 한 명이 나에게 말합니다). 사실상 GCM 처리 데이터가 태그 확인 전 어느 시점에서든 관찰 가능하면 키가 손상됩니다.

Crypto Board는 첫 번째 시나리오에 GCM을 사용하지 않고 CBC+HMAC를 사용하는 것이 좋습니다.

두 번째 시나리오가 4k 프레임이고 각 4k 프레임을 암호화하는 경우 이 모델에서 작동합니다. 각 4k + nonce + 태그 프레임은 바이트를 다시 받기 전에 해독되고 확인되므로 키 스트림/키가 누출되지 않습니다.

비교를 위해: 저는 현재 이 "프리미티브를 프리미티브로 설정" 암호화 API를 개발 중입니다. 다음 은 인증된 암호화에 대한 클래스입니다.

나에게는 키와 독립적으로 암호화 기본 요소에 대해 이야기할 수 있다는 것이 유용하다는 것이 밝혀졌습니다. 예를 들어, 특정 프리미티브를 모든 AEAD 알고리즘과 함께 작동하는 메서드에 연결하고 키 등의 생성을 해당 메서드에 맡기고 싶습니다. 따라서 AeadAlgorithm 클래스와 별도의 Key 클래스가 있습니다.

이미 여러 버그를 방지한 또 다른 매우 유용한 것은 모든 것에 대해 일반 byte[] 또는 Span<byte> 를 사용하는 대신 고유한 유형을 사용하여 다른 모양의 데이터(예: Key 및 Nonce )를 나타내는 것입니다.

public abstract class AeadAlgorithm : Algorithm
{
    public int KeySize { get; }

    public int NonceSize { get; }

    public int TagSize { get; }

    public byte[] Decrypt(
        Key key,
        Nonce nonce,
        ReadOnlySpan<byte> associatedData,
        ReadOnlySpan<byte> ciphertext)

    public void Decrypt(
        Key key,
        Nonce nonce,
        ReadOnlySpan<byte> associatedData,
        ReadOnlySpan<byte> ciphertext,
        Span<byte> plaintext)

    public byte[] Encrypt(
        Key key,
        Nonce nonce,
        ReadOnlySpan<byte> associatedData,
        ReadOnlySpan<byte> plaintext)

    public void Encrypt(
        Key key,
        Nonce nonce,
        ReadOnlySpan<byte> associatedData,
        ReadOnlySpan<byte> plaintext,
        Span<byte> ciphertext)

    public bool TryDecrypt(
        Key key,
        Nonce nonce,
        ReadOnlySpan<byte> associatedData,
        ReadOnlySpan<byte> ciphertext,
        out byte[] plaintext)

    public bool TryDecrypt(
        Key key,
        Nonce nonce,
        ReadOnlySpan<byte> associatedData,
        ReadOnlySpan<byte> ciphertext,
        Span<byte> plaintext)
}

@bartonjs 그/그녀가 맞습니다. 인증할 때까지 출력되지 않는 프로그램에 의존해야 합니다. 예를 들어 인증하지 않거나 아직 인증하지 않은 경우 블록에 대한 입력을 제어할 수 있으므로 출력을 알고 거기에서 거꾸로 작업할 수 있습니다.

예를 들어 man in the middle attack은 알려진 블록을 cbc 스트림에 주입하고 고전적인 비트 뒤집기 공격을 수행할 수 있습니다.

직렬 nonce 또는 이와 유사한 ... ala TLS를 사용하여 청크를 사용하여 다른 많은 데이터 문제를 해결하는 방법을 잘 모르겠습니다.

글쎄요, 제가 하는 말을 다시 말씀드리자면, 일반적인 목적의 라이브러리에는 충분하지 않은 작은 크기의 네트워크에만 해당됩니다.

공개의 정신으로 누가 Microsoft 암호화 검토 위원회에 있는지(이상적으로는 이 주제를 검토한 특정 구성원의 의견/의견) 밝힐 수 있습니까? 브라이언 라마키아 와 그 외 누구?

_역심리학 사용:_

스트리밍 AEAD가 나와서 기쁩니다 . 이것은 Inferno 가 계속해서 평균적인 Joe를 위한 유일한 실용적인 CryptoStream 기반 스트리밍 AEAD임을 의미합니다. MS Crypto Review Board에 감사드립니다!

@ektrah 의 의견을 바탕으로 그의 (그녀?) 접근 방식은 앞서 언급한 RFC 5116 에 의해 주도됩니다. RFC 5116에는 다음과 같은 주목할만한 인용문이 많이 있습니다.

3.1. Nonce 생성에 대한 요구 사항
키의 고정 값에 대해 인증된 암호화 작업의 각 호출에 대해 각 nonce 값이 고유해야 한다는 요구 사항을 존중하는 방식으로 nonce를 구성하는 것이 보안에 필수적입니다.
...

1. AEAD 알고리즘 사양에 대한 요구 사항
   각 AEAD 알고리즘은 N_MIN 및 N_MAX 값이 해당 알고리즘에 고유한 N_MIN 및 N_MAX 옥텟(포함) 사이의 길이를 가진 모든 nonce를 수락해야 합니다. N_MAX와 N_MIN의 값은 같을 수 있습니다. 각 알고리즘은 길이가 12옥텟인 논스를 받아들여야 합니다(SHOULD). 아래에 설명된 무작위 또는 상태 저장 알고리즘은 N_MAX 값이 0일 수 있습니다(MAY).
   ...
   인증된 암호화 알고리즘은 예를 들어 암호문 출력에 통합되는 내부 초기화 벡터 생성을 위해 임의 소스를 통합하거나 사용할 수 있습니다(MAY). 이러한 종류의 AEAD 알고리즘을 randomized라고 합니다. 암호화만 무작위이며 암호 해독은 항상 결정적입니다. 무작위 알고리즘은 0과 같은 N_MAX 값을 가질 수 있습니다(MAY).

인증된 암호화 알고리즘은 예를 들어 알고리즘에 의해 내부 임시값으로 사용되는 고유한 값의 구성을 허용하기 위해 암호화 작업의 호출 사이에 유지되는 내부 상태 정보를 통합할 수 있습니다. 이러한 종류의 AEAD 알고리즘을 상태 저장(stateful)이라고 합니다. 이 방법은 응용 프로그램이 길이가 0인 nonce를 입력하는 경우에도 우수한 보안을 제공하기 위해 알고리즘에서 사용할 수 있습니다. 상태 저장 알고리즘은 0과 같은 N_MAX 값을 가질 수 있습니다(MAY).

탐색할 가치가 있는 한 가지 아이디어는 길이가 0이거나 null인 Nonce를 전달하는 것입니다. 이는 기본값일 수도 있습니다. 이러한 "특별한" Nonce 값을 전달하면 실제 Nonce 값이 무작위로 지정되며 Encrypt의 출력으로 사용할 수 있습니다.

"이유" 때문에 INonceProvider 가 유지되는 경우 AuthenticatedEncryptor 를 다시 입력할 때마다 트리거되는 Reset() 호출을 추가하는 것이 좋습니다. 반면에 AuthenticatedEncryptor 인스턴스의 키를 다시 입력하지 않을 계획이라면 스트리밍 청크 암호화 API(예: 청크 = 네트워크 패킷)를 구축하려는 경우 GC를 폐기하고 모든 청크는 다음과 같아야 합니다. 다른 키로 암호화됨(예: Netflix MSL 프로토콜, Inferno 등). 특히 AEAD 엔진 풀을 유지 관리하고 enc/dec를 수행하기 위해 해당 풀에서 인스턴스를 차용하려는 병렬 enc/dec 작업의 경우. GC에게 사랑을 주세요 :)

내 관점에서 암호화 기본 요소의 유일한 목적은 잘 설계된 고급 보안 프로토콜을 구현하는 것입니다. 이러한 모든 프로토콜은 고유한 방식으로 임시 항목을 생성해야 한다고 주장합니다. 예를 들어:

• TLS 1.2는 RFC 5116의 권장 사항을 따르고 4바이트 IV를 8바이트 카운터와 연결합니다.
• TLS 1.3 xor는 12바이트 IV로 12바이트로 채워진 8바이트 카운터입니다.
• 노이즈는 AES-GCM에 대해 빅엔디안 바이트 순서 로 12바이트 로 패딩된 8바이트 카운터와 ChaCha/Poly에 대해 리틀엔디안 바이트 순서 로 12바이트로 패딩된 8바이트 카운터를 사용합니다.

GCM은 일반적인 nonce 크기(96비트)에서 임의 nonce에 대해 너무 취약합니다. 그리고 실제로 무작위 nonce를 지원하는 보안 프로토콜을 알지 못합니다.

암호화 프리미티브를 제공하는 더 많은 API에 대한 수요는 많지 않습니다. 99.9%의 개발자는 데이터베이스에 암호 저장, 저장 파일 암호화, 소프트웨어 업데이트를 안전하게 전송하는 등 보안 관련 시나리오를 위한 고급 레시피가 필요합니다.

그러나 이러한 고급 레시피를 위한 API는 드뭅니다. 사용 가능한 유일한 API는 종종 HTTPS와 암호화 기본 요소뿐이므로 개발자는 자체 보안 프로토콜을 실행해야 합니다. IMO 솔루션은 프리미티브 작업을 위한 API 설계에 많은 노력을 기울이지 않는 것입니다. 고급 레시피용 API입니다.

피드백 주셔서 감사합니다. 여러분! 몇 가지 질문:

1. 스트리밍 복호화는 치명적으로 실패할 수 있지만 스트리밍 암호화는 가능합니다. 스트리밍 암호화(비 스트리밍 옵션과 함께)가 있지만 스트리밍이 아닌 암호 해독만 더 유용하게 들립니까? 그렇다면 해결해야 할 몇 가지 문제가 있습니다.
   ㅏ. 일부 알고리즘(CCM, SIV)은 실제로 스트리밍을 지원하지 않습니다. 기본 클래스에 스트리밍 암호화를 적용하고 스트리밍된 입력을 버퍼링해야 하나요? 아니면 파생 클래스에서 던져야 하나요?
   비. 스트리밍 AAD는 구현 제약으로 인해 가능하지 않을 수 있지만 다른 알고리즘은 다른 시간에 이를 필요로 합니다(일부는 처음에 필요하고 일부는 끝날 때까지 필요하지 않음). 미리 요구해야 합니까 아니면 개별 알고리즘이 허용할 때 작동하는 추가 방법이 있어야 합니까?

1. 사용자가 새 nonce를 생성하는 코드를 작성해야 한다는 점만 고려하면 INonceProvider를 개선할 수 있습니다. 다른 사람이 제안한 모양이 있습니까?

1 . = 사용자에게 미리 경고하지 않는 것이 문제가 될 수 있다고 생각합니다. 위의 누군가가 10GB 파일로 시나리오를 상상해보십시오. 그들은 스트리밍을 받고 있다고 생각하고 나중에 다른 개발자가 암호를 변경하고 다음 코드는 값을 반환하기 전에 10GB를 버퍼링(또는 시도)합니다.

1. b = 다시 "스트리밍" 또는 네트워킹 아이디어(예: AES GCM 등)를 사용하면 암호 해독이 끝날 때까지 AAD 정보를 얻을 수 없습니다. 암호화에 관해서는 아직 데이터를 미리 가지고 있지 않은 경우를 보지 못했습니다. 따라서 적어도 암호화의 경우 시작 시 요구해야 하며 암호 해독은 더 복잡합니다.

1. 인터페이스를 통해 nonce에 "바이트"를 제공하거나 직접적으로 제공하는 것은 문제가 되지 않는다고 생각합니다. 두 가지 방법으로 같은 것을 얻을 수 있습니다. 원시인에게는 더 못생겼지만 사람들이 밤에 더 잘 자게 해준다면 격렬하게 반대하지 않습니다. 나는 이것을 완료된 거래로 취소하고 다른 문제로 넘어갈 것입니다.

심의 과정에 대해

@bartonjs : 커뮤니티 참여가 없는 비공개 결정이 효과적인 정당화라면 하루 종일 논쟁을 벌일 수 있지만 주제에서 벗어나도록 하겠습니다. 게다가 더 풍부한 대면이나 실시간 통신이 없기 때문에 나는 그곳에서 누구를 화나게 하고 싶지 않습니다.

스트리밍에 관하여

1. '스트리밍은 AES-GCM 보안을 의미하지 않음' 인수

특히 스티밍 => 태그 확인 전에 복호화된 데이터를 호출자에게 반환 => 보안 없음. 이것은 소리가 아닙니다. @bartonjs 는 '선택된 암호문 => 출력 보기 => 키 복구'를 주장하는 반면 @drawaes 는 '블록에 대한 제어 입력 => 따라서 출력을 알고 있음 => "거기에서 작업"'이라고 주장합니다.

글쎄요, AES-GCM에서 태그가 하는 일은 무결성 검증(변조 방지) 뿐입니다 . 개인 정보 보호에 0 영향을 미칩니다. 실제로 AES-GCM에서 GCM/GHASH 태그 처리를 제거하면 단순히 AES-CTR 모드가 됩니다. 프라이버시 측면을 처리하는 것은 이 구조입니다. 그리고 CTR은 비트 플립에 유연하지만 기본 AES 프리미티브가 손상되었음을 의미하기 때문에 두 사람이 주장하는 방식(키 또는 일반 텍스트 복구)에서 "깨지지" 않습니다. 암호 분석가(누구입니까?)가 다른 사람들이 모르는 것을 알고 있다면 그/그녀가 그것을 게시해야 합니다. 가능한 유일한 것은 공격받은 사람이 비트 N을 뒤집을 수 있고 일반 텍스트의 비트 N이 뒤집혔다는 것을 알 수 있지만 실제 일반 텍스트가 무엇인지는 결코 알 수 없다는 것입니다.

그래서

1) 일반 텍스트 개인 정보가 항상 적용됩니다.
2) 무결성 검증은 단순히 연기되고(스트림이 끝날 때까지)
3) 어떠한 키도 손상되지 않습니다.

스트리밍이 기본인 제품 및 시스템의 경우 이제 AEAD에서 일반 AES 암호화로 일시적으로 단계를 낮추고 태그 확인 시 다시 AEAD로 다시 올라가는 절충안을 설계할 수 있습니다. 이는 "이 모든 것을 버퍼링하고 싶습니까? 미쳤습니까? 우리는 암호화를 할 수 없습니다!"라고 말하는 대신 보안을 수용하기 위해 몇 가지 혁신적인 개념을 잠금 해제합니다.

모두 Encrypt 및 EncryptFinal (또는 이에 상응하는 것)가 아닌 EncryptFinal 구현하기를 원하기 때문입니다.

2. GCM에만 국한되지 않습니다!

이제 AES-GCM은 "죄송한 순간"을 즐길 수 있는 마법의 짐승이 아닙니다. 그것은 단순히 AES-CTR + GHASH(가능하다면 일종의 해시)입니다. 개인 정보와 관련된 Nonce 고려 사항은 CTR 모드에서 상속되고 무결성과 관련된 태그 고려 사항은 사양에서 허용되는 가변 태그 크기에서 나옵니다. 여전히 AES-CTR + GHASH는 첫 번째 알고리즘이 개인 정보를 처리하고 두 번째 알고리즘이 무결성을 처리한다는 점에서 AES-CBC + HMAC-SHA256과 매우 유사합니다. AES-CBC + HMAC-SHA256에서 암호문의 비트 플립은 해독된 텍스트의 해당 블록을 손상시키고(CTR과 달리) 다음 해독된 일반 텍스트 블록(예: CTR)의 비트를 결정론적으로 뒤집습니다. 다시 말하지만, 공격자는 결과 일반 텍스트가 무엇인지 알 수 없습니다. 단지 비트가 뒤집힌 것뿐입니다(예: CTR). 마지막으로 무결성 검사(HMAC-SHA256)가 이를 포착합니다. 그러나 마지막 바이트만 처리합니다(예: GHASH).

따라서 무결성이 정상일 때까지 모든 해독된 데이터를 보류한다는 주장이 진정으로 좋은 것이라면 일관되게 적용해야 합니다. 따라서 AES-CBC 경로에서 나오는 모든 데이터도 HMAC-SHA256이 통과할 때까지 버퍼링되어야 합니다(라이브러리에 의해 내부적으로). 이는 기본적으로 .NET에서 스트리밍 데이터가 AEAD의 발전으로부터 혜택을 받을 수 없음을 의미합니다. .NET은 스트리밍 데이터를 강제로 다운그레이드합니다. 암호화 없음 또는 일반 암호화 중에서 선택합니다. AEAD가 없습니다. 버퍼링이 기술적으로 비실용적일 경우 건축가는 최소한 최종 사용자에게 "무관심"이 아닌 "드론 영상이 손상될 수 있음"을 경고할 수 있는 옵션이 있어야 합니다.

3. 우리가 가진 것 중 최고야

데이터는 점점 더 커지고 보안은 더 강력해져야 합니다. 스트리밍은 디자이너가 수용해야 하는 현실이기도 합니다. 전 세계가 기본적으로 부패 중간 변조를 감지할 수 있는 진정으로 통합된 AEAD 알고리즘을 만들 때까지 우리는 친구처럼 암호화 + 인증을 고수해야 합니다. 진정한 AEAD 프리미티브가 연구되고 있지만 지금은 암호화 + 인증이 있습니다.

스트리밍 워크로드를 지원할 수 있는 빠르고 인기 있는 AEAD 알고리즘에 관심을 갖는 만큼 "AES-GCM"에는 관심이 없습니다.

4. AES-CBC-HMAC 사용, 사용(해결 방법 삽입)

Crypto Board는 첫 번째 시나리오에 GCM을 사용하지 않고 CBC+HMAC를 사용하는 것이 좋습니다.

위에서 언급한 모든 것 또는 시나리오의 세부 사항을 제쳐두고 AES-CBC-HMAC가 무료가 아님을 암시합니다. AES-CBC 암호화는 병렬화할 수 없고 GHASH는 PCLMULQDQ 명령을 통해 가속될 수 있기 때문에 AES -GCM보다 ~3배 느립니다 . 따라서 AES-GCM을 사용하여 1GB/초에 있는 경우 이제 AES-CBC-HMAC에서 ~300MB/초에 도달하게 됩니다. 이것은 다시 "Crypto는 속도를 늦추고 건너 뛰십시오"라는 사고 방식을 수행합니다. 보안 담당자는 싸우기 위해 열심히 노력합니다.

각 4k 프레임 암호화

비디오 코덱이 갑자기 암호화를 수행해야 합니까? 아니면 이제 암호화 계층이 비디오 코덱을 이해해야 합니까? 데이터 보안 계층의 비트스트림일 뿐입니다. 비디오/게놈 데이터/이미지/독점 형식 등이라는 사실은 보안 계층 ​​문제가 되어서는 안 됩니다. 전체 솔루션은 핵심 책임을 혼합해서는 안됩니다.

목하

NIST는 길이가 96비트를 초과하는 무작위 IV를 허용합니다. NIST 800-38D 의 섹션 8.2.2를 참조하십시오. 여기에 새로운 것은 없으며 nonce 요구 사항은 CTR 모드에서 제공됩니다. 이것은 또한 대부분의 스트림 암호에서 상당히 표준적 입니다. 나는 nonces에 대한 갑작스러운 두려움을 이해하지 못합니다. 항상 number used once . 그럼에도 불구하고 INonce 논쟁이 투박한 인터페이스를 만들기는 하지만 적어도 스트림이 필요 없는 부과와 같은 혁신을 제거하지는 않습니다. AEAD 보안 + 스트리밍 워크로드 혁신을 얻을 수 있다면 언제든지 INonce 에 양보하겠습니다. 나는 혁신 스트리밍과 같은 기본적인 것을 말하는 것을 싫어합니다. 하지만 그것이 우리가 퇴보할까봐 두려워하는 부분입니다.

나는 틀렸다는 것이 증명되기를 원한다.

나는 직장에서 긴 하루를 보낸 후 이것을 타자하기 위해 아이들과 함께 영화의 밤을 포기한 사람입니다. 나는 피곤하고 틀릴 수 있습니다. 그러나 최소한 일화나 "위원회 이유" 또는 기타 부두교보다는 사실에 기반한 공개 커뮤니티 대화가 있어야 합니다. 저는 안전한 .NET 및 Azure 혁신을 촉진하는 사업을 하고 있습니다. 나는 우리가 일치된 목표를 가지고 있다고 생각합니다.

커뮤니티 대화라고 하면 ...

커뮤니티 Skype 통화를 할 수 있습니까? 이처럼 복잡한 주제를 표현하는 것은 거대한 텍스트의 벽에 부딪힙니다. 예쁘게 주세요?

Skype 통화를 하지 마십시오. 커뮤니티에서 사용할 수 있는 기록이 없는 "비공개 모임"의 정의입니다. Github 문제는 모든 당사자가 민사 문서화된 담론을 가질 수 있는 올바른 수단입니다(MS 주석 제거 선례 무시).

MS Crypto Review Board도 아마 Skype 통화를 했을 것입니다. 이것은 이 스레드에 참여하는 MS 사람들의 잘못이 아닙니다. 그들은 MS Crypto Review Board의 상아탑에 대한 접근 및 설득력이 매우 제한적일 것입니다(무엇이든/누구든 간에).

스트리밍 AEAD 관련:

바이트 크기 스트리밍 _encryption_은 GCM, CTR+HMAC와 같은 MAC 마지막 모드에서는 가능하지만 CCM과 같은 MAC 우선 모드에서는 불가능합니다. 바이트 크기 스트리밍 _decryption_은 기본적으로 누출되므로 누구도 고려하지 않습니다. 블록 크기 스트리밍 _encryption_은 CBC+HMAC에서도 가능하지만 아무 것도 변경되지 않습니다. 즉. AEAD 스트리밍에 대한 바이트 크기 또는 블록 크기 접근 방식에는 결함이 있습니다.

청크 크기 스트리밍 _encryption_ 및 _decryption_은 훌륭하게 작동하지만 두 가지 제약 조건이 있습니다.

• 버퍼링이 필요합니다(블록 크기 이상). 이것은 버퍼링이 제어/캡핑된 경우(예: Inferno) 라이브러리/API에서 수행하거나 처리할 상위 계층(호출 계층)에 남겨둘 수 있습니다. 어느 쪽이든 작동합니다.

• 청크 스트리밍 AEAD는 표준화되지 않았습니다. 전. nacl-stream , Inferno, MS 소유 DataProtection, 자체 제작.

이것은 지금까지 이 토론의 모든 사람들이 이미 알고 있는 내용을 요약한 것입니다.

@sdrapkin , 내가 제대로 이해했는지 확인하기 위해 스트리밍 암호화를 제공하지만 스트리밍 복호화를 제공하지 않는 이 API는 괜찮습니까?

@sdrapkin 음 , 실시간으로 브레인스토밍을 하는 인간은 확실히 유익합니다. 기록 유지 문제는 회의록으로 해결할 수 있습니다. 기술적인 측면으로 돌아가서 청킹은 스트리밍 암호 해독을 위해 작동하지만 낮은 수준의 보안 기본 요소는 아닙니다. 커스텀 프로토콜입니다. 그리고 당신이 지적한 것과 같은 비표준 하나.

@morganbr

_스트리밍 암호화를 제공하지만 스트리밍 복호화는 제공하지 않는 이 API는 괜찮습니까?_

아니, 난 아니야. 그러한 API를 사용할 수 있다면 버퍼 복호화로 해독할 수 없는 크기의 스트림 암호화 암호문을 쉽게 만들 수 있습니다(메모리 부족).

^^^^ 이건 아직까지 합의가 많이 된건 아니지만 비대칭 API가 어떻게 되든 간에 재앙이 될 것이라는 점에는 모두 동의할 수 있을 것 같습니다. "헤이는 암호화 방법이 있기 때문에 내가 의존할 것이라고 생각한 스트림 암호 해독 방법입니다"와 위의 @sdrapkin 주석 때문입니다.

@Drawaes 동의합니다. 비대칭 enc/dec API는 끔찍할 것입니다.

업데이트가 있습니까?

분명히 나는 ​​몇 가지 공격을 통합했습니다.

스트림 암호(AES-CTR 및 AES-GCM이 있음)의 고유한 약점은 임의의 일반 텍스트 복구를 허용하는 선택된 암호문 공격을 허용합니다. 선택된 암호문 공격에 대한 방어는 인증입니다. 그래서 AES-GCM은 면역이 됩니다... 스트리밍 복호화를 하지 않고 부채널 관찰에서 일반 텍스트가 무엇인지 식별할 수 없다면 말입니다. 예를 들어, 해독된 데이터가 XML로 처리되는 경우 공백 또는 < 이외의 문자가 해독된 데이터의 시작 부분에 있으면 매우 빠르게 실패합니다. 그래서 "스트리밍 암호 해독은 스트림 암호 설계에 대한 우려를 재도입합니다"(이는 .NET에는 전혀 없음을 눈치채셨을 수도 있습니다)입니다.

키 복구가 어디에서 왔는지 찾는 동안 인증 과 같은 문서가 있습니다.GCM(Ferguson/Microsoft)의 약점 이지만 짧은 태그 크기를 기반으로 인증 키를 복구하는 것입니다(이는 Windows 구현에서 96비트 태그만 허용하는 이유의 일부임). 스트리밍 GCM이 위험한 이유에 대해 다른 인증 키 복구 벡터에 대해 조언을 받았을 것입니다.

이전 댓글 에서 @sdrapkin 은 "바이트 크기 스트리밍 암호 해독이 근본적으로 누출되고 있으므로 누구도 고려하지 않습니다. ... 스트리밍 AEAD에 대한 바이트 크기 또는 블록 크기 접근 방식에는 결함이 있습니다."라고 언급했습니다. 스트리밍 암호화를 수행할 수 없는 CCM(및 SIV)과 결합하고 스트리밍 중 하나는 갖고 다른 하나는 갖지 않는 것이 이상하다는 의견은 우리가 원샷 암호화 및 해독하다.

그래서 우리는 마지막 API 제안(https://github.com/dotnet/corefx/issues/23629#issuecomment-329202845)으로 돌아온 것 같습니다. 쉬는 동안 잊어 버린 다른 미해결 문제가 없다면.

다시 오신 것을 환영합니다 @bartonjs

나는 곧 그러나 잠시 잠을 잘 것이다:

1. 우리는 이 스레드에서 이전에 기본 디자인과 프로토콜 디자인을 결합했습니다. 선택된 암호문 공격은 원시적인 문제가 아니라 프로토콜 설계의 문제라고 말하겠습니다.

2. 스트리밍 AEAD 암호 해독을 사용하면 최소한 개인 정보를 보호할 수 있으며 마지막 바이트에서 개인 정보 보호 + 진위성으로 즉시 업그레이드할 수 있습니다. AEAD에 대한 스트리밍 지원(즉, 기존의 개인 정보만 해당)이 없으면 사람들을 더 낮은 수준의 개인 정보 보호만 영구적으로 제한하게 됩니다.

기술적인 장점이 충분하지 않거나 내 주장의 권위에 대해 (당연히) 회의적이라면 나는 외부 권위 경로를 시도할 것입니다. 실제 기본 구현은 스트리밍 모드에서 AEAD(AES GCM 포함)를 지원한다는 것을 알아야 합니다. Windows 코어 OS( bcrypt )는 BCryptEncrypt 또는 BCryptDecrypt 기능을 통해 GCM을 스트리밍할 수 있습니다. 거기에서 dwFlags 를 참조하십시오. 또는 사용자 코드 예제 . 또는 Microsoft 제작 CLR 래퍼 . 또는 구현이 올해 초에 NIST FIP-140-2 인증 을 받았습니다. 또는 Microsoft와 NIST 모두 AES 구현과 관련하여 상당한 리소스를 사용하고 여기 와 여기에서 인증했습니다. 이 모든 것에도 불구하고 아무도 원시인을 탓하지 않았습니다. .NET Core가 갑자기 나타나 강력한 기본 구현을 약화시키기 위해 자체 암호화 이론을 부과하는 것은 전혀 의미가 없습니다. 특히 스트리밍과 원샷을 동시에 지원할 수 있는 경우 매우 간단합니다.

더? 음, 위의 내용은 '최신' evp API를 사용하는 경우에도 OpenSSL에 해당합니다.

BouncyCastle의 경우도 마찬가지입니다.

Java Cryptography Architecture에서도 마찬가지입니다.

건배!
시드

@sidshetye ++10 크립토보드가 그렇게 걱정된다면 왜 Windows CNG가 이 작업을 수행하도록 합니까?

Microsoft의 NIST FIPS-140-2 AES 유효성 검사(예: # 4064 )를 확인하면 다음을 확인할 수 있습니다.

AES-GCM:

• 일반 텍스트 길이: 0, 8, 1016, 1024
• AAD 길이: 0, 8, 1016, 1024

AES-CCM:

• 일반 텍스트 길이: 0-32
• AAD 길이: 0-65536

스트리밍에 대한 유효성 검사가 없습니다. NIST가 그 예를 확인하는지 여부조차 확실하지 않습니다. AES-GCM 구현은 64Gb 이상의 일반 텍스트를 암호화하도록 허용되어서는 안 됩니다(GCM의 또 다른 터무니없는 제한).

내 사용이 16k를 넘지 않아야하므로 스트리밍에 크게 집착하지는 않지만 조각난 버퍼는 훌륭하고 전혀 위험하지 않아야합니다 (실제로 cng가 인터페이스를 정확히 그 목적을 위해 만든 것으로 의심됩니다) ... 예를 들어 여러 범위 또는 이와 유사한 것(예: 연결 목록)을 전달하고 한 번에 해독할 수 있기를 원합니다. 연속 버퍼로 해독하면 문제가 없습니다.

따라서 "스트리밍 스타일" API에서 섀도우 크립토 보드를 이동하는 것은 지금으로서는 안 될 일이라고 생각합니다. 따라서 앞으로 나아가서 원샷 API를 만들어 보겠습니다. 충분한 사람들이 나중에 필요를 표시하면 API를 확장할 수 있는 여지가 항상 있습니다.

@sdrapkin 요점은 NIST Labs와 MSFT에서 광범위한 검토를 거친 스트리밍 API라는 것입니다. 검증되는 각 빌드는 $80,000 - $50,000이며 MSFT(OpenSSL, Oracle 및 기타 크립토 헤비급)는 10년 넘게 이러한 API 및 구현을 검증하는 데 막대한 투자를 했습니다. .NET은 스트리밍 또는 원샷에 관계없이 0, 8, 1016, 1024 이외의 크기를 지원할 것이라고 확신하기 때문에 테스트 계획의 특정 일반 텍스트 크기로 인해 주의가 산만해지지 않도록 합니다. 요점은 전투 테스트를 거친 모든 API(말 그대로, 무기 지원 시스템에서), 이러한 모든 플랫폼에서 암호화 기본 API 수준에서 스트리밍 AEAD를 지원한다는 것입니다. 불행히도 지금까지 이에 반대하는 모든 주장은 암호화 기본 수준에서 의사 우려로 인용된 응용 프로그램 또는 프로토콜 수준 문제였습니다.

저는 '최고의 아이디어가 승리하도록 합시다'를 지지하지만 .net 핵심 암호화 팀(MSFT 또는 커뮤니티)이 획기적인 발견을 하지 않는 한, 다른 모든 조직에서 지금까지 암호화를 수행하는 모든 사람이 어떻게 잘못되었는지 알 수 없습니다. 그리고 그들은 옳습니다.

추신: 여기에 동의하지 않는다는 것을 압니다. 하지만 우리 모두는 플랫폼과 고객에게 가장 좋은 것이 무엇인지 원합니다.

@Drawaes 오늘날 정의되고 있는 AEAD 인터페이스(구현이 아닐 수도 있음)가 스트리밍 API 표면을 지원하지 않는 한 사람들이 두 개의 인터페이스나 사용자 정의 인터페이스 없이 어떻게 확장할 수 있는지 알 수 없습니다. 그것은 재앙이 될 것입니다. 나는 이 논의가 미래를 보장하는 인터페이스로 이어지기를 바랍니다(또는 최소한 수년 동안 존재해 온 다른 AEAD 인터페이스를 미러링합니다!).

동의하는 경향이 있습니다. 그러나 이 문제는 아무데도 빠르게 진행되지 않고 있으며, 그런 일이 발생하면 2.1 버전에 도달하지 못하거나 문제를 해결할 시간이 남지 않은 상태에서 문제를 해결해야 하는 위기에 처하게 될 것입니다. 솔직히 말해서 예전 래퍼로 돌아가서 2.0용으로 개조하고 있습니다. ;)

Java , OpenSSL 또는 C# Bouncy Castle 또는 CLR Security 에 대한 몇 가지 참조 API가 있습니다. 솔직히 그들 중 누구라도 할 것이고 장기적으로 나는 C#이 모든 암호화 구현이 잘 확립된 인터페이스에 반대되는 Java의 'Java 암호화 아키텍처' 와 같은 것을 갖고 사용자 코드에 영향을 주지 않고 암호화 라이브러리를 교체할 수 있기를 바랍니다.

여기로 돌아가서 .NET Core의 ICryptoTransform 인터페이스를 다음과 같이 확장하는 것이 가장 좋습니다.

public interface IAuthenticatedCryptoTransform : ICryptoTransform 
{
    bool CanChainBlocks { get; }
    byte[] GetTag();
    void SetExpectedTag(byte[] tag);
}

모든 byte[] 를 Span $#$ 하는 경우 전반적인 일관성을 위해 System.Security.Cryptography 네임스페이스의 전체 API에 침투해야 합니다.

편집: JCA 링크 수정

모든 byte[]를 확장하는 경우 전반적인 일관성을 위해 System.Security.Cryptography 네임스페이스의 전체 API에 침투해야 합니다.

우리는 이미 그렇게 했습니다. 인터페이스를 변경할 수 없기 때문에 ICryptoTransform을 제외한 모든 것.

.NET Core의 ICryptoTransform을 확장하는 것이 가장 좋다고 생각합니다.

이것의 문제는 호출 패턴이 끝에 태그를 가져오는 것이 매우 어색하다는 것입니다(특히 CryptoStream이 관련된 경우). 이거 원래 썼는데 촌스럽네요. GCM 매개변수가 CBC/ECB 매개변수와 다르기 때문에 이들 중 하나를 얻는 방법의 문제도 있습니다.

여기 내 생각이 있습니다.

• 스트리밍 암호 해독은 AE에 위험합니다.
• 일반적으로 저는 "기본값을 주고 위험을 관리하게 해주세요"를 좋아합니다.
• 나는 또한 ".NET은 가치 제안의 일부이기 때문에 완전히 안전하지 않은 것을 (쉽게) 허용해서는 안됩니다"의 팬입니다.
• 내가 원래 잘못 이해한 것처럼 GCM 암호 해독을 잘못 수행하는 위험이 입력 키 복구였다면 여전히 "이것은 너무 안전하지 않습니다"입니다. (.NET과 다른 모든 것의 차이점은 "이 일을 하는 데 시간이 더 오래 걸리고 세상이 더 많이 배웠다"는 것입니다.)
• 그러나 그렇지 않기 때문에 훈련용 바퀴가 정말로 떨어져 나가기를 원한다면 나는 그 개념을 즐겁게 할 것입니다.

그 목적에 대한 내 상당히 원시적인 생각(기존 제안에 추가하여 원샷이 남아 있지만 추상 대신 가상 기본 impl로 추측):

```C#
부분 클래스 AuthenticatedEncryptor
{
// 작업이 이미 진행 중이면 throw
공개 추상 무효 초기화(ReadOnlySpan관련 데이터);
// 성공하면 true, "destination too small"이면 false, 다른 경우에는 예외입니다.
공개 추상 bool TryEncrypt(ReadOnlySpan데이터, 스팬encryptData, out int bytesRead, out int bytesWritten);
// 나머지 EncryptedData가 너무 작으면 false, 다른 입력이 너무 작으면 throw됩니다. NonceOrIVSizeInBits 및 TagSizeInBits 속성을 참조하세요.
// NonceOrIvUsed는 Initialize로 이동할 수 있지만 입력으로 해석될 수 있습니다.
공개 추상 bool TryFinish(ReadOnlySpan나머지 데이터, 스팬나머지 EncryptedData, out int bytesWritten, Span태그, 스팬nonceOrIvUsed);
}

부분 클래스 AuthenticatedDecryptor
{
// 작업이 이미 진행 중이면 throw
공개 추상 무효 초기화(ReadOnlySpan태그, ReadOnlySpannonceOrIv, ReadOnlySpan관련 데이터);
// 성공하면 true, "destination too small"이면 false, 다른 경우에는 예외입니다.
공개 추상 bool TryDecrypt(ReadOnlySpan데이터, 스팬DecryptedData, out int bytesRead, out int bytesWritten);
// 잘못된 태그가 발생하지만 어쨌든 데이터가 누출될 수 있습니다.
// (remainingDecryptedData는 CBC+HMAC에 필요하므로 나머지 데이터도 추가할 수 있습니다.)
공개 추상 bool TryFinish(ReadOnlySpan나머지 데이터, 스팬나머지DecryptedData, out int bytesWritten);
}
```

AssociatedData는 마지막으로 필요한 알고리즘이 이를 유지할 수 있고 먼저 이를 필요로 하는 알고리즘이 다른 방식으로 가질 수 없기 때문에 Initialize에서 제공됩니다.

스트리밍이 어떤 모습일지에 대한 모양이 결정되면(그리고 사람들이 CCM이 스트리밍 암호화 모드에 있을 때 내부적으로 버퍼링되어야 하는지 아니면 던져야 하는지 생각하는지 여부) 다시 게시판으로 돌아가겠습니다.

@bartonjs 암호화/암호 해독 전반에 걸쳐 대칭을 위해 스트림 끝에서 태그를 뽑고 프로그래밍하는 것에 대해 무슨 말인지 압니다. 까다롭지만 각 사용자가 해결하도록 남겨두면 더 나쁩니다. MIT에서 공유할 수 있는 구현이 있습니다. 내 팀과 내부적으로 검토해야 함(내 책상/모바일이 아님)

중간 지점은 OpenSSL 또는 NT의 bcrypt와 같을 수 있습니다. 여기서 태그 비교가 발생하기 때문에 최종 암호 해독 호출 직전에 태그를 연결해야 합니다. 예를 들어 SetExpectedTag (최종 암호 해독 전) 및 GetTag (최종 암호화 후)는 작동하지만 사용자에게 태그 관리 부담을 덜어줍니다. 대부분은 자연스러운 시간 순서이기 때문에 암호 스트림에 태그를 추가하기만 하면 됩니다.

Initialize 자체(암호 해독 시)에 있는 태그를 기대하면 공간(바이트 흐름)과 시간(시작이 아닌 끝에서 태그 확인)의 대칭이 깨져 유용성이 제한된다고 생각합니다. 그러나 위의 태그 API는 이를 해결합니다.

또한 암호화의 경우 Initialize 는 암호화 변환 전에 IV가 필요합니다.

마지막으로 암호화 및 암호 해독을 위해 Initialize 는 변환 전에 AES 암호화 키가 필요합니다. (명백한 것이 누락되었거나 해당 비트를 입력하는 것을 잊으셨습니까?)

초기화 자체(복호화 시)에서 태그를 기대하면 대칭이 깨집니다.

CBC+HMAC에서 일반적인 권장 사항은 복호화를 시작하기 전에 HMAC를 확인하는 것이므로 태그 우선 복호화 알고리즘입니다. 마찬가지로 계산 중에 태그에 대해 파괴적인 작업을 수행하고 최종 응답이 0인지 확인하는 "순수 AE" 알고리즘이 있을 수 있습니다. 따라서 연결된 데이터 값과 마찬가지로 먼저 이를 필요로 하는 알고리즘이 있을 수 있으므로 완전히 일반화된 API에서 가장 먼저 등장합니다.

SetAssociatedData 및 SetTag 에 띄우면 기본 클래스가 알고리즘에 독립적이지만 사용법이 알고리즘에 종속된다는 문제가 있습니다. AesGcm를 AesCbcHmacSha256 또는 SomeTagDesctructiveAlgorithm으로 변경하면 태그가 아직 제공되지 않았기 때문에 TryDecrypt가 발생합니다. 나에게 그것은 전혀 다형성이 아닌 것보다 나쁩니다. 따라서 유연성을 허용하는 것은 알고리즘별로 완전히 분리되도록 모델을 분리하는 것을 제안합니다. (예, NeedsTagFirst 와 같은 더 많은 알고리즘 식별 특성 속성으로 제어할 수 있지만 실제로는 사용하기 더 어려워집니다)

또한 암호화의 경우 초기화는 암호화 변환 전에 IV가 필요합니다.

마지막으로 암호화 및 암호 해독을 위해 Initialize는 변환 전에 AES 암호화 키가 필요합니다.

키는 클래스 ctor 매개변수였습니다. IV/nonce는 ctor 매개변수의 IV/nonce 공급자에서 가져옵니다.

공급자 모델은 암호화 중에 IV가 제공되지 않고 데이터 대신 생성되는 SIV를 해결합니다. 그렇지 않으면 SIV에 매개변수가 있고 빈 값을 제공해야 합니다.

아니면 그 비트를 입력하는 것을 잊으셨습니까?

스트리밍 방법은 이미 키 및 IV/nonce 공급자가 ctor 매개변수로 포함된 기존 제안에 추가되고 있었습니다.

@bartonjs : 어떤 알고리즘은 먼저 태그를 지정하고 다른 알고리즘은 마지막에 태그를 지정할 수 있다는 좋은 점과 원래 사양에 추가된 것임을 상기시켜 주셔서 감사합니다. 사용 사례를 고려하는 것이 더 쉽다는 것을 알았으므로 다음은 클라우드 우선 예입니다.

스토리지에 보관된 하나 이상의 10GB AES-GCM 암호화 파일(예: 암호문 뒤의 태그)에 대한 분석을 수행할 것입니다. 분석 작업자는 동시에 여러 인바운드 스트림을 별도의 시스템/클러스터로 해독하고 마지막 바이트 + 태그 확인 후 각 분석 워크로드를 시작합니다. 모든 스토리지, 작업자, 분석 VM은 Azure US-West에 있습니다.

여기에서 모든 스트림의 끝에 태그를 가져와 AuthenticatedDecryptor의 Initialize 메서드에 제공할 방법이 없습니다. 따라서 사용자가 GCM 사용을 위한 코드 수정을 자원하여도 API 사용을 시작할 수 없습니다.

생각해 보면 다양한 AEAD를 수용하고 사용자 코드 변경이 없는 API를 가질 수 있는 유일한 방법은 다양한 AEAD 알고리즘에 대한 암호화 공급자가 태그를 자동으로 마술처럼 처리하는 것입니다. Java는 GCM에 대한 암호문의 끝에 태그를 추가하여 이를 수행하고 사용자 개입 없이 복호화하는 동안 제거합니다. 그 외에 누군가가 알고리즘을 크게 변경할 때마다(예: CBC-HMAC => GCM) 태그 우선 처리와 태그 후 처리의 상호 배타적 특성 때문에 코드를 수정해야 합니다.

IMHO, 먼저 결정해야 합니다.

옵션 1) 알고리즘 공급자가 내부적으로 태그 관리(예: Java)를 처리합니다.

또는

옵션 2) 사용자가 스스로 할 수 있도록 API에 충분히 노출(예: WinNT bcrypt 또는 openssl)

옵션 1은 버퍼 관리가 복잡해질 수 있기 때문에 라이브러리 소비자의 전반적인 경험을 정말 단순화합니다. 라이브러리에서 잘 풀면 이제 각 사용자가 매번 풀지 않아도 됩니다. 또한 모든 AEAD는 동일한 인터페이스(태그 우선, 태그 후, 태그 없음)를 사용하며 알고리즘 교체도 더 간단합니다.

내 투표는 옵션 1에 대한 것입니다.

마지막으로 GCM을 통한 ICryptoTransform 스트리밍 작업이 태그 인스트림 소스 를 자동으로 뽑을 수 있도록 구현을 파헤칠 수 있었습니다. 이것은 CLR Security의 자체 래퍼에 대한 중요한 업데이트였으며 추가 버퍼 복사본에도 불구하고 여전히 매우 빠릅니다(Windows 10 부트캠프의 테스트 macbook pro에서 ~4GB/초). 우리는 기본적으로 CLR Security를 ​​둘러싸서 우리 자신을 위한 옵션 1을 만들었습니다. 그래서 다른 곳에서는 그것을 할 필요가 없습니다. 이 비주얼 은 ICryptoTransform 인터페이스의 TransformBlock 및 TransformFinalBlock 내에서 무슨 일이 일어나고 있는지 설명하는 데 정말 도움이 됩니다.

@sidshetye 클라우드 우선 예제가 차단된 이유를 잘 모르겠습니다. 저장소에서 읽는 경우 마지막 몇 개의 태그 바이트를 먼저 다운로드하고 암호 해독기 ctor에 제공할 수 있습니다. Azure Storage API를 사용하는 경우 CloudBlockBlob.DownloadRangeXxx 를 통해 수행됩니다.

@GrabYourPitchforks 해당 예제에서 너무 벗어나지 않도록 해야 하지만 이는 Azure Blob Storage의 특정 기능입니다. 일반적으로 VM 기반 스토리지(IaaS) 또는 비 Azure Storage 워크로드는 일반적으로 검색할 수 없는 네트워크 스트림을 얻습니다.

저는 개인적으로 @GrabYourPitchforks 를 보게 되어 매우 기쁩니다.

스토리지에 보관된 하나 이상의 10GB AES-GCM 암호화 파일(예: 암호문 뒤의 태그)에 대한 분석을 수행할 것입니다. 분석 작업자는 동시에 여러 인바운드 스트림을 별도의 시스템/클러스터로 해독하고 마지막 바이트 + 태그 확인 후 각 분석 워크로드를 시작합니다. 모든 스토리지, 작업자, 분석 VM은 Azure US-West에 있습니다.

@sidshetye , 당신은 멍청하고 위험한 프리미티브와 똑똑하고 포옹 가능한 프로토콜을 분리하는 것에 대해 매우 단호했습니다! 나는 꿈이 있었고 그것을 믿었습니다. 그리고 당신은 이것을 우리에게 던집니다. 이것은 프로토콜 - 시스템 설계입니다. 당신이 설명한 프로토콜을 설계한 사람은 엉망입니다. 둥근 구멍에 네모난 못을 끼울 수 없다고 우는 것은 이제 소용이 없습니다.

GCM으로 암호화된 10Gb 파일이 누구건 간에 위험할 정도로 원시 에지(64Gb 이후에는 GCM이 좋지 않음)에 가까이 살고 있을 뿐만 아니라 전체 암호문을 버퍼링해야 한다는 암시적인 주장도 있었습니다.

10Gb 파일을 GCM으로 암호화하는 사람은 압도적인 확률로 프로토콜 실수를 저지르고 있습니다. 솔루션: 청크 암호화. TLS에는 가변 길이 16k로 제한된 청킹이 있으며 더 간단하고 PKI가 없는 다른 기능이 있습니다. 이 가상 예제의 "클라우드 우선" 성적 매력은 디자인 실수를 줄이지 않습니다.

(이 스레드에 대해 따라잡을 일이 많이 있습니다.)

@sdrapkin 은 데이터 보호 계층에서 IAuthenticatedEncryptor 인터페이스를 재사용하는 것에 대해 지적했습니다. 솔직히 말해서 데이터 보호 계층이 암호화를 수행하는 방식에 대해 상당히 독단적이기 때문에 프리미티브에 대한 올바른 추상화라고 생각하지 않습니다. 예를 들어, IV 또는 nonce의 자체 선택을 금지하고 준수 구현이 AAD의 개념을 이해하도록 요구하며 다소 독점적인 결과를 생성합니다. AES-GCM의 경우 IAuthenticatedEncryptor.Encrypt 의 반환 값은 하위 키 파생에 사용되는 거의 아무 것도 없는 이상한 것의 연결입니다. 암호문은 제공된 일반 텍스트에 대해 AES-GCM을 실행한 결과입니다(그러나 AAD!) 및 AES-GCM 태그. 따라서 보호된 페이로드 생성과 관련된 각 단계는 안전하지만 페이로드 자체는 어떤 유형의 승인된 규칙도 따르지 않으며 결과 암호문을 성공적으로 해독할 수 있는 데이터 보호 라이브러리 외에는 아무도 찾지 못할 것입니다. 따라서 앱 개발자 대면 라이브러리에는 좋은 후보이지만 프리미티브에 의해 구현되는 인터페이스에는 끔찍한 후보가 됩니다.

또한 모든 인증된 암호화 알고리즘이 구현해야 하는 One True Interface(tm) IAuthenticatedEncryptionAlgorithm 를 갖는 것에서 상당한 가치를 보지 못한다고 말해야 합니다. 이러한 프리미티브는 단순한 블록 암호 프리미티브 또는 해싱 프리미티브와 달리 "복잡"합니다. 이러한 복잡한 프리미티브에는 변수가 너무 많습니다. 원시 AE만입니까, 아니면 AEAD입니까? 알고리즘이 IV/nonce를 전혀 허용합니까? (나는 그렇지 않은 것을 보았습니다.) 입력 IV / nonce 또는 데이터가 구조화되어야 하는 방법에 대한 우려가 있습니까? IMO 복잡한 프리미티브는 단순히 독립형 API여야 하며 상위 수준 라이브러리는 관심 있는 특정 복잡한 프리미티브를 지원합니다. 그런 다음 상위 수준 라이브러리는 시나리오에 적합하다고 생각하는 균일한 API를 노출합니다.

@sdrapkin 다시 주제에서 벗어납니다. 시스템이 기본 요소를 사용하여 구축되었다고 말할 뿐입니다. 여기에서 암호화 프리미티브는 순수하고 강력합니다. 시스템/프로토콜 계층이 버퍼링을 처리하는 동안; 그것도 클러스터 수준에서, 확실히 원샷 프리미티브가 강제하는 메인 시스템 메모리가 아닙니다. '청킹' 경계는 64GB 미만이므로 X(여기서 X=10GB)입니다. 클러스터의 버퍼링 용량이 거의 무제한이었고 마지막 바이트가 클러스터에 로드될 때까지 아무것도 시작할 수 없었기 때문입니다. 이것은 정확히 관심사의 분리이며, 내가 이야기한 강점에 대해 각 레이어를 최적화합니다. 그리고 이것은 기본 프리미티브가 상위 레이어 디자인/제한을 핸디캡하지 않는 경우에만 발생할 수 있습니다(더 많은 실제 앱에는 고유한 레거시 핸디캡이 있음).

NIST 800-38d sec9.1은 다음과 같이 말합니다.

승인되지 않은 당사자가 IV 생성을 제어하거나 영향을 미치는 것을 방지하기 위해,
GCM은 다음 요구 사항을 충족하는 암호화 모듈 내에서만 구현되어야 합니다.
FIPS 펍. 140-2. 특히 모듈의 암호화 경계는 다음을 포함해야 합니다.
Sec.의 구성 중 하나에 따라 IV를 생산하는 "생성 장치". 8.2 위.
FIPS 140-2의 요구 사항에 대한 검증을 위한 모듈의 문서는 다음과 같아야 합니다.
모듈이 IV의 고유성 요구 사항을 준수하는 방법을 설명합니다.

이는 GCM IV가 내부적으로 자동 생성되어야 하며 외부적으로 전달되지 않아야 함을 의미합니다.

@sdrapkin 좋은 지적이지만 더 자세히 읽어보면 96비트 이상의 IV 길이에 대해 섹션 8.2.2에서 최소 96비트가 무작위인 RBG(임의 비트 생성기)로 IV를 생성할 수 있음을 알 수 있습니다. 다른 비트는 0일 수 있음). 나는 지난 달 이 스레드 자체에 대해 언급했습니다( 여기서는 nonce 아래에 있음).

LT;DR: INonce 는 NIST 및 FIPS 지침을 준수하지 않는 함정입니다.

섹션 9.1은 FIPS 140-2의 경우 IV 생성 장치(완전히 임의적 즉, 8.2.2절 또는 결정론적 구현, 즉 8.2.1절)가 FIPS 검증을 받는 모듈 경계 내에 있어야 한다고 말합니다. 부터 ...

1. RBG는 이미 FIPS 인증을 받았습니다.
2. IV 렌즈 >= 96 권장
3. 재부팅을 지속하는 IV 생성 장치를 설계하면 암호화 기본 계층으로의 무기한 전원 손실이 어렵습니다.
4. 위의 3가지를 암호화 라이브러리 내에서 구현하고 인증을 받는 것은 어렵고 비용이 많이 듭니다(비트가 정확하지 않은 빌드 이미지를 초래하는 모든 경우 $50K).
5. 사용자 코드는 3을 구현하고 위의 4로 인해 인증을 받지 않습니다. (일부 이국적인 군대/정부 시설은 제쳐두고 가자).

... FIPS 인증을 받는 대부분의 암호화 라이브러리(오라클의 Java, WinNT의 bcryptprimitives, OpenSSL 등 참조)는 IV용 RBG 경로를 사용하고 단순히 바이트 배열을 입력으로 사용합니다. INonce 인터페이스를 갖는 것은 실제로 NIST 및 FIPS의 관점에서 보면 함정입니다. 사용자가 해당 인터페이스의 구현을 암호화 기능에 전달해야 함을 암시하기 때문입니다. 그러나 INonce 의 모든 사용자 구현은 9개월 이상 및 $50K 이상의 NIST 인증 프로세스를 거치지 않았음을 거의 보장합니다. 그러나 RGB 구조(이미 암호화 라이브러리에 있음)를 사용하여 바이트 배열을 방금 보냈다면 지침을 완전히 준수할 것입니다.

이전에 말했듯이 이러한 기존 암호화 라이브러리는 API 표면을 발전시켰고 여러 시나리오에서 전투 테스트를 거쳤습니다. 이 긴 스레드에서 우리가 다룬 것 이상입니다. 다시 한 번 나의 투표는 바퀴를 재발명하려고 시도하기보다 모든 라이브러리, 모든 유효성 검사 및 모든 설치에서 해당 지식과 경험을 활용하는 것입니다. 바퀴를 재발명하지 마십시오. 로켓을 발명하는 데 사용하세요 :)

안녕하세요 여러분,

이에 대한 업데이트가 있습니까? @karelz 의 암호화 로드맵 스레드 또는 AES GCM 스레드 에서 업데이트를 본 적이 없습니다.

감사 해요
시드

따라서 마지막 구체적인 제안은 https://github.com/dotnet/corefx/issues/23629#issuecomment -334328439입니다.

partial class AuthenticatedEncryptor
{
    // throws if an operation is already in progress
    public abstract void Initialize(ReadOnlySpan<byte> associatedData);
    // true on success, false on “destination too small”, exception on anything else.
    public abstract bool TryEncrypt(ReadOnlySpan<byte> data, Span<byte> encryptedData, out int bytesRead, out int bytesWritten);
    // false if remainingEncryptedData is too small, throws if other inputs are too small, see NonceOrIVSizeInBits and TagSizeInBits properties.
    // NonceOrIvUsed could move to Initialize, but then it might be interpreted as an input.
    public abstract bool TryFinish(ReadOnlySpan<byte> remainingData, Span<byte> remainingEncryptedData, out int bytesWritten, Span<byte> tag, Span<byte> nonceOrIvUsed);
}

partial class AuthenticatedDecryptor 
{
    // throws if an operation is already in progress
    public abstract void Initialize(ReadOnlySpan<byte> tag, ReadOnlySpan<byte> nonceOrIv, ReadOnlySpan<byte> associatedData);
    // true on success, false on “destination too small”, exception on anything else.
    public abstract bool TryDecrypt(ReadOnlySpan<byte> data, Span<byte> decryptedData, out int bytesRead, out int bytesWritten);
    // throws on bad tag, but might leak the data anyways.
    // (remainingDecryptedData is required for CBC+HMAC, and so may as well add remainingData, I guess?)
    public abstract bool TryFinish(ReadOnlySpan<byte> remainingData, Span<byte> remainingDecryptedData, out int bytesWritten);
}

이후 몇 가지 잠재적인 문제만 제기되었습니다.

• 태그는 사전에 필요하므로 특정 시나리오를 방해합니다. 더 많은 유연성을 허용하려면 API가 훨씬 더 복잡해져야 합니다. 그렇지 않으면 이 문제를 프로토콜(즉, 상위 수준) 문제로 간주해야 합니다.
• INonceProvider 는 불필요하게 복잡하거나 NIST 및 FIPS 지침을 준수하지 않을 수 있습니다.
• 차이가 너무 클 수 있으므로 인증된 암호화 기본 요소의 의도된 추상화는 꿈일 수 있습니다. 이 제안에 대해 더 이상 논의되지 않았습니다.

다음을 제안하고 싶습니다.

1. 태그를 미리 요구하지 않는 추가 복잡성은 심각해 보이고 해당 문제 시나리오는 드물고 문제는 실제로 프로토콜 문제처럼 들립니다. 좋은 디자인은 많은 것을 수용할 수 있지만 모든 것을 수용할 수는 없습니다. 개인적으로 나는 이것을 프로토콜에 맡기는 것이 편하다. (강력한 반례를 환영합니다.)
2. 논의는 IV 생성을 제외하고 오용으로부터 보호하지 않는 유연하고 낮은 수준의 구현으로 일관되게 이동했습니다. 일관성을 유지합시다. 일반적인 합의는 고수준 API가 중요한 다음 단계이며 대다수 개발자가 적절하게 사용하는 데 필수적이라는 것입니다. 이것이 저수준 API에서 오용을 방지하지 못하는 문제를 해결하는 방법입니다. 그러나 추가적인 두려움이 IV 세대 영역에서 오용 방지라는 아이디어를 유지한 것 같습니다. 저수준 API의 맥락에서 일관성을 유지하기 위해 byte[] -동등한 쪽으로 기울었습니다. 그러나 주입된 INonceProvider 를 사용하면 구현 스와핑이 더 원활해집니다. @sidshetye 의 의견은 반박할 수 없거나 단순히 RNG를 호출하는 간단한 INonceProvider 구현이 여전히 규정을 준수하는 것으로 간주될 수 있습니까?
3. 추상화는 유용해 보이고 설계에 많은 노력을 기울였기 때문에 지금쯤이면 그것들이 해를 끼치기보다 이로움을 더 많이 줄 것이라고 확신합니다. 게다가 높은 수준의 API는 여전히 낮은 수준의 추상화를 따르지 않는 낮은 수준의 API를 구현하도록 선택할 수 있습니다.
4. IV는 일반적인 용어이고 nonce는 IV의 특정 종류입니다. 맞습니까? 이것은 INonceProvider 에서 IIVProvider , nonceOrIv* 에서 iv* $ 로의 이름 변경을 요청합니다. 결국, 우리는 항상 IV를 다루고 있지만 반드시 nonce를 다룰 필요는 없습니다.

태그 선행은 내 시나리오의 시작이 아니므로 아마도 자체 구현을 유지할 것입니다. 괜찮습니다. 이 영역에서 높은 성능의 코드를 작성하는 것이 모든 사람의 차 한잔의 일인지 확신할 수 없습니다.

문제는 불필요한 대기 시간이 발생한다는 것입니다. 프레임 디코딩을 시작하려면 끝에 태그를 가져오려면 전체 메시지를 미리 버퍼링해야 합니다. 이것은 기본적으로 IO와 암호 해독을 겹칠 수 없음을 의미합니다.

마지막에 허용하는 것이 왜 그렇게 어려운지 잘 모르겠습니다. 그러나 나는 이 API에 대한 장애물을 벗어나지 않을 것입니다. 내 시나리오에서는 관심이 없을 것입니다.

IV는 일반적인 용어이고 nonce는 IV의 특정 종류입니다. 맞습니까?

아니요. nonce 는 한 번 사용되는 숫자입니다. nonce를 지정하는 알고리즘은 재사용이 알고리즘의 보장을 위반함을 나타냅니다. GCM의 경우 동일한 키와 다른 메시지로 동일한 논스를 사용하면 GHASH 키가 손상되어 GCM을 CTR로 줄일 수 있습니다.

http://nvlpubs.nist.gov/nistpubs/ir/2013/NIST.IR.7298r2.pdf 에서:

Nonce: 동일한 키로 절대 반복되지 않는 보안 프로토콜에서 사용되는 값. 예를 들어, 챌린지-응답 인증 프로토콜에서 챌린지로 사용되는 nonce는 일반적으로 인증 키가 변경될 때까지 반복되어서는 안 됩니다. 그렇지 않으면 재생 공격의 가능성이 있습니다. nonce를 챌린지로 사용하는 것은 임의 챌린지와 다른 요구 사항입니다. 왜냐하면 nonce가 반드시 예측할 수 없는 것은 아니기 때문입니다.

"IV"에는 동일한 엄격한 요구 사항이 없습니다. 예를 들어, CBC를 사용하여 IV를 반복하면 암호화된 메시지가 동일한 IV를 사용하는 이전 메시지와 같거나 다른지 여부만 누출됩니다. 알고리즘을 약화시키지 않습니다.

nonce는 한 번 사용되는 숫자입니다.
"IV"에는 동일한 엄격한 요구 사항이 없습니다.

@bartonjs 네. nonce가 암호 프리미티브를 초기화 하는 데 사용되기 때문에 초기화 벡터라고 생각합니다. 내가 찾을 수 있는 IV의 정의에 완벽하게 부합합니다. 소가 되는 것이 동물이 되는 것보다 더 엄격한 요구 사항이 있는 것과 마찬가지로 더 엄격한 요구 사항이 있습니다. 현재 문구는 "cowOrAnimal" 매개변수를 요구하는 것 같습니다. 모드마다 IV의 요구 사항이 다르다는 사실은 모두 어떤 형태의 IV를 요구한다는 사실을 변경하지 않습니다. 제가 놓치고 있는 부분이 있다면 현재의 문구를 그대로 유지하되 "iv" 또는 "IIVProvider"만 간단하고 정확합니다.

nonceOrIv 자전거 보관소에 탐닉하려면:

96비트 GCM IV는 때때로 4바이트 salt 및 8바이트 nonce 로 정의됩니다(예: RFC 5288). RFC 4106은 GCM nonce 를 4바이트 salt 및 8바이트 iv 정의합니다. RFC 5084(CMS의 GCM)에 따르면 CCM은 nonce , GCM 은 iv , 그러나 _"... AES-CCM 및 AES-GCM에 대한 공통 용어 집합을 갖습니다. , AES-GCM IV는 이 문서의 나머지 부분에서 nonce라고 합니다."_ RFC 5647(SSH용 GCM)은 _"참고: [RFC5116]에서 IV는 nonce라고 합니다."_ RFC 4543( IPSec의 GCM)은 _"패킷의 IV 필드와 구별하기 위해 AES-GMAC IV 입력을 nonce로 참조합니다."라고 말합니다. RFC 7714(SRTP용 GCM)는 12바이트 IV 이고 거의 일관성을 유지하지만 "_최소 및 최대 논스(IV) 길이: 12 옥텟이어야 합니다."_

대부분의 GCM 사양에서 일관성이 완전히 결여되어 있다는 점을 감안할 때 nonceOrIv 는 다소 의미가 있습니다. $0.02

태그 선행은 시작이 아닙니다.

여기에서 자신을 표명하는 다른 고객과 마찬가지로 태그를 미리 요구하는 것은 우리에게도 쉽지 않은 일입니다. .NET이 이 인위적으로 도입된 제한으로 동시 스트림을 처리할 수 있는 방법은 없습니다. 확장성을 완전히 죽입니다.

복잡성이 추가된다는 주장을 뒷받침할 수 있습니까? 실제로는 사소해야 하기 때문입니다. 또한 플랫폼별 암호화 구현(래핑할)에는 이러한 제한이 없습니다. 구체적으로, 그 이유는 입력 태그가 계산된 태그에 비해 단순히 일정 시간이어야 하기 때문입니다. 그리고 계산된 태그는 TryFinish 동안 최종 블록이 해독된 후에 만 사용할 수 있습니다. 따라서 본질적으로 구현을 시작할 때 TryFinish 까지 인스턴스 내부에 tag 를 저장하고 있다는 것을 알게 될 것입니다. 선택적 입력으로 사용할 수 있습니다.

public abstract bool TryFinish(ReadOnlySpan<byte> remainingData, 
                             Span<byte> remainingDecryptedData, 
                             out int bytesWritten, 
                             ReadOnlySpan<byte> tag = null); // <==

나는 또한 우리가 모든 암호화 시나리오를 다룰 단일 인터페이스로 정규화하기 위해 너무 열심히 노력하고 있다고 생각합니다. 나도 일반화된 인터페이스를 선호하지만 기능이나 확장성을 희생한 적은 없습니다. 특히 언어 자체의 표준 크립토 라이브러리와 같은 기본 계층에서는 더욱 그렇습니다. IMHO, 그렇게 하는 자신을 발견하면 일반적으로 추상화에 결함이 있음을 의미합니다.

단순하고 일관된 인터페이스가 필요한 경우 이전에 여기에서 옵션 1로 제기 된 Java 접근 방식을 선호합니다 . 또한 알고리즘 구현 내에서 태그를 먼저/마지막으로 태그를 지정하는 위의 문제를 회피합니다(IMHO, 그래야 한다고 생각함). 우리 팀은 이것을 구현하지 않기 때문에 우리의 결정은 아니지만 결정을 내리고 구현을 시작해야 한다면 이 길을 확실히 갈 것입니다.

INonce 인터페이스를 피하십시오. 간단한 byte[] 또는 span<> 는 호환되는 로우 레벨 인터페이스에 충분해야 합니다.

IV 대 Nonce - 일반화된 경우는 실제로 IV입니다. GCM의 경우 IV는 Nonce여야 합니다(예: Car vs RedOrCar). 그리고 이것을 복사하여 붙여 넣을 때 @timovzl 이 매우 유사한 예제를 사용했다는 것을 알았습니다. :)

@sidshetye (1) 태그를 미리 필요로 하는 알고리즘을 지원하고 (2) 다른 모든 상황에서 TryFinish 만큼 늦게 태그만 필요하다는 정확한 제안을 할 수 있습니까?

다음과 같은 방향으로 생각하고 있는 것 같은데요?

• Initialize 의 태그는 null이 허용됩니다. 사전에 이를 필요로 하는 알고리즘만 null을 발생시킵니다.
• TryFinish 의 태그는 필수이거나 (또는) 사전에 이미 요구한 알고리즘에 대해 null이 허용됩니다.

위의 내용은 문서화 및 노하우의 형태로 복잡성을 추가한다고 가정합니다. 저수준 API의 경우 적절한 문서와 노하우가 필요하기 때문에 이것은 작은 희생으로 간주될 수 있습니다.

다른 구현 및 스트리밍과의 호환성을 위해 이것이 가능해야 한다고 확신하기 시작했습니다.

@timovzl 물론입니다. 내일 시간을 낼 수 있기를 바랍니다.

@Timovzl , 나는 오늘에서야 시간을 내고 결국 토끼굴이 되었습니다! 길지만 대부분의 사용 사례를 캡처하고 .NET Core/Standard 방향( Span<> )을 수용하면서 .NET 암호화의 장점( ICryptoTransform )을 캡처한다고 생각합니다. 나는 다시 읽었지만 아래에 오타가 없기를 바랍니다. 또한 일부 실시간 커뮤니케이션(채팅, 회의 통화 등)은 신속한 브레인스토밍에 필수적이라고 생각합니다. 나는 당신이 그것을 고려할 수 있기를 바랍니다.

프로그래밍 모델

먼저 API 사용자를 위한 결과 프로그래밍 모델에 대해 이야기하겠습니다.

스트리밍 암호화

var aesGcm = new AesGcm();
using (var encryptor = aesGcm.CreateAuthenticatedEncryptor(Key, IV, AAD))
{
  using (var cryptoOutStream = new CryptoStream(cipherOutStream, encryptor, CryptoStreamMode.Write))
  {
    clearInStream.CopyTo(cryptoOutStream);
  }
}

스트리밍 복호화

var aesGcm = new AesGcm();
using (var decryptor = aesGcm.CreateAuthenticatedDecryptor(Key, IV, AAD))
{
  using (var decryptStream = new CryptoStream(cipherInStream, encryptor, CryptoStreamMode.Write))
  {
    decryptStream.CopyTo(clearOutStream);
  }
}

비 스트리밍

비 스트리밍은 스트리밍의 특별한 경우이므로 위의 사용자 코드를 AuthenticatedSymmetricAlgorithm (아래 정의)의 도우미 메서드로 래핑하여 더 간단한 API를 노출할 수 있습니다. 즉

public class AesGcm : AuthenticatedSymmetricAlgorithm
{
  ...
  // These return only after consuming entire input buffer

  // Code like Streaming Encrypt from above within here
​  public abstract bool TryEncrypt(ReadOnlySpan<byte> clearData, Span<byte> encryptedData);

  // Code like Streaming Decrypt from above within here
  public abstract bool TryDecrypt(ReadOnlySpan<byte> encryptedData, Span<byte> clearData); 
  ...
}

이것은 다음과 같은 더 간단한 API를 제공하는 것으로 두 배가 될 수 있습니다.

비 스트리밍 암호화

var aesGcm = new AesGcm(Key, IV, AAD);
aesGcm.TryEncrypt(clearData, encryptedData);
var tag = aesGcm.Tag;

비 스트리밍 암호 해독

var aesGcm = new AesGcm(Key, IV, AAD);
aesGcm.Tag = tag;
aesGcm.TryDecrypt(encryptedData, clearData);

후드

corefx 소스를 보면 Span<>은 어디에나 있습니다. 여기에는 System.Security.Cryptography.*가 포함됩니다. - 대칭 암호는 예외이므로 첫 번째 및 최상위 계층 인증 암호화를 수정합니다.

1. 스팬 I/O용 ICipherTransform 생성

이것은 ICryptoTransform 의 Span 인식 버전과 같습니다. 나는 프레임워크 업그레이드의 일부로 인터페이스 자체를 변경하지만 사람들이 그것에 대해 민감할 수 있으므로 ICipherTransform 라고 합니다.

public partial interface ICipherTransform : System.IDisposable
{
  bool CanReuseTransform { get; }
  bool CanTransformMultipleBlocks { get; } // multiple blocks in single call?
  bool CanChainBlocks { get; }             // multiple blocks across Transform/TransformFinal
  int InputBlockSize { get; }
  int OutputBlockSize { get; }
  int TransformBlock(ReadOnlySpan<byte> inputBuffer, int inputOffset, int inputCount, Span<byte> outputBuffer, int outputOffset);
  Span<byte> TransformFinalBlock(ReadOnlySpan<byte> inputBuffer, int inputOffset, int inputCount);
}

ICryptoTransform 도 [Obsolete] 로 표시

.NET 암호화에 대한 사전 지식이 있는 사람들에게 예의를 갖추기 위해

[Obsolete("See ICipherTransform")]
public partial interface ICryptoTransform : System.IDisposable { ... }

2. Span I/O를 위한 기존 SymmetricAlgorithm 클래스 확장

public abstract class SymmetricAlgorithm : IDisposable
{
  ...
  public abstract ICipherTransform CreateDecryptor(ReadOnlySpan<byte> Key, ReadOnlySpan<byte> IV);
  public abstract ICipherTransform CreateEncryptor(ReadOnlySpan<byte> Key, ReadOnlySpan<byte> IV);
  public virtual ReadOnlySpan<byte> KeySpan {...}
  public virtual ReadOnlySpan<byte> IVSpan {...}
  public virtual ReadOnlySpan<byte> KeySpan {...}
  ...
}

3. Span I/O를 위해 기존 CryptoStream 확장

이것은 System.Runtime의 Stream 와 같습니다. 또한 AEAD 사례에 따라 대리인을 추가할 예정입니다.

중요: CryptoStream 는 암호화 중에 스트림 끝에 태그를 추가하고 암호 해독 중에 태그(TagSize 바이트)를 자동으로 추출하려면 FlushFinalBlock 에서 필수 업그레이드가 필요합니다 . 이것은 Java의 암호화 아키텍처 또는 C# BouncyCastle과 같은 전투 테스트를 거친 다른 API와 유사합니다. 스트리밍에서 태그가 끝에 생성되지만 암호 해독 중에 최종 블록이 변환될 때까지 필요하지 않기 때문에 이것은 불가피하지만 가장 좋은 위치입니다. 장점은 프로그래밍 모델을 크게 단순화한다는 것입니다.

참고: 1) CBC-HMAC를 사용하면 먼저 태그를 확인하도록 선택할 수 있습니다. 더 안전한 옵션이지만 그렇다면 실제로는 2단계 알고리즘이 됩니다. 첫 번째 패스는 HMAC 태그를 계산하고 두 번째 패스는 실제로 암호 해독을 수행합니다. 따라서 메모리 스트림 또는 네트워크 스트림은 항상 메모리에 버퍼링되어 원샷 모델로 축소되어야 합니다. 스트리밍하지 않습니다. GCM 또는 CCM과 같은 진정한 AEAD 알고리즘은 효율적으로 스트리밍할 수 있습니다.

public class CryptoStream : Stream, IDisposable
{
  ...
  public CryptoStream(Stream stream, IAuthenticatedCipherTransform transform, CryptoStreamMode mode);
  public override int Read(Span<byte> buffer, int offset, int count);
  public override Task<int> ReadAsync(Span<byte> buffer, int offset, int count, CancellationToken cancellationToken);
  public override void Write(ReadOnlySpan<byte> buffer, int offset, int count);
  public override Task WriteAsync(ReadOnlySpan<byte> buffer, int offset, int count, CancellationToken cancellationToken);

  public void FlushFinalBlock()
  {
    ...
    // If IAuthenticatedCipherTransform
    //    If encrypting, `TransformFinalBlock` -> `GetTag` -> append to out stream
    //    If decryption, extract last `TagSize` bytes -> `SetExpectedTag` -> `TransformFinalBlock`
    ...
  }

  ...
}

인증된 암호화의 계층

위와 같이 AEAD(Authenticated Encryption with Associated Data)를 허용하기 위해 누락된 비트를 추가할 수 있습니다.

AEAD에 대한 새로운 ICipherTransform 연장

이렇게 하면 CryptoStream 이 작업을 제대로 수행할 수 있습니다. 또한 IAuthenticatedCipherTransform 인터페이스를 사용하여 자체 사용자 정의 스트리밍 클래스/사용법을 구현할 수 있지만 CryptoStream 로 작업하면 매우 응집력 있고 일관된 .net 암호화 API를 만들 수 있습니다.

  public interface IAuthenticatedCipherTransform : ICipherTransform
  {
    Span<byte> GetTag();
    void SetExpectedTag(Span<byte> tag);
  }

인증된 암호화 기본 클래스

단순히 확장 SymmetricAlgorithm

public abstract class AuthenticatedSymmetricAlgorithm : SymmetricAlgorithm
{
  ...
  // Program Key/IV/AAD via class properties OR CreateAuthenticatedEn/Decryptor() params
  public abstract IAuthenticatedCipherTransform CreateAuthenticatedDecryptor(ReadOnlySpan<byte> Key = default, ReadOnlySpan<byte> IV = default, ReadOnlySpan<byte> AuthenticatedData = default);
  public abstract IAuthenticatedCipherTransform CreateAuthenticatedEncryptor(ReadOnlySpan<byte> Key = default, ReadOnlySpan<byte> IV = default, ReadOnlySpan<byte> AuthenticatedData = default);
  public virtual Span<byte> AuthenticatedData {...}
  public virtual Span<byte> Tag {...}
  public virtual int TagSize {...}
  ...
}

AES GCM 클래스

public class AesGcm : AuthenticatedSymmetricAlgorithm
{
  public AesGcm(ReadOnlySpan<byte> Key = default, ReadOnlySpan<byte> IV = default, ReadOnlySpan<byte> AuthenticatedData = default)

  /* other stuff like valid key sizes etc similar to `System.Security.Cryptography.Aes` */
}

@sidshetye 노력에 박수를 보냅니다.

GCM을 통한 스트리밍 암호화가 가능합니다. GCM을 통한 스트리밍 복호화는

• NIST 800-38d에서는 허용되지 않습니다. 섹션 5.2.2 "인증된 복호화 기능"은 복호화된 평문 P의 반환이 태그 T를 통한 올바른 인증을 의미해야 함을 분명히 합니다.
• 안전하지 않음. "Release of Unverified Plaintext"(RUP) 설정에는 알고리즘이 안전하다는 보안 개념이 있습니다. RUP 보안은 Andreeva-et-al의 2014년 논문에서 공식화되었습니다. GCM은 RUP 설정에서 안전하지 않습니다. 모든 항목을 GCM과 비교하는 CAESAR 경쟁에서는 RUP 보안을 바람직한 속성으로 나열합니다. GCM에서 공개된 검증되지 않은 일반 텍스트는 비트 플리핑 공격에 취약합니다.

이 스레드의 앞부분에서 비대칭 Encrypt/Decrypt API의 가능성이 (개념적으로) 제기되었으며, 저는 그것이 매우 나쁜 생각이 될 것이라는 합의가 있다고 생각합니다.

요약하면, GCM 복호화를 위한 높은 수준의 바이트 세분화된 스트리밍 API를 가질 수 없습니다 . 전에도 여러 번 말했고, 다시 말해요. 스트리밍 API를 사용하는 유일한 방법은 청크 암호화입니다. 청크 암호화에 대한 모든 사람의 회전목마를 절약하겠습니다.

MS가 GCM API에 대해 무엇을 하기로 결정하든 RUP는 허용될 수 없습니다.

@sdrapkin RUP는 여기 에서 자세히 논의되었으며 우리는 이미 그 다리를 건넜습니다. 간단히 말해서, RUP는 복호화된 데이터가 태그가 확인될 때까지 사용될 필요가 없다는 것을 의미하지만 Java JCE, WinNT bcrypt, OpenSSL 등과 같이 메소드 경계에서 시행할 필요가 없습니다. 대부분의 암호화 기본 요소, 특히 낮은 수준의 기본 요소와 마찬가지로 주의해서 사용하십시오.

^^ 너무. 나는 더 높은 수준의 스트림 API 등에 동의하고 그것을 잘 시행합니다. 그러나 저수준 프리미티브를 사용하려면 분할 버퍼 등과 같은 것을 사용할 수 있어야 하며 데이터가 사용되지 않도록 하는 것은 나에게 달려 있습니다. 태그 계산/체크 포인트에서 예외를 발생시키되 낮은 수준의 프리미티브를 햄스트링하지 마십시오.

데이터가 사용되지 않는지 확인하는 것은 나에게 달려 있습니다.

잘못된. 그것은 당신에게 달려 있지 않습니다. AES-GCM은 매우 _특정한_ 정의를 가지고 있으며 그 정의는 그것이 당신에게 달려 있지 않다는 것을 보장합니다. 원하는 것은 별도의 AES-CTR 프리미티브와 별도의 GHASH 프리미티브로, 원하는 대로 결합하고 적용할 수 있습니다. 그러나 우리는 별도의 AES-CTR 및 GHASH 프리미티브에 대해 논의하고 있지 않습니까? 우리는 AES-GCM에 대해 논의하고 있습니다. 그리고 AES-GCM 은 RUP가 허용되지 않도록 요구합니다.

또한 crypto.stackexchange 에서 Ilmari Karonen 의 답변을 검토하는 것이 좋습니다.

@sdrapkin 당신은 좋은 지적을합니다. 그러나 결국에는 RUP에서 안전한 알고리즘을 갖고 여기에서 결정된 API에 해당 알고리즘이 적합하도록 하는 것이 바람직합니다. 따라서 우리는 다음을 선택해야 합니다.

1. API는 스트리밍을 지원하지 않습니다. 간단하지만 저수준 API에는 부족합니다. 우리는 언젠가 이것을 후회할 수도 있습니다.
2. AES-GCM 구현 은 스트리밍을 방지하고 API를 제한하지 않고 사양을 준수합니다.

스트리밍 시나리오를 감지하고 이 사용법이 잘못된 이유를 설명하는 예외를 throw할 수 있습니까? 아니면 스트리밍 구현이 전체 버퍼를 사용하도록 해야 합니까? 후자는 불행할 것입니다. 스트리밍 중이라고 생각할 수도 있지만 그렇지 않습니다.

스트리밍 구현에서 확인하는 SupportsStreaming(out string whyNot) 메서드를 추가할 수 있습니다.

일반적으로 스트리밍/최종 태그에 대한 확고한 주장이 있습니까? 그렇지 않다면 API로 이를 배제하지 않는 것을 목표로 삼아야 한다고 생각합니다.

@sdrapkin : 이것은 응용 프로그램이 아니라 라이브러리이기 때문에 RUP를 더 넓게 볼 수 있습니다. 따라서 이것은 검증되지 않은 데이터의 실제 릴리스/사용보다 버퍼링 및 레이어 설계 문제에 가깝습니다. AES GCM에 대한 NIST 특별 간행물 800-38D를 보면

1. GCM 사양은 최대 일반 텍스트 길이를 2^39-256비트 ~ 64GB로 정의합니다. 시스템 메모리에 가까운 곳에서 버퍼링하는 것은 비합리적입니다.

2. GCM 사양은 태그가 실패하면 출력을 FAIL로 정의했습니다. 그러나 구현의 어떤 레이어가 태그 확인까지 버퍼링해야 하는지에 대한 규정은 없습니다. 다음과 같은 호출 스택을 살펴보겠습니다.

A => AESGCM_Decrypt_App(key, iv, ciphertext, aad, tag)
B =>  +- AESGCM_Decrypt_DotNet(key, iv, ciphertext, aad, tag)
C =>    +- AESGCM_Decrypt_OpenSSL(key, iv, ciphertext, aad, tag)

어디에
A는 애플리케이션 계층에서 AES GCM입니다.
B는 언어 계층에서 AES-GCM입니다.
C는 플랫폼 계층에서 AES-GCM입니다.

태그가 체크아웃되면 일반 텍스트가 (A)에서 해제되지만 그렇지 않으면 FAIL이 반환됩니다. 그러나 사양의 어디에도 주 메모리가 진행 중인 일반 텍스트를 버퍼링할 수 있는 유일한 장소이며 버퍼링이 (B) 또는 (C) 또는 다른 곳에서 발생해야 한다고 제안하지 않습니다. 실제로 OpenSSL, Windows NT Bcrypt(C)의 예에서는 스트리밍이 상위 계층에서 버퍼링을 허용합니다. 그리고 Java JCA, Microsoft의 CLR Security 및 위의 내 제안은 스트리밍이 응용 프로그램 계층에서 버퍼링을 허용하는 (B)의 예입니다. A의 설계자가 일반 텍스트를 릴리스하기 전에 더 나은 버퍼링 기능을 가지고 있지 않다고 가정하는 것은 주제넘은 일입니다. 이론상 및 실제로 해당 버퍼는 메모리, SSD 또는 네트워크의 스토리지 클러스터가 될 수 있습니다. 또는 펀치 카드 ;) !

버퍼링은 제쳐두고도 이 백서는 키 신선도 또는 전력 무기한 오류에 대한 IV 비반복과 같은 다른 실제 문제(섹션 9.1, 설계 고려 사항 및 9.2, 작동 고려 사항 참조)에 대해 논의합니다. 우리는 분명히 이것을 레이어 B, 즉 여기에서 굽지 않을 것입니다.

@timovzl 위의 최근 제안 은 원샷(건축가는 버퍼링에 신경 쓰지 않음)과 스트리밍(건축가는 더 나은 버퍼링 기능을 가짐)의 두 가지 시나리오를 모두 다룹니다. 저수준 스트리밍 API 문서 가 이제 소비자가 버퍼링을 담당한다는 것이 분명하다면 보안 증거의 감소가 없고 사양에서 벗어나는 일도 없습니다.

편집: 문법, 오타 및 마크다운 작동 시도

Bingo .. 여기서도 태그 확인이 발생하는 위치는 레이어 디자이너의 결정입니다. 저는 검증되지 않은 데이터를 애플리케이션 계층에 공개하는 것을 옹호하는 것이 아닙니다.

논의는 이러한 "소비자" 수준 API인지 아니면 진정한 Primitive인지에 대한 것입니다. 그것이 진정한 원시적이라면 상위 수준의 "더 안전한" API가 위에 구축될 수 있도록 기능을 노출해야 합니다. 위에서 Nonce 토론을 통해 이것이 진정한 원시적이어야 한다는 것은 이미 결정되었습니다. 즉, 발에 총을 쏠 수 있음을 의미합니다. 스트리밍/부분 암호문 디코딩에도 동일하게 적용된다고 생각합니다.

즉, "더 높은" 수준과 더 안전한 API를 신속하게 제공하여 사람들이 이들 위에 자신의 것을 "롤링"하는 것을 막는 것이 필수적일 것입니다.

내 관심은 네트워킹/파이프라인에서 비롯되며 부분 버퍼를 수행할 수 없고 "원샷"을 수행해야 하는 경우 이러한 API의 단점에 대한 이점이 없으므로 계속 BCrypt/OpenSsl 등으로 직접 이동합니다.

내 관심은 네트워킹/파이프라인에서 비롯되며 부분 버퍼를 수행할 수 없고 "원샷"을 수행해야 하는 경우 이러한 API의 단점에 대한 이점이 없으므로 계속 BCrypt/OpenSsl 등으로 직접 이동합니다.

정확히. 필요성은 사라지지 않을 것이므로 사람들은 다른 구현을 사용하거나 자체적으로 구현합니다. 좋은 경고 문서로 스트리밍을 허용하는 것보다 반드시 안전한 결과는 아닙니다.

@Timovzl , 나는 우리가 마지막 제안 에 대해 많은 기술적 피드백과 디자인 요구 사항을 이끌어 냈다고 생각합니다. 구현 및 출시에 대한 생각은?

@Sidshetye 는 모든 요구 사항을 해결한다고 생각 하는 자세한 제안 을 했습니다. RUP에 대한 단일 비판은 더 이상의 반대 없이 다루어졌습니다. (특히, RUP는 여러 계층 중 하나에서 방지될 수 있으며 저수준 API는 어느 계층을 지시하지 않아야 하며 스트리밍을 _no_ 제공하면 더 나쁜 영향을 미칠 것으로 예상됩니다.)

진전을 위해 최근 제안에 대해 더 우려하는 사람이 있으면 말씀해 주십시오. 물론 대안도 제시해 주십시오.

저는 이 제안과 API가 구체화되는 것에 대해 열광적입니다.

@Sidshetye , 몇 가지 질문과 제안이 있습니다.

1. 기존 SymmetricAlgorithm 에서 상속받는 것이 바람직합니까? 통합하려는 기존 구성 요소가 있습니까? 그 접근 방식의 장점을 놓치고 있지 않다면 기본 클래스가 없는 AuthenticatedEncryptionAlgorithm 를 보고 싶습니다. 다른 것이 없다면 바람직하지 않은 CreateEncryptor / CreateDecryptor (인증되지 않은!) 메소드가 노출되는 것을 방지합니다.
2. 관련된 구성 요소 중 어느 것도 비대칭 암호화와 함께 사용할 수 없습니다. 예? 거의 모든 구성 요소는 이름에서 "대칭"을 생략합니다. 저도 동의합니다. SymmetricAlgorithm 를 계속 상속하지 않는 한 AuthenticatedSymmetricAlgorithm 는 기존 용어인 인증된 암호화를 준수하여 AuthenticatedEncryptionAlgorithm 로 이름을 변경할 수 있습니다.
3. TryEncrypt / TryDecrypt 를 알고리즘에 설정 가능한 Tag 속성이 있는 대신 태그에 쓰거나 받도록 변경합니다.
4. public setter를 통해 key , iv 및 authenticatedAdditionalData 를 설정하는 목적은 무엇입니까? 여러 유효한 접근 방식과 가능한 한 변경 가능한 속성을 피합니다. 그것들 없이 업데이트된 제안을 만들 수 있습니까?
5. AesGcm 의 상태를 원합니까? 내 본능은 iv 및 authenticatedAdditionalData 가 메시지당이므로 확실히 배제하는 것입니다. key 는 일반적으로 단일 키로 여러 작업을 수행하기를 원하므로 상태로 사용할 가치가 있습니다. 그러나 호출별로 키를 가져오는 것도 가능합니다. CreateAuthenticatorEncryptor 에도 동일한 질문이 적용됩니다. 어쨌든 우리는 매개변수를 전달하기 위해 _단방향_으로 정착해야 합니다. 장점과 단점에 대해 토론하고 싶습니다. 저는 AesGcm 의 키 상태에 기대고 있고 나머지는 각각 CreateAuthenticatedEncryptor 또는 TryEncrypt 에 있습니다. 이미 동의했다면 업데이트된 제안을 보여주세요. :-)
6. ICipherTransform 는 추상 클래스 CipherTransform 여야 기존 구현을 중단하지 않고 메서드를 추가할 수 있습니다.
7. 모든 함수 매개변수는 camelCase를 사용해야 합니다. 즉, 소문자로 시작합니다. 또한 authenticatedData 또는 authenticatedAdditionalData 라고 해야 합니까? 또한 매개변수 이름 plaintext 및 ciphertext 를 선택해야 한다고 생각합니다.
8. IV가 전달되는 곳마다 선택적 매개변수로 표시하여 자체적으로 제공하는 것보다 적절하게 생성된(암호화된) IV를 얻는 것이 더 쉽도록 하고 싶습니다. 최소한 저수준 API의 오용을 더 어렵게 만들고 우리는 이것을 무료로 얻습니다.
9. 나는 여전히 TryEncrypt 의 클라이언트 코드가 ciphertext 를 제공하는 데 필요한 스팬 길이를 알 수 있는 방법을 알아 내려고 노력하고 있습니다! TryDecrypt 및 plaintext 의 길이도 동일합니다. 확실히 우리는 성공할 때까지 루프에서 시도하지 않아야 하며 실패한 반복 후 길이를 두 배로 늘리면 안 될까요?

마지막으로, 이 위에 구축된 고급 API는 어떤 모습일까요? API 사용을 순전히 살펴보면 스트리밍 API와 비스트리밍 API 모두 이미 간단하기 때문에 개선의 여지가 거의 없는 것 같습니다! 내가 상상하는 주요 차이점은 자동 IV, 자동 출력 크기 및 암호화된 데이터 양에 대한 제한입니다.

Windows는 스트리밍을 허용합니다. OpenSSL도 마찬가지입니다. 그 둘은 대부분 기존 개념에 그것을 고정시켰습니다(둘 다 "그리고 이 문제가 옆에 있어 처리해야 하는 부분이 있습니다. 그렇지 않으면 오류가 발생합니다").

Go는 하지 않고 libsodium은 하지 않습니다.

첫 번째 물결은 그것을 허용하고 나중의 물결은 허용하지 않는 것처럼 보입니다. 우리는 틀림없이 나중의 물결에 있기 때문에 그것을 허용하지 않는 것을 고수할 것이라고 생각합니다. 원샷 모델(암호화/복호화에 대해 호출 간에 키를 유지할 수 있음)을 도입한 후 스트리밍 수요가 증가하면 재평가할 수 있습니다. 따라서 해당 패턴을 준수하는 API 제안이 유용해 보입니다. SIV나 CCM 모두 스트리밍 암호화를 지원하지 않지만 이들에 대한 스트리밍 API는 잠재적으로 버퍼링이 심합니다. 사물을 명확하게 유지하는 것이 더 나은 것 같습니다.

제안은 또한 알고리즘 자체(SIV)가 암호화 출력에 태그를 통합하지 않는 한 페이로드에 태그를 포함해서는 안 됩니다(GCM 및 CCM은 이를 별도의 데이터라고 부름). ( E(...) => (c, t) 대 E(...) => c || t 또는 E(...) => t || c ). API 사용자는 확실히 이것을 concat으로 사용할 수 있습니다(Spans를 적절하게 열기만 하면 됨).

GCM 사양은 태그 불일치 시 FAIL 이외 의 릴리스를 허용하지 않습니다. NIST는 이에 대해 매우 명확합니다. McGrew & Viega의 원본 GCM 논문은 다음과 같이 말합니다.

암호 해독 작업은 일반 텍스트가 아닌 FAIL 을 반환하고 캡슐화 해제가 중지되고 일반 텍스트가 전달되거나 추가 처리되지 않고 삭제됩니다.

이전 의견 중 RUP에 대한 언급은 없었습니다. 단지 손을 흔들었을 뿐입니다("상위 계층이 처리할 것입니다." - 예, 맞습니다).

간단합니다. GCM 암호화는 스트리밍할 수 있습니다. GCM 복호화를 스트리밍할 수 없습니다. 다른 모든 것은 더 이상 GCM이 아닙니다.

첫 번째 물결은 그것을 허용하고 나중의 물결은 허용하지 않는 것처럼 보입니다. 우리는 틀림없이 나중의 물결에 있기 때문에 그것을 허용하지 않는 것을 고수할 것이라고 생각합니다.

@bartonjs 말 그대로 모든 기술 및 논리적 분석을 무시하고 대신 Go 및 libsodium 프로젝트의 날짜 를 실제 분석에 대한 약한 프록시로 사용하고 있습니까? 내가 프로젝트의 이름 을 기반으로 비슷한 주장을 한다고 상상해보십시오. 또한 우리는 인터페이스 및 구현을 결정하고 있습니다. AEAD에 대해 비 스트리밍 인터페이스 를 결정하면 이러한 모든 구현 이 차후에 배제된다는 것을 알고 계십니까?

원샷 모델(암호화/복호화에 대해 호출 간에 키를 유지할 수 있음)을 도입한 후 스트리밍 수요가 증가하면 재평가할 수 있습니다.

지금까지 GitHub에서 입증된 수요가 부족한 이유는 무엇입니까? 기술 또는 고객 요구 장점보다 더 적은 작업을 지원하는 것이 완전히 기발한 것처럼 보이는 지점에 도달하고 있습니다.

@bartonjs 말 그대로 모든 기술 및 논리적 분석을 무시하고 대신 Go 및 libsodium 프로젝트의 날짜를 실제 분석에 대한 약한 프록시로 사용하고 있습니까?

아니요, 저는 이것이 매우 위험하며 AEAD 스트리밍을 피해야 한다고 말하는 전문 암호학자의 조언을 사용하고 있습니다. 그런 다음 저는 CNG 팀의 "이론적으로는 많은 사람들이 그것을 원한다고 말하지만 실제로는 거의 아무도 하지 않습니다"라는 CNG 팀의 정보를 사용하고 있습니다. 다른 라이브러리가 일회성 경로를 택했다는 사실은 단순히 결정을 _강화합니다_.

지금까지 GitHub에서 입증된 수요가 부족한 이유는 무엇입니까?

몇 가지 시나리오가 언급되었습니다. 호출자가 데이터 리어셈블리를 수행하도록 하는 대신 API를 복잡하게 만드는 시나리오가 충분하다고 생각되는 경우 조각난 버퍼 처리는 ReadOnlySequence 수락으로 해결할 수 있습니다.

큰 파일이 문제지만 GCM이 64GB에 불과한 컷오프가 있기 때문에 큰 파일은 이미 문제입니다. 예전에). 메모리 매핑된 파일을 사용하면 2GB RAM 없이도 스팬(최대 2^31-1)을 사용할 수 있습니다. 그래서 우리는 최대값에서 몇 비트를 줄였습니다... 어쨌든 시간이 지나면서 일어날 것입니다.

AEAD에 대해 비 스트리밍 인터페이스를 결정하면 이러한 모든 구현이 차후에 배제된다는 것을 알고 계십니까?

나는 아마도 합리적인 통합 인터페이스가 없을 것이라고 @GrabYourPitchforks 가 옳았다고 점점 더 확신합니다(https://github.com/dotnet/corefx/issues/23629#issuecomment-334638891). GCM _requireing_ nonce/IV 및 SIV _forbidding_ 이는 AEAD 모드/알고리즘의 초기화가 무슨 일이 일어날지에 대한 지식이 이미 필요하다는 것을 의미합니다... 실제로 AEAD에 대한 "추상화된" 개념은 없습니다. SIV는 "태그"의 위치를 ​​지정합니다. GCM/CCM은 그렇지 않습니다. SIV는 사양에 따라 태그 우선입니다.

SIV는 모든 데이터를 가질 때까지 암호화를 시작할 수 없습니다. 따라서 스트리밍 암호화는 throw(이는 호출하지 않으려면 알아야 함) 또는 버퍼(n^2 작업 시간이 발생할 수 있음)를 발생시킵니다. 길이를 알 때까지 CCM을 시작할 수 없습니다. 그러나 CNG는 길이에 대한 사전 암호화 힌트를 허용하지 않으므로 동일한 보트에 있습니다.

기본적으로 옳은 일보다 잘못된 일을 하는 것이 더 쉬운 새 구성 요소를 설계해서는 안 됩니다. 스트리밍 암호 해독을 사용하면 태그가 확인되기 전에 데이터 유효성 검사 버그를 매우 쉽게 얻을 수 있는 Stream 클래스(CryptoStream을 사용하여 그렇게 하려는 제안)를 연결하는 것이 매우 쉽고 유혹적입니다. 이는 AE의 이점을 거의 완전히 무효화합니다. . ( IGcmDecryptor => CryptoStream => StreamReader => XmlReader => "잠깐, 그건 합법적인 XML이 아닙니다..." => 적응형 암호문 오라클) .

그것은 요점에 도달하고 있습니다 ... 고객 요구.

불행히도 내 인생에서 너무 많이 들었습니다. 미안하지만 당신은 우리가 생각하는 고객이 아닙니다. GCM을 안전하게 수행하는 방법을 알고 있음을 인정합니다. 태그 확인이 끝날 때까지 휘발성 파일/버퍼/등으로만 스트리밍하는 것을 알고 있습니다. 넌스 관리가 무엇을 의미하는지 알고 있고 잘못될 위험도 알고 있습니다. 스트림 크기에 주의를 기울이고 2^36-64바이트 후에 새 GCM 세그먼트로 잘라야 한다는 것을 알고 있습니다. 당신은 모든 것을 말하고 완료한 후에 당신이 그 일을 잘못 이해하는 것은 당신의 버그라는 것을 알고 있습니다.

반면에 내가 염두에 두고 있는 고객은 상사가 지시했기 때문에 "암호화해야 함"을 알고 있는 사람입니다. 그리고 그들은 암호화 방법을 검색할 때 일부 튜토리얼에서 "항상 AE 사용"이라고 말하고 GCM을 언급한다는 것을 알고 있습니다. 그런 다음 그들은 CryptoStream을 사용하는 ".NET의 암호화" 자습서를 찾습니다. 그런 다음 그들은 SSLv2를 선택한 것과 동일한 작업을 수행했다는 사실을 전혀 모르고 파이프라인을 연결합니다. 이론상으로는 확인란을 선택했지만 실제로는 그렇지 않습니다. 그리고 그들이 그것을 할 때 _그_ 버그는 더 잘 알고 있는 모든 사람의 것이지만 잘못된 일은 너무 쉽게 하도록 내버려 두십시오.

당신은 우리가 생각하는 고객이 아닙니다 [...] 반면에 내가 생각하는 고객은 상사가 [...]

@bartonjs 몇 달 전에 우리는 목표가 낮은 수준의 API(강력하지만 특정 조건에서는 안전하지 않음)와 높은 수준의 API(완벽한)를 사용하여 두 고객 프로필을 대상으로 지정하는 것이라고 이미 결정했습니다. 제목에도 있습니다. 그것은 확실히 자유 국가이지만, 이제 다른 주장을 하여 골대를 옮기는 것은 정직하지 않습니다.

반면에 내가 염두에 두고 있는 고객은 상사가 지시했기 때문에 "암호화해야 함"을 알고 있는 사람입니다. 그리고 그들은 암호화 방법을 검색할 때 일부 튜토리얼에서 "항상 AE 사용"이라고 말하고 GCM을 언급한다는 것을 알고 있습니다. 그런 다음 그들은 CryptoStream을 사용하는 ".NET의 암호화" 자습서를 찾습니다. 그런 다음 그들은 SSLv2를 선택한 것과 동일한 작업을 수행했다는 사실을 전혀 모르고 파이프라인을 연결합니다. 이론상으로는 확인란을 선택했지만 실제로는 그렇지 않습니다. 그리고 그들이 그것을 할 때 그 버그는 더 잘 아는 모든 사람에게 속하지만 잘못된 일은 너무 쉽게 하도록 내버려 두십시오.

@bartonjs 잠깐, 저수준 프리미티브는 어떻게 되었나요? 나는 이 특별한 문제의 목적이 육아에 대한 유연성이라고 생각했습니다. 계획이 변경된 경우 반드시 알려주십시오. 그래서 우리는 모두 같은 것에 대해 이야기하고 있습니다.

또한 블록별 방식이 아직 고려 중입니까, 아니면 원샷 방식인가요?

나는 아마도 합리적인 통합 인터페이스가 없을 것이라고 @GrabYourPitchforks 가 옳았다는 것을 점점 더 확신합니다(#23629 (comment)).

모든 예를 보면 이것은 점점 더 무익해 보이기 시작합니다. 특히 구현에 서로 다른 제한이 있는 저수준 API의 경우에는 더욱 그렇습니다. 인터페이스를 통합하기보다는 AES-GCM으로 확실한 예를 설정해야 할 것입니다. 참고로 후자는 미래의 고급 API에 여전히 흥미로울 수 있습니다. 더 제한적이라는 속성으로 인해 통합 인터페이스를 훨씬 쉽게 달성할 수 있습니다.

블록별 방법이 아직 고려 중입니까, 아니면 원샷 방법입니까?

https://github.com/dotnet/corefx/issues/23629#issuecomment -378605071에서 언급했듯이 위험 대 보상 대 표현된 사용 사례에서 AE의 원샷 버전만 허용해야 한다고 생각합니다.

나는 전체 토론을 읽지 않았고 임의의 부분만 읽었습니다. 어떤 방향으로 가고 있는지 모르겠습니다. 제가 쓴 글이 이 맥락에서 이해가 되지 않는다면 죄송합니다. 내 2¢:

• 스트림이 중요합니다. 보안 취약성을 의미하므로 직접 지원할 수 없는 경우 가능하면 스트림을 노출하는 저수준 API 위에 구축된 고수준 래퍼를 제공하십시오(비효율적이지만 안전한 방법으로).
• AES-GCM이 어떤 시나리오에서도 스트림을 절대 사용할 수 없는 경우 스트림을 기반으로 하는 AES-CBC-HMAC의 합법적인 구현을 제공하십시오. 또는 다른 AE 알고리즘.
• 레벨이 높을수록 좋습니다. 사용자가 실수할 영역이 적을수록 좋습니다. 의미 — 가능한 한 많은 것을 숨기는 API를 노출합니다(예: 이 인증 태그). 물론 더 구체적인 오버로드도 있을 수 있습니다(해야 합니다).
• IMHO는 단순히 적합하지 않은 경우 다른 암호화 서비스와 인터페이스를 통합하는 데 신경 쓰지 않습니다. 이것이 openssl이 CLI로 수행한 작업이며 결과가 좋지 않습니다(예: 인증 태그를 제공할 가능성 없음).

우리(.NET 보안 팀)는 우리와 Microsoft 내의 광범위한 암호화 팀과 의논했습니다. 우리는 이 스레드에서 언급된 많은 문제와 우려 사항에 대해 논의했습니다. 궁극적으로 이러한 우려는 스트리밍 GCM API를 프레임워크 내의 핵심 빌딩 블록으로 도입하는 것을 보증할 만큼 설득력이 없었습니다.

이 결정은 향후 필요할 경우 재검토될 수 있습니다. 그 동안 우리는 현재보다 상황을 더 악화시키지 않았습니다. 현재 스트리밍 GCM 지원을 위해 타사 암호화 라이브러리를 사용하고 있는 개발자는 계속 그렇게 할 수 있으며 의도한 도입으로 인해 중단되지 않을 것입니다. 비 스트리밍 GCM API.

메모리에 맞지 않는 데이터 암호화를 처리하는 방법은 무엇입니까?

@pgolebiowski 안전한 스트리밍 암호화를 제공하도록 특별히 설계된 고급 .NET 암호화 라이브러리 를 사용합니다.

@sdrapkin 이것은 말보다 쉽습니다. "안전하다"는 질문이 많습니다. 입증되고 실제로 신뢰할 수 있는 것은 무엇입니까? 당신은 자신에게 말합니다 :

Bouncy Castle C# 라이브러리(일반적인 StackOverflow 권장 사항). Bouncy Castle c#은 거대한(145k LOC) 성능이 저조한 크립토 박물관 카탈로그(일부는 고대)로, 오래된 Java 구현이 동등하게 오래된 .NET(2.0?)으로 이식되었습니다.

좋아, 그래서 옵션은 무엇입니까? 어쩌면 당신의 도서관? 아니 정말 . 흠... 아마도 libsodium-net? 아니 정말 .

오히려 신뢰할 수 있는 소스(예: Microsoft 또는 커뮤니티에서 광범위하게 사용)에서 제공되는 감사 라이브러리를 실제로 찾을 때 .NET Core 세계에 그러한 라이브러리가 존재하지 않는다고 생각합니다.

• 고객: 메모리에 맞지 않는 데이터의 인증된 암호화?
• microsoft: 죄송합니다. 하지만 당신은 우리가 생각하는 고객이 아닙니다. 감사되지 않고 안전성이 의심되는 라이브러리를 사용하십시오. 부채널 공격을 받는 경우 문제가 아닙니다.
• 고객:

@pgolebiowski 옵션은 확립된 .NET 프레임워크를 사용하는 것입니다. 당신이 원하는 대로 입증되었고 신뢰할 수 있는 바로 그 것. 다른 라이브러리(내 라이브러리 포함)는 Microsoft가 ECDH와 같은 누락된 암호화 기본 요소를 NetStandard에 추가하기를 기다립니다.

Inferno 포크 도 볼 수 있습니다. 몇 가지 사소한 변경으로 NetStandard20을 달성한 포크가 2개 이상 있습니다.

귀하의 라이브러리는 2년 전에 한 사람 에 의해 2일 이내에 감사되었습니다. 나는 그것을 믿지 않습니다, 죄송합니다. Microsoft에는 이를 위한 전담 팀이 있습니다. 저는 Cure53의 사람들보다 더 신뢰하는 사람들로 구성되어 있습니다.

진지하게, 우리는 많은 것에 대한 제3자 지원에 대해 이야기할 수 있습니다. 그러나 필요한 모든 보안 관련 항목은 표준 라이브러리에서 제공해야 합니다.

@pgolebiowski 누군가에게 무엇이든 믿으라고 설득하는 것은 제가 할 수 있는 일이지만 귀하의 진술은 정확하지 않습니다. Inferno는 "Cure53" 조직의 2명의 전문가가 감사했습니다. 감사는 2일이 걸렸고 전체 라이브러리는 ~1,000라인의 코드였습니다. 하루에 감사자당 ~250줄의 코드로 관리할 수 있습니다.

사실, 손쉬운 감사 기능은 Inferno의 주요 기능 중 하나입니다. 정확히는 신뢰하고 싶지 않은 사람들을 위한 것입니다.

이 스레드의 목표는 AES-GCM에 대한 지원을 추가하는 것입니다. 귀하의 라이브러리는 AES-GCM도 지원하지 않습니다. 사람들이 귀하의 코드를 사용하도록 하려면 corefx에 대한 제안으로 제출하십시오. 적절한 스레드에서.

또 다른 점은 이 알고리즘을 지원하더라도 .net 암호화 위원회에서 검토하지 않았으며 corefx의 일부가 아니라는 것입니다. 그러한 검토를 위한 후보조차 아닙니다. 이것은 이 헛된 토론과 광고의 끝을 의미합니다.

@pgolebiowski 나는 아무 것도 광고하지 않았습니다. 단지 귀하의 질문에 답변하고, 귀하의 사용 사례에 대한 대안을 제안하고, 부정확한 주장을 수정했을 뿐입니다. AES-GCM은 스트리밍 암호화에 적합하지 않으며, 이는 .NET 보안 팀에서 검토 및 동의한 사항 이므로 신뢰할 수 있습니다.

어디에서나 스트리밍 AES-GCM을 방어하고 있습니까? 기억할 수 없습니다. 그러나 다음과 같은 말을 기억할 수 있습니다.

• 스트림이 중요합니다. 보안 취약성을 의미하므로 직접 지원할 수 없는 경우 가능하면 스트림을 노출하는 저수준 API 위에 구축된 고수준 래퍼를 제공하십시오(비효율적이지만 안전한 방법으로).
• AES-GCM이 어떤 시나리오에서도 스트림을 절대 사용할 수 없는 경우 스트림을 기반으로 하는 AES-CBC-HMAC의 합법적인 구현을 제공하십시오. 또는 다른 AE 알고리즘.

또는 corefx에 대한 미해결 문제 언급:

메모리에 맞지 않는 데이터 암호화를 처리하는 방법은 무엇입니까?

보너스:

Inferno 포크도 볼 수 있습니다. 몇 가지 사소한 변경으로 NetStandard20을 달성한 포크가 2개 이상 있습니다. [...] Inferno는 "Cure53" 조직의 2명의 전문가가 감사했습니다. [...] 간편한 감사 기능은 Inferno의 주요 기능 중 하나입니다.

나는 아무것도 광고하지 않았다

제쳐두고 나는 대부분의 사람들이 생각하는 의미에서 "스트리밍"을 정말로 원하지 않았습니다. 성능 및 메모리 사용상의 이유로 "차단" 처리를 원했습니다. 나는 실제로 결과를 "스트리밍"하고 싶지 않습니다. 이것이 openssl 및 cng 지원이 그것을 잃는 것이 부끄럽고 기본적으로 내가 생각할 수있는 모든 시나리오에서 "원시"를 쓸모 없게 만드는 것입니다.

@Drawaes 생각해보면 블록 작업이 스트림을 사용하는 것보다 훨씬 안전할 수 있습니다. 평신도는 스트림을 만질 수 있지만 블록 작업보다 원샷 API를 훨씬 더 많이 사용합니다. 게다가 블록 작업은 XmlReader 와 _직접적으로_ 결합될 수 없습니다. 따라서 실제로 논의된 많은 위험은 스트림 개체에 적용되지만 블록 작업에는 적용되지 않습니다.

원샷 API도 사용할 수 있을 때 블록 작업을 수행하려면 우리가 하는 일을 알고 있으며 특히 낮은 수준의 조정이 필요하다고 제안합니다. 우리는 평신도를 보호할 수 있고 _그리고_ 유연성을 가질 수 있습니다.

RUP를 피하는 것과 관련하여, 나는 여전히 GCM에 대한 이점 차단 작업이 얼마나 많은지 숙고하고 있습니다. 암호화는 모든 이점을 얻는 반면 복호화는 약간만 이점을 얻습니다. 전체 암호문을 저장하는 것을 피할 수 있지만 여전히 전체 평문을 버퍼링해야 합니다. 암호 해독기는 디스크에 중간 일반 텍스트를 저장하도록 _선택할 수 있습니다. 그러나 그 대가로 우리는 더 많은 오류의 여지를 도입했습니다. 더 높은 수준에서 이 문제를 해결하지 말라는 설득력 있는 주장이 있습니까(예: 청크 또는 진정한 스트리밍 알고리즘 사용)?

TLS 및 파이프라인. 현재(그리고 예측 가능한 미래에) 파이프라인은 4k 블록을 사용하지만 tls 메시지는 16k의 암호문일 수 있습니다. 한 번에 16k를 단일 연속 버퍼에 복사해야 해독할 수 있습니다. 블록을 사용하면 4 또는 5라고 말할 수 있으며 블록 경쟁을 위해 최대 16바이트를 버퍼링해야 할 수도 있습니다.

@Drawaes 16k는 여전히 일정하고 거대하지 않습니다. 이 맥락에서 많은 차이가 있습니까?

예, 파이프라인의 다른 사본을 의미합니다. 이것은 성능에 중요하고 측정 가능한 영향을 미칩니다.

이렇게 하려면 무엇이 필요합니까? 다음 단계는 무엇입니까? @드로웨스

AES-GCM의 경우 https://github.com/dotnet/corefx/issues/7023에서 해당 문제가 잠겨 있어 전달이 제대로 되지 않는 것 같습니다. @blowdart , 잠금을 해제할 수 있습니까? 사람들이 토론할 수 없을 때 발전하기는 정말 어렵습니다. 또는 그것이 옵션이 아닌 경우 이 기능을 대중에게 제공할 수 있는 대체 솔루션을 제안할 수 있습니다.

아니요, 잠금을 해제하지 않습니다. 결정이 내려졌고 주제가 끝났습니다.

@blowdart 답변 감사합니다. 아마도 이것이 충분히 명확하지 않다는 것을 이해합니다.

또는 그것이 옵션이 아닌 경우 이 기능을 대중에게 제공할 수 있는 대체 솔루션을 제안할 수 있습니다.

AES-GCM을 지원하기로 결정한 것에 대해 감사드립니다. 훌륭합니다. 저는 확실히 그 알고리즘을 원합니다. 따라서 이제 실제로 지원하는 것이 좋습니다. AES-GCM 설계 및 구현에 대한 토론이 여기에서 열리기를 원하십니까 아니면 새로운 호에서 열리기를 원하십니까?

또한 해당 주제가 완료되면 왜 닫지 않습니까? 그리고 지금 당장 구현에 대한 논의가 https://github.com/dotnet/corefx/issues/7023에서 열릴 것이라고 제안하므로 해당 문제의 제목을 변경하여 더 명확하게 만드십시오. 어떤 AEAD 알고리즘을 먼저 지원할 것인지 결정하는 것과 같은 것일 수 있습니다.

즉, 현재 상황에서 AES-GCM을 추진하기 위해 무엇이 필요한지 불분명하다는 피드백을 제공합니다.

@karelz

@pgolebiowski 이미 PR이 나왔어요. 다음주 마스터 수요일에 가능할 것 같습니다.