प्रस्तावित एपीआई पर त्वरित-से-न्यायाधीश प्रतिक्रिया (सहायक होने की कोशिश):

• Span<T> NetStandard2 में नहीं है।
• "नॉन" बहुत कार्यान्वयन-विशिष्ट है - यानी। जीसीएम की गंध। हालांकि, यहां तक ​​कि GCM दस्तावेज़ (उदा. NIST SP800-38D) भी इसे "IV" के रूप में संदर्भित करते हैं, जो - GCM के मामले में - एक गैर होता है। हालांकि, अन्य एईएडी कार्यान्वयनों के मामले में IV को गैर नहीं होना चाहिए (उदा। CBC+HMAC के तहत IV को दोहराना विनाशकारी नहीं है)।
• स्ट्रीमिंग एईएडी को या तो क्रिप्टोस्ट्रीम के साथ निर्बाध रूप से काम करना चाहिए, या अपना स्वयं का "एईएडीक्रिप्टोस्ट्रीम" प्रदान करना चाहिए जो क्रिप्टोस्ट्रीम के रूप में स्ट्रीम करना / बाहर करना आसान है।
• एईएडी एपीआई कार्यान्वयन को एएडी (एसोसिएटेड डेटा) के आधार पर आंतरिक कुंजी व्युत्पत्ति करने की अनुमति दी जानी चाहिए। टैग गणना/सत्यापन के लिए विशुद्ध रूप से AAD का उपयोग करना बहुत प्रतिबंधात्मक है और एक मजबूत AEAD मॉडल को रोकता है।
• "प्राप्त करें *" विधियों को कुछ वापस करना चाहिए (गेटटैग)। यदि वे शून्य हैं, तो वे अवश्य ही कुछ स्थापित कर रहे होंगे/स्थिति बदल रहे होंगे।
• "फिनिशिंग" से पहले एक टैग प्राप्त करने का प्रयास करना शायद एक बुरा विचार है, इसलिए "IsFinished" मददगार हो सकता है।
• जिन लोगों ने ICryptoTransform को डिज़ाइन किया है, उन्होंने पुन: उपयोग, बहु-ब्लॉक समर्थन और अलग-अलग आकार के इनपुट/आउटपुट ब्लॉक आकारों के बारे में सोचा। इन चिंताओं पर कब्जा नहीं किया जाता है।

एईएडी एपीआई विवेक के प्रमाण के रूप में, इस तरह के प्रस्तावित एपीआई का पहला कार्यान्वयन एईएस-जीसीएम नहीं होना चाहिए, बल्कि एचएमएसी टैग के साथ क्लासिक/डिफ़ॉल्ट एईएस-सीबीसी होना चाहिए। इसका सरल कारण यह है कि कोई भी व्यक्ति आज सरल, मौजूदा, प्रसिद्ध .NET कक्षाओं के साथ AES-CBC+HMAC AEAD कार्यान्वयन का निर्माण कर सकता है। आइए पहले एक उबाऊ पुराने [AES-CBC+HMAC] को नए AEAD API पर काम करें, क्योंकि यह सभी के लिए MVP और टेस्ट-ड्राइव के लिए आसान है।

गैर/चतुर्थ नामकरण मुद्दा कुछ ऐसा था जिसके बारे में मैं अनिश्चित था, IV में बदलाव से खुश हूं इसलिए बदल जाएगा।

कुछ वापस करने के तरीकों के लिए, यह किसी भी आवंटन से बचाता है। एक अधिभार Get() हो सकता है जो कुछ देता है। हो सकता है कि इसे नामकरण परिवर्तन की आवश्यकता हो, लेकिन मैं इस विचार से काफी विवाहित हूं कि पूरे एपीआई को मूल रूप से आवंटन मुक्त होना चाहिए।

धाराओं आदि के लिए, मुझे इससे अत्यधिक परेशान नहीं है क्योंकि वे उच्च स्तरीय एपीआई हैं जिन्हें आसानी से निचले स्तर के प्राइमेटिव से बनाया जा सकता है।

आपके समाप्त होने से पहले एक टैग प्राप्त करने की अनुमति नहीं दी जानी चाहिए, हालांकि आपको पता होना चाहिए कि आपने कब फिनिश कहा है, इसलिए मुझे यकीन नहीं है कि यह एपीआई में होना चाहिए, हालांकि यह एक परिभाषित व्यवहार होना चाहिए इसलिए मैंने एपीआई डिज़ाइन को शामिल करने के लिए अपडेट किया है एक व्यवहार खंड ताकि हम किसी भी अन्य को पकड़ सकें जिनके बारे में सोचा जाता है।

किस सिफर के लिए, मुझे नहीं लगता कि कोई विशिष्ट सिफर एकमात्र लक्ष्य होना चाहिए, एक नया सामान्य प्रयोजन एपीआई साबित करने के लिए इसे एक संख्या में फिट करने की आवश्यकता है। एईएस जीसीएम और सीबीसी दोनों को कवर किया जाना चाहिए।

(सभी विषय पर फीडबैक अच्छा या बुरा हमेशा मददगार होता है!)

• कक्षा, या इंटरफ़ेस?
• कैसे, यदि बिल्कुल भी, वर्तमान सममित एल्गोरिथम वर्ग इसके साथ परस्पर क्रिया करते हैं?
• इसका उपयोग लगातार कुंजियों के लिए कैसे किया जाएगा, जैसे ट्रिपलडीईएससीएनजी और एईएससीएनजी कर सकते हैं?
• इनमें से कई स्पैन ऐसा लगता है कि वे रीडऑनलीस्पैन हो सकते हैं।

@Drawaes इस एपीआई पर गेंद को घुमाने के लिए धन्यवाद। कुछ विचार:

1. टैग निर्माण और सत्यापन इस एपीआई का एक बहुत ही महत्वपूर्ण हिस्सा है क्योंकि टैग का दुरुपयोग पूरे उद्देश्य को विफल कर सकता है। यदि संभव हो, तो मैं यह सुनिश्चित करने के लिए इनिशियलाइज़ और फिनिश ऑपरेशंस में निर्मित टैग देखना चाहूंगा कि उन्हें गलती से अनदेखा नहीं किया जा सकता है। इसका तात्पर्य यह है कि एन्क्रिप्ट और डिक्रिप्ट को समान प्रारंभिक और अंतिम विधियों का उपयोग नहीं करना चाहिए।
2. अंत तक पहुंचने से पहले डिक्रिप्शन के दौरान आउटपुट ब्लॉक के बारे में मेरी मिश्रित भावनाएं हैं क्योंकि टैग की जांच होने तक डेटा भरोसेमंद नहीं है (जो तब तक नहीं किया जा सकता जब तक कि सभी डेटा संसाधित नहीं हो जाते)। हमें उस ट्रेडऑफ़ का बहुत सावधानी से मूल्यांकन करना होगा।
3. क्या रीसेट करना आवश्यक है? समाप्त करना चाहिए बस रीसेट? हम वृद्धिशील हैश पर ऐसा करते हैं (लेकिन उन्हें नए IVs की आवश्यकता नहीं है)

@bartonjs

1. क्लास, जैसा कि अक्सर बीसीएल में एक इंटरफ़ेस के साथ देखा गया है, आप बाद में सब कुछ तोड़े बिना इसका विस्तार नहीं कर सकते। एक इंटरफ़ेस जीवन के लिए एक पिल्ला की तरह है ... जब तक कि डिफ़ॉल्ट इंटरफ़ेस विधियों को उस समस्या के समाधान के रूप में नहीं माना जा सकता है।
   इसके अलावा एक अमूर्त प्रकार से एक सीलबंद वर्ग वास्तव में तेज़ है (अभी तक) क्योंकि जिट अब विधियों को विचलित कर सकता है ... तो यह मूल रूप से मुफ़्त है। इंटरफ़ेस प्रेषण उतना अच्छा नहीं है (अभी भी अच्छा है उतना अच्छा नहीं है)
2. मुझे नहीं पता कि आप इसे कैसे काम करना चाहेंगे? मुझे वर्तमान सामान में बहुत कम दिलचस्पी है क्योंकि यह इतना भ्रमित करने वाला है कि मैं सभी उचित आधुनिक एल्गो को सीधे पैच कर दूंगा (अन्य वर्गों में 3DES छोड़ दें :) लेकिन मेरे पास सभी उत्तर नहीं हैं तो क्या आपके पास इस पर कोई और विचार है?
3. स्थायी कुंजी आसान होनी चाहिए। कुंजी विधि या दृढ़ता स्टोर पर एक विस्तार विधि बनाएं।

MyKeyStore.GetCipher();

इसे इनिशियलाइज़ नहीं किया गया है। यह डिस्पोजेबल है इसलिए किसी भी रेफरी को सामान्य डिस्पोजेबल पैटर्न द्वारा छोड़ा जा सकता है। यदि वे कुंजी सेट करने का प्रयास करते हैं तो एक अमान्य ऑपरेशन अपवाद फेंक दें।

हाँ केवल-पढ़ने के लिए जब मैं अपने फोन पर ट्यूब पर नहीं हूं तो मैं समायोजित करूंगा।

@morganbr कोई समस्या नहीं ... मैं बस यह देखना चाहता हूं कि यह किसी भी चीज़ से अधिक हो;)

1. क्या आप एक कोड स्निपेट दे सकते हैं कि आप इसे कैसे काम करते हुए देखते हैं? सुनिश्चित नहीं है कि यह करता है लेकिन कोड हमेशा स्पष्टता लाता है
2. यह दुर्भाग्यपूर्ण है लेकिन आपको वास्तव में ब्लॉकों को जल्दी से बाहर निकालना होगा। एचएमएसी और हैशिंग के साथ आप नहीं करते हैं, लेकिन आपके पास केवल राज्य का अंतरिम डेटा नहीं है। तो इस मामले में आपको अज्ञात मात्रा में डेटा बफर करना होगा। आइए पाइपलाइन उदाहरण और टीएलएस पर एक नज़र डालें। हम 16k प्लेनटेक्स्ट लिख सकते हैं लेकिन पाइपलाइन बफ़र्स आज 4k पेज के आकार के हैं। इसलिए हम सबसे अच्छा 4*4k एन्क्रिप्ट/डिक्रिप्ट करना चाहेंगे। आप में से अंत तक मुझे जवाब नहीं देते हैं, आपको उन सभी को स्टोर करने के लिए आंतरिक मेमोरी आवंटित करने की आवश्यकता होती है और फिर मुझे लगता है कि जब मुझे परिणाम मिलता है तो मैं इसे फेंक देता हूं? या मिटा दोगे। क्या होगा अगर मैं 10mb डिक्रिप्ट करता हूं और आप उस मेमोरी को पकड़ते हैं, जब मुझे अब गुप्त मेमोरी के उपयोग के बारे में चिंता करने की आवश्यकता होती है।
3. इनिट/रीसेट चीज़ पर 100% नहीं (आपके विचार नहीं, मेरा वर्तमान एपीआई आकार) यह मेरे साथ अच्छी तरह से नहीं बैठता है इसलिए मैं एक नए सुझाव के लिए खुला हूं!

मुझे वर्तमान सामान में बहुत कम दिलचस्पी है क्योंकि यह इतना भ्रमित करने वाला है कि मैं सीधे सभी उचित आधुनिक एल्गो को पैच कर दूंगा (अन्य वर्गों में 3 डीईएस छोड़ दें :)

समस्या यह होगी कि कंटेनर प्रारूप जैसे लिफाफा (या EncryptedXml) को 3DES-CBC, AES-CBC, आदि के साथ काम करने की आवश्यकता हो सकती है। कोई व्यक्ति ECIES/AES-256-CBC-PKCS7/HMAC-SHA-2 के साथ एन्क्रिप्टेड कुछ को डिक्रिप्ट करना चाहता है। -256 को शायद यह नहीं लगेगा कि वे पुरानी और टेढ़ी-मेढ़ी बातें कर रहे हैं।

अगर यह केवल AE के लिए होना चाहिए, तो वह नाम में कहीं परिलक्षित होना चाहिए। अभी यह सामान्य "सिफर" है (जो मैं था/है, किसी बिंदु पर, एक शब्दकोश/शब्दावली के साथ बैठने जा रहा हूं और पता लगा सकता हूं कि "ऑपरेशन के एक मोड में एक एन्क्रिप्शन एल्गोरिदम" के लिए कोई शब्द है या नहीं, क्योंकि मुझे लगता है कि "सिफर" == "एल्गोरिदम", इसलिए "एईएस")।

:) मैं केवल यह इंगित कर रहा था कि यह मेरा विषय क्षेत्र नहीं है या मेरे लिए बहुत रुचि नहीं है इसलिए मैं इस विषय पर आपके और समुदाय को स्थगित करने के लिए तैयार हूं, मैंने इसके प्रभावों के बारे में नहीं सोचा है।

इनके माध्यम से त्वरित रूप से स्कैन करने के बाद, एक विकल्प उन्हें "सिफर" या जो कुछ भी इसे कक्षा कहा जाता है उसका एक उदाहरण लेने की अनुमति देता है। यह पहली लहर में नहीं किया जा सकता है, लेकिन जल्दी से इसका पालन कर सकता है। यदि एपीआई सुपर कुशल है तो मुझे कोई कारण नहीं दिखता कि उन्हें आंतरिक रूप से अपना काम करना चाहिए और वास्तव में इस एपीआई के लिए उपयोग का मामला है।

नामकरण पर एक साइड बार के रूप में ... मुझे यह स्वीकार करना चाहिए कि यह कठिन है
Openssl = सिफर
रूबी = सिफर
गो = AEAD आदि के लिए डकटाइप्ड इंटरफेस के साथ सिफर पैकेज
जावा = सिफर

अब मैं अलग होने के लिए हूं लेकिन... एक चलन है। अगर कुछ बेहतर संभव है तो अच्छा है।

शायद "ब्लॉकमोड सिफर" ...?

मैंने कुछ बदलाव किए हैं, अगर कोई बेहतर नाम तय किया जाता है तो मैं नामकरण बदल दूंगा।

जब मैंने सवालों के जवाब देने की कोशिश करना शुरू किया, तो मुझे एहसास हुआ कि एपीआई में पहले से ही एन्क्रिप्शन/डिक्रिप्शन भेदभाव गायब है, इसलिए आपके उदाहरण में, यह नहीं जानता कि डेटा एन्क्रिप्ट या डिक्रिप्ट करना है या नहीं। उस पुट को प्राप्त करने से कुछ स्पष्टता जुड़ सकती है।

मैं कुछ तरीकों की कल्पना कर सकता हूं कि एपीआई उचित टैग उपयोग को लागू कर सकता है (इस धारणा के आधार पर कि यह एक एईएडी एपीआई है, न केवल सममित एन्क्रिप्शन क्योंकि हमारे पास पहले से ही सममित एल्गोरिदम/आईसीक्रिप्टोट्रांसफॉर्म/क्रिप्टोस्ट्रीम है)। टैगिंग को लागू करने के एक उदाहरण के रूप में, इन्हें निर्देशात्मक के रूप में न लें।
विधि द्वारा:

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 {}
}

उस ने कहा, अगर यह डिक्रिप्शन पर बफर नहीं करता है, तो क्या यह सुनिश्चित करना व्यावहारिक है कि डिक्रिप्शन वास्तव में समाप्त हो गया है और टैग चेक हो गया है? क्या अपडेट किसी तरह यह पता लगा सकता है कि यह जांचने का समय है? क्या ऐसा कुछ निपटान करना चाहिए? (निपटान थोड़ा खतरनाक है क्योंकि हो सकता है कि जब तक आप वस्तु का निपटान करते हैं तब तक आप डेटा पर पहले ही भरोसा कर चुके होंगे)

जहाँ तक नामकरण की बात है, हमारी मिसाल सिमेट्रिक एल्गोरिथम और एसिमेट्रिक एल्गोरिथम है। यदि यह एईएडी के लिए अभिप्रेत है, तो कुछ विचार प्रमाणित सममित एल्गोरिथम या प्रमाणीकृत एन्क्रिप्शन एल्गोरिथम हो सकते हैं।

कुछ विचार और एपीआई विचार:

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 , विचारों के योगदान के लिए धन्यवाद। आपके एपीआई में टैग कहां जाने चाहिए? क्या वे परोक्ष रूप से सिफरटेक्स्ट का हिस्सा हैं? यदि ऐसा है, तो इसका तात्पर्य एक प्रोटोकॉल से है जो कुछ एल्गोरिदम में वास्तव में नहीं है। मैं यह समझना चाहता हूं कि लोग कौन से प्रोटोकॉल पर ध्यान दे सकते हैं यह देखने के लिए कि क्या निहित टैग प्लेसमेंट स्वीकार्य है या यदि इसे अलग से ले जाने की आवश्यकता है।

@morganbr मैंने एन्क्रिप्ट/डिक्रिप्ट समस्या पर भी ध्यान दिया, लेकिन आज रात आपके डिजाइन के लिए इतनी खुशी को ठीक करने का समय नहीं था। मैं कक्षा में विधियों को पसंद करता हूं क्योंकि यह बेहतर आक्रामक रीसाइक्लिंग की अनुमति देता है (कुंजी के लिए बफर और IV जोड़ सकते हैं)।

निपटान से पहले एक चेक के रूप में। दुर्भाग्य से किसी ऑपरेशन के अंत के बारे में बताना संभव नहीं है।

@sdrapkin इंटरफेस मैं कहूंगा कि पहले बताई गई संस्करण समस्या के कारण नहीं जाना है। जब तक हम भविष्य में डिफ़ॉल्ट इम्प्लांटेशन पर भरोसा नहीं करते। इसके अलावा इंटरफ़ेस प्रेषण धीमा है .. सरणी खंड भी हमारे हैं क्योंकि स्पैन अधिक बहुमुखी निचला आदिम है। हालांकि बाद में मांग होने पर विस्तार विधियों को सरणी सेगमेंट के लिए जोड़ा जा सकता है।

आपकी कुछ संपत्तियां रुचिकर हैं इसलिए जब मैं अपने फोन के बजाय कंप्यूटर पर हूं तो अपडेट हो जाएंगी।

हर तरफ अच्छी प्रतिक्रिया!

@morganbr टैग सिफरटेक्स्ट का हिस्सा हैं। यह CAESAR API (जिसमें AES-GCM शामिल है) के बाद तैयार किया गया है।

@Drawaes मैंने केवल विचारों को चित्रित करने के लिए इंटरफेस का उपयोग किया है - मैं स्थिर विधियों/कक्षाओं के साथ बिल्कुल ठीक हूं। अवधिमौजूद नहीं होना। मुझे इस बात की परवाह नहीं है कि क्या आ रहा है या नहीं - यह नेटस्टैंडर्ड 2 में नहीं है, और यह सामान्य .NET में नहीं है कि गंभीर परियोजनाएं वास्तव में उपयोग करती हैं (हाँ, हाँ, मुझे पता है कि यह कोर में है, लेकिन कोर एक खिलौना है अभी के लिए)। मुझे व्यक्तिगत रूप से स्पैन पर विचार करने में खुशी होगीजब मैं इसे देखता हूं - तब तक ArraySegmentनिकटतम नेटस्टैंडर्ड एपीआई है जो वास्तव में जहाज करता है।

मैं सीएईएसएआर एपीआई पर गहराई से विचार करूंगा जो उपयोगी है।

स्पैन के लिए, यह 2.1 समय सीमा के आसपास शिपिंग कर रहा है, मेरा मानना ​​​​है कि उम्मीद है कि उसी समय इस एपीआई का पहला कार्यान्वयन जहाज जाएगा (या कम से कम जल्द से जल्द संभव समय)।

यदि आप वर्तमान प्रीरिलीज़ नगेट पैकेज पर एक नज़र डालें तो यह .net मानक 1.0 तक का समर्थन करता है और रिलीज़ होने पर इसे बदलने की कोई योजना नहीं है।

हो सकता है कि @stephentoub इस बात की पुष्टि कर सकता है कि जैसा कि हम बोलते हैं, वह स्पैन आधारित एपीआई को पूरे ढांचे में जोड़ने का काम कर रहा है।

(स्पैन के लिए Nuget)[https://www.nuget.org/packages/System.Memory/4.4.0-preview2-25405-01]

तो मैं कहूंगा कि यह बिल्कुल नए एपीआई के लिए एकमात्र वास्तविक विकल्प है। फिर विस्तार विधियों आदि को एक ArraySegment लेने के लिए जोड़ा जा सकता है यदि आपने ऐसा चुना है और यदि यह पर्याप्त उपयोगी है तो इसे ढांचे में जोड़ा जा सकता है लेकिन एक ArraySegment को एक स्पैन में बदलना छोटा है, लेकिन दूसरी तरफ डेटा की प्रतिलिपि बनाने की आवश्यकता है।

उपरोक्त एपीआई के साथ मुझे जो समस्या दिखाई दे रही है, वह किसी भी "खंडित" डेटा पर प्रदर्शन के लिए एक आपदा होगी। उदाहरण के लिए नेटवर्क ट्रैफ़िक कहें, यदि एक प्रमाणीकृत ब्लॉक किसी मौजूदा स्ट्रीम से कई रीड्स पर विभाजित है, तो मुझे इसे एक ही [डेटा संरचना डालें] में बफर करना होगा और एक ही बार में एन्क्रिप्ट/डिक्रिप्ट करना होगा। उस डेटा पर किसी भी प्रकार की शून्य प्रतिलिपि करने के सभी प्रयासों को हरा देता है।

नेटवर्किंग फ्रेमवर्क जैसे कि पाइपलाइन प्रदान करता है, लगभग सभी प्रतियों से बचने का प्रबंधन करता है, लेकिन फिर अगर वे इस एपीआई में किसी भी प्रकार की क्रिप्टो हिट करते हैं तो वह सब खत्म हो जाता है।

अलग कॉन्फ़िगरेशन ऑब्जेक्ट (या बैग) वास्तव में मेरे पास मौजूद एक अन्य एपीआई पर हाल की चर्चा में शामिल है। मैं सैद्धांतिक रूप से इसका विरोध नहीं कर रहा हूं क्योंकि भविष्य में अगर यह बढ़ता है तो मुख्य वस्तु पर बड़ी संख्या में संपत्तियों का होना एक गड़बड़ हो सकता है।

मेरे साथ एक दो बातें हुई हैं।

• वर्तमान प्रस्ताव टैगसाइज को एक आउट वैल्यू (ठीक है, केवल-प्राप्त-संपत्ति) कहता है। लेकिन जीसीएम और सीसीएम दोनों के लिए यह एन्क्रिप्शन के लिए एक इनपुट है (और डिक्रिप्शन से व्युत्पन्न होने के बाद से आपने वास्तविक टैग की आपूर्ति की है)।
• प्रस्ताव मानता है कि इनपुट और आउटपुट एक ही समय और टुकड़ों में हो सकते हैं।
  
  
  
  • IIRC CCM स्ट्रीमिंग एन्क्रिप्शन नहीं कर सकता (सादे टेक्स्ट की लंबाई एल्गोरिथम के पहले चरण में एक इनपुट है)।
  
  
  • गद्देदार मोड (कम से कम एक) ब्लॉक द्वारा डिक्रिप्शन लैग करते हैं, जब तक कि फाइनल नहीं कहा जाता है, वे नहीं जानते कि क्या अधिक डेटा आ रहा है / यदि वर्तमान ब्लॉक को पैडिंग को हटाने की आवश्यकता है
  
  
• कुछ एल्गोरिदम ऑपरेशन की शुरुआत में आवश्यक होने के लिए एडी तत्व पर विचार कर सकते हैं, इसे देर से बाध्य एसोसिएशन की तुलना में एक इनिट/सीटीआर पैरामीटर की तरह बनाते हैं।

मुझे नहीं पता कि कंटेनर प्रारूपों (EnvelopedCms, EncryptedXml) को कुंजी निकालने की आवश्यकता होगी, या यदि इसे उत्पन्न करना और इसे याद रखना उनके ऊपर होगा (जब तक उन्हें इसे लिखने की आवश्यकता होती है)।

(जाहिर है कि मैंने कल इस पर "टिप्पणी" बटन नहीं मारा था, इसलिए 1910Z पर "मैंने कुछ बदलाव किए हैं" के बाद यह कुछ भी स्वीकार नहीं करेगा)

सही टैग आकार परिवर्तनशील होना चाहिए। माना।

यदि हम अभी के लिए एन्क्रिप्शन को देखते हैं, तो उपयोग के मामले को सरल बनाने के लिए। आप सही हैं कि कुछ सिफर कुछ भी कम या अधिक नहीं लौटाएंगे। यदि आप पर्याप्त बफ़र प्रदान नहीं करते हैं तो क्या होता है इसके बारे में एक सामान्य प्रश्न है।

स्पैन का उपयोग करते हुए नए टेक्स्टएन्कोडिंग इंटरफेस पर एक सुझाव था कि रिटर्न टाइप एक एनम को परिभाषित करने के लिए कि आउटपुट के लिए पर्याप्त जगह थी या नहीं, और आकार वास्तव में इसके बजाय "आउट" पैरा में लिखा गया था। यह एक संभावना है।

सीसीएम मामले में मैं बस इतना कहूंगा कि यह कुछ भी नहीं लौटाता है और आंतरिक रूप से बफर करना होगा जब तक कि आप फिनिश को कॉल न करें, जिस बिंदु पर वह पूरे लॉट को डंप करना चाहेगा। यदि आपके पास एक ही ब्लॉक में सभी डेटा हैं (जिस स्थिति में एक बेहतर नाम हो सकता है) तो आपको केवल कॉल फिनिश को अपनी पहली कॉल के रूप में कुछ भी नहीं रोकता है। या यदि आप उन सिफर पर अपडेट का प्रयास करते हैं तो फेंकना संभव है। उदाहरण के लिए यदि आप सीसीएम पर निरंतरता करने का प्रयास करते हैं तो सीएनजी एक अमान्य आकार त्रुटि देता है।

जब टैग डिक्रिप्शन पर सेट होता है, तो आप अक्सर इसे तब तक नहीं जानते जब तक कि आप पूरे पैकेट को नहीं पढ़ लेते हैं, अगर हम उदाहरण के रूप में टीएलएस लेते हैं तो हमें अंत में टैग तक पहुंचने के लिए 8 * 2k नेटवर्क पैकेट पढ़ना पड़ सकता है। एक 16k ब्लॉक का। इसलिए अब हमें डिक्रिप्शन शुरू करने से पहले पूरे 16k को बफर करना होगा और ओवरलैप करने का कोई मौका नहीं है (मैं यह नहीं कह रहा हूं कि इसका उपयोग टीएलएस के लिए किया जाएगा कि इस प्रकार के सिफर के लिए एक आईओ बाध्य प्रक्रिया आम है, चाहे वह डिस्क हो या नेटवर्क)।

@Drawaes रे। खंडित धाराएँ और बफरिंग सीमाएँ:
आपको अपनी लड़ाई चुननी होगी। आप एई दुनिया में हर एक अच्छे लक्ष्य के साथ संरेखित एक एकीकृत एपीआई बनाने में सक्षम नहीं होंगे - और ऐसे कई लक्ष्य हैं। भूतपूर्व। इन्फर्नो में एक सभ्य खंडित AEAD स्ट्रीमिंग है, लेकिन यह किसी भी खिंचाव से मानक नहीं है, और ऐसा मानक मौजूद नहीं है। उच्च स्तर पर, लक्ष्य "सुरक्षित चैनल" है (देखें यह , यह , और यह )।

हालाँकि, हमें अभी के लिए छोटा सोचने की जरूरत है। मानकीकरण के प्रयासों के लिए चंकिंग/बफर-लिमिटिंग रडार पर भी नहीं है (" बड़े प्लेनटेक्स्ट वाले AEADs " सेक्शन) ..

एन्क्रिप्शन/डिक्रिप्शन ऑपरेशंस मूल रूप से ट्रांसफॉर्म के बारे में हैं। इन परिवर्तनों के लिए बफ़र्स की आवश्यकता होती है, और ये इन-प्लेस नहीं होते हैं (आउटपुट बफ़र्स इनपुट बफ़र्स से बड़े होने चाहिए - कम से कम एन्क्रिप्ट ट्रांसफ़ॉर्म के लिए)।

RFC 5116 भी रुचि का हो सकता है।

@Drawaes , दिलचस्प है कि आप टीएलएस लाते हैं। मैं तर्क दूंगा कि एसएसएलस्ट्रीम (क्या यह इस एपीआई का उपयोग करने के लिए था) को किसी भी अनधिकृत परिणाम को किसी एप्लिकेशन पर वापस नहीं करना चाहिए क्योंकि एप्लिकेशन के पास स्वयं का बचाव करने का कोई तरीका नहीं होगा।

ज़रूर, लेकिन वह SSLStreams समस्या है। मैंने पाइपलाइनों के शीर्ष पर इस सटीक चीज़ (प्रोटोकॉल स्तर पर सीएनजी और ओपनएसएसएल को क्रिप्टो बिट्स के लिए कॉल करने पर प्रबंधित टीएलएस) को प्रोटोटाइप किया है। तर्क बहुत सरल था, एन्क्रिप्टेड डेटा आता है, जगह में बफर को डिक्रिप्ट करें, आउट बाउंड से संलग्न करें और जब तक आप टैग तक नहीं पहुंच जाते तब तक दोहराएं। टैग कॉल समाप्त होने पर...

अगर यह पाइप लाइन को बंद कर देता है। यदि यह फेंकता नहीं है तो फ्लश अगले चरण को उसी धागे पर या प्रेषण के माध्यम से काम पर जाने की इजाजत देता है।

मेरी अवधारणा का प्रमाण प्राइमटाइम के लिए तैयार नहीं था, लेकिन इसका उपयोग करके और बहुत सारी प्रतियों आदि से बचने से यह बहुत ही अच्छा प्रदर्शन बढ़ा;)

किसी भी नेटवर्किंग के साथ समस्या यह है कि पाइपलाइन में चीजें अपने स्वयं के बफर आवंटित करना शुरू कर देती हैं और जितना संभव हो उतना उपयोग नहीं कर रही हैं जो पहले से ही सिस्टम के माध्यम से आगे बढ़ रहे हैं।

ओपनएसएसएल के क्रिप्ट, और सीएनजी में एक ही विधि अपडेट, अपडेट, फिनिश है। चर्चा के अनुसार फिनिश टैग को आउटपुट कर सकता है। अद्यतन ब्लॉक आकार (सीएनजी के लिए) में होना चाहिए और ओपनएसएसएल के लिए यह ब्लॉक आकार तक पहुंचने के लिए न्यूनतम बफरिंग करता है।

चूंकि वे आदिम हैं, मुझे यकीन नहीं है कि हम उनसे उच्च स्तरीय कार्यक्षमता की अपेक्षा करेंगे। यदि हम उन्हें बनाने के लिए आदिम के बजाय एक "उपयोगकर्ता" स्तर एपीआई डिजाइन कर रहे थे, तो मैं तर्क दूंगा कि प्रमुख पीढ़ी, IV निर्माण और संपूर्ण प्रमाणित भाग सभी को लागू किया जाना चाहिए, इसलिए मुझे लगता है कि यह निर्भर करता है कि इस एपीआई का लक्ष्य स्तर वास्तव में क्या है।

गलत बटन

@blowdart , जिनके पास गैर प्रबंधन पर कुछ दिलचस्प विचार थे।

तो गैर प्रबंधन मूल रूप से एक उपयोगकर्ता समस्या है और उनके सेटअप के लिए विशिष्ट है।

तो ... इसे एक आवश्यकता बनाओ। आपको गैर प्रबंधन में प्लग इन करना होगा ... और डिफ़ॉल्ट कार्यान्वयन, या किसी भी कार्यान्वयन की आपूर्ति बिल्कुल नहीं करनी चाहिए। यह, बजाय एक साधारण

cipher.Init(myKey, nonce);

उपयोगकर्ताओं को एक विशिष्ट इशारा करने के लिए मजबूर करता है कि जोखिम को समझें।

@blowdart का विचार गैर प्रबंधन समस्याओं और एल्गोरिदम के बीच अंतर दोनों में मदद कर सकता है। मैं मानता हूं कि यह सुनिश्चित करने के लिए अंतर्निहित कार्यान्वयन नहीं होना महत्वपूर्ण है कि उपयोगकर्ता यह समझें कि गैर प्रबंधन एक समस्या है जिसे उन्हें हल करने की आवश्यकता है। ऐसा कुछ कैसा दिखता है?

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 का क्या मतलब है? यह सिर्फ एक अतिरिक्त इंटीफेस/प्रकार है, अगर इनिट सिर्फ कोई नहीं लेता है और किसी भी ब्लॉक को शुरू करने से पहले कॉल करने की आवश्यकता होती है, तो क्या यह अतिरिक्त/इंटरफ़ेस के बिना एक ही चीज़ नहीं है?

इसके अलावा, मैं कोई क्रिप्टो विशेषज्ञ नहीं हूं, लेकिन एईएस को IV की आवश्यकता नहीं है (जो एक गैर नहीं है लेकिन उपयोगकर्ता द्वारा प्रदान करने की आवश्यकता है?)

यह सिर्फ एक अतिरिक्त इंटरफ़ेस/प्रकार है

ऐसी बात है। यह अनिवार्य रूप से कहता है कि _nonce प्रबंधन_ एक समस्या है, न कि केवल शून्य या यादृच्छिक बाइट सरणी में गुजरना। यह अनजाने में पुन: उपयोग को रोकने में भी मदद कर सकता है यदि लोग GetNextNonce की व्याख्या करते हैं जिसका अर्थ है "पिछली बार की तुलना में कुछ अलग लौटाएं"।

एल्गोरिदम के लिए इसकी आवश्यकता नहीं होना भी सहायक है, जिसमें गैर प्रबंधन समस्याएं नहीं हैं (जैसे एईएस एसआईवी या शायद एईएस + सीबीसी + एचएमएसी)।

सटीक IV/गैर-आवश्यकताएं मोड के आधार पर भिन्न होती हैं। उदाहरण के लिए:

• एईएस ईसीबी को गैर या IV की आवश्यकता नहीं है
• एईएस जीसीएम को 96-बिट नॉन की आवश्यकता होती है जिसे कभी भी पुन: उपयोग नहीं किया जाना चाहिए या कुंजी टूटने की सुरक्षा नहीं होनी चाहिए। जब तक गैर का पुन: उपयोग नहीं किया जाता है तब तक कम एन्ट्रॉपी ठीक है।
• एईएस सीबीसी को 128-बिट IV की आवश्यकता होती है जो यादृच्छिक होना चाहिए। यदि IV दोहराता है, तो यह केवल यह बताता है कि क्या वही संदेश पहले भेजा गया है।
• एईएस एसआईवी को स्पष्ट IV की आवश्यकता नहीं है क्योंकि यह इसे अन्य इनपुट से प्राप्त करता है।

एईएस सीबीसी को IV चाहिए ना? तो क्या आपके पास इनिशियलाइज़ेशन वेक्टरप्रोवाइडर होगा? यह एक गैर नहीं है लेकिन
अंतिम ब्लॉक को गैर-पसंद करने और पुन: उपयोग करने से टीएलएस हमला हुआ क्योंकि iv की भविष्यवाणी की जा सकती है। आप स्पष्ट रूप से सीबीसी के लिए अनुक्रमिक गैर कहने का उपयोग नहीं कर सकते हैं।

हाँ, लेकिन IV एक गैर नहीं है, इसलिए आपके पास nomce प्रदाता शब्द नहीं हो सकता है

मेरा मतलब यह नहीं था कि एईएस सीबीसी को आईवी की जरूरत नहीं है-- यह करता है। मेरा मतलब केवल कुछ योजनाओं के बारे में अनुमान लगाना था जो IV को अन्य डेटा से प्राप्त करती हैं।

निश्चित रूप से मुझे लगता है कि मेरी बात यह है कि मैं इसे आम तौर पर पसंद करता हूं ... मैं प्रदाता को पूल कर सकता हूं;) लेकिन या तो इसे एक iv प्रदाता कहते हैं या इरादे पर स्पष्ट होने के लिए 2 इंटरफेस हैं

@morganbr INonceProvider सिफर कंस्ट्रक्टरों में पारित कारखाने एक खराब डिज़ाइन हैं। यह पूरी तरह से इस तथ्य को याद करता है कि _nonce_ अपने आप में मौजूद नहीं है: "_...used ones_" बाधा में एक _context_ है। CTR और GCM (जो CTR का उपयोग करता है) मोड के मामलों में, _nonce_ का _context_ _key_ है। अर्थात। _nonce प्रदाता_ को एक गैर-वापसी लौटानी चाहिए जिसका उपयोग किसी विशिष्ट _key_ के संदर्भ में केवल एक बार किया जाता है।

चूंकि आपके प्रस्तावित एपीआई में INonceProvider कुंजी-जागरूक नहीं है, इसलिए यह सही नॉनस उत्पन्न नहीं कर सकता है (यादृच्छिकता के अलावा, जो कि एक गैर नहीं है, भले ही सांख्यिकीय यादृच्छिकता के काम करने के लिए बिट स्पेस काफी बड़ा था सुरक्षित रूप से)।

मुझे पूरा यकीन नहीं है कि इस चर्चा सूत्र का लक्ष्य क्या हासिल करना है। विभिन्न प्रमाणित-एन्क्रिप्शन डिज़ाइन विचारों पर चर्चा की जाती है... ठीक है। पहले से ही .NET कोर में निर्मित प्रमाणित एन्क्रिप्शन इंटरफेस के बारे में क्या - विशेष रूप से इसके ASP.NET API में? IAuthenticatedEncryptor , आदि है। इन सभी क्षमताओं को आज .NET कोर के हिस्से के रूप में लागू, एक्स्टेंसिबल और शिपिंग किया जा चुका है। मैं यह नहीं कह रहा हूं कि डेटाप्रोटेक्शन क्रिप्टो सही है, लेकिन क्या उन्हें अनदेखा करने की योजना है? उन्हें बदलो? आत्मसात या रिफैक्टर?

DataProtection क्रिप्टो को @GrabYourPitchforks (लेवी ब्रोडरिक) द्वारा बनाया गया था। वह विषय वस्तु जानता है, और उसकी राय/इनपुट/प्रतिक्रिया इस समुदाय के लिए सबसे मूल्यवान होगी। मैं क्रिप्टो-थीम वाले मनोरंजन का उतना ही आनंद लेता हूं जितना कि कोई, लेकिन अगर कोई क्रिप्टो एपीआई डिजाइन के बारे में गंभीर होना चाहता है, तो वास्तविक विशेषज्ञ जो पहले से ही एमएस टीम में हैं, उन्हें शामिल किया जाना चाहिए।

@sdrapkin , गैर-प्रदाताओं को महत्वपूर्ण जागरूक होने की आवश्यकता है, यह एक अच्छी बात है। मुझे आश्चर्य है कि इन एपीआई को लागू करने के लिए संशोधित करने का कोई उचित तरीका है या नहीं।

डेटाप्रोटेक्शन एक अच्छा एपीआई है, लेकिन यह एक उच्च स्तरीय निर्माण है। यह प्रमुख पीढ़ी और प्रबंधन, IVs और आउटपुट प्रोटोकॉल को इनकैप्सुलेट करता है। अगर किसी को एक अलग प्रोटोकॉल के कार्यान्वयन में जीसीएम का उपयोग (कहना) करने की आवश्यकता है, तो डेटाप्रोटेक्शन इसे संभव नहीं बनाता है।

.NET क्रिप्टो टीम में @bartonjs , @blowdart और मैं शामिल हैं। बेशक, अगर @GrabYourPitchforks झंकार करना चाहता है, तो वह स्वागत से अधिक है।

मैं @morganbr से सहमत हूं कि यह निम्न स्तर का आदिम माना जाता है (वास्तव में यह शीर्षक में कहता है)। जबकि डेटा सुरक्षा आदि को सीधे उपयोगकर्ता कोड में उपयोग करने के लिए डिज़ाइन किया गया है और पैर में खुद को शूट करने की क्षमता को कम करता है, जिस तरह से मैं इस आदिम को देखता हूं वह ढांचे और पुस्तकालयों को एक सामान्य आधार पर उच्च स्तर के निर्माण की अनुमति देना है।

उस विचार को ध्यान में रखते हुए, प्रदाता ठीक है अगर इसे किसी भी समय एक कुंजी की आपूर्ति की जाती है। यह इसे थोड़ा गड़बड़ कर देता है मुझे टीएलएस का उपयोग करके समझाता है (यह नेटवर्क यातायात के लिए एईएस ब्लॉक मोड का एक प्रसिद्ध उपयोग है)।

मुझे एक "फ्रेम" मिलता है (शायद इंटरनेट के एमटीयू ~ 1500 के साथ 2 + टीयू से अधिक)। इसमें नॉन (या 4 बाइट्स के साथ नॉन का हिस्सा "छिपा हुआ") होता है, फिर मुझे इस मान को एक शेल "प्रदाता" पर सेट करना होता है और फिर डिक्रिप्ट को कॉल करना होता है और एक सादा पाठ प्राप्त करने के लिए बफ़र्स को डिक्रिप्ट करने के अपने चक्र से गुजरना पड़ता है। .

अगर आप इससे खुश हैं तो मैं इसके साथ रह सकता हूं। मैं इसे आगे बढ़ाने के लिए उत्सुक हूं ताकि उपरोक्त डिज़ाइन को उस चीज़ पर अपडेट करने के लिए उत्सुक हूं जिस पर हम सहमत हो सकते हैं।

चर्चा को आगे बढ़ाने के लिए धन्यवाद, इस पर कूदने के लिए कुछ खाली समय मिल रहा है। @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 के लिए।

चूंकि सारी दुनिया एक मेम है, विरोध नहीं कर सकती, क्षमा करें :)

साथ ही, एपीआई नए, इनिट, अपडेट आदि के साथ गंदी लगती है। मैं इस प्रोग्रामर के मॉडल का प्रस्ताव दूंगा

// 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. आम तौर पर एएडी << सादा पाठ इसलिए मैंने cipher.Init(mykey, nonce, aad); देखा है जहां पूरे एएडी को बफर के रूप में पारित किया जाता है और फिर सिफर शेष संभावित गीगाबाइट + स्ट्रीम पर क्रंच करता है। (उदाहरण के लिए BCryptEncrypts's CipherModeInfo param )। इसके अलावा, myKey का आकार पहले से ही AES128, 192, 256 स्थापित करता है, किसी अन्य पैरामीटर की कोई आवश्यकता नहीं है।
2. यदि कॉलर मौजूदा वर्ग, मौजूदा एईएस स्थिरांक का पुन: उपयोग करना चाहता है और एईएस कुंजी समान होने पर एईएस उपकुंजी पीढ़ी को छोड़ना चाहता है तो इनिट एक वैकल्पिक एपीआई बन जाता है।
3. सिफर के एपीआई को अधिकांश अन्य क्रिप्टो एपीआई या यहां तक ​​कि मौजूदा .NET एपीआई जैसे ब्लॉक आकार प्रबंधन आंतरिक से कॉलर को ढाल देना चाहिए। उनके उपयोग के मामले के लिए अनुकूलित बफर आकार से संबंधित कॉलर जैसे नेटवर्क आईओ 16 के + बफर के माध्यम से)। कार्यान्वयन मान्यताओं का परीक्षण करने के लिए एक प्रमुख संख्या> 16K के साथ प्रदर्शन करना
4. इनपुटस्पैन केवल पढ़ने के लिए है। और इनपुट। तो एक आउटस्पैन की जरूरत है
5. अद्यतन () एन्क्रिप्ट या डिक्रिप्ट करता है? डेवलपर के मानसिक मॉडल से मेल खाने के लिए बस एन्क्रिप्ट और डिक्रिप्ट इंटरफेस रखें। tag भी इस समय सबसे महत्वपूर्ण वांछित डेटा है, उसे वापस कर दें।

वास्तव में एक कदम आगे बढ़ते हुए, क्यों न सिर्फ

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

इसके अलावा, कृपया INonceProvider और अन्य प्रकारों से दूर रहें। क्रिप्टो प्राइमेटिव को इसकी आवश्यकता नहीं है, बस byte[] iv (छोटे डेटा के लिए मेरा पसंदीदा) या Span (माना जाता है कि नया अच्छा लेकिन बहुत अधिक अमूर्त IMHO) से चिपके रहें। नॉन प्रोवाइडर ऊपर की परत पर काम करता है और इसका परिणाम यहां देखा गया iv हो सकता है।

आदिम को इतना आदिम बनाने में समस्या यह है कि लोग उनका गलत इस्तेमाल करेंगे। एक प्रदाता के साथ हम कम से कम कुछ विचारों को उनके उपयोग में मजबूर कर सकते हैं।

हम आम तौर पर एईएडी के बारे में बात कर रहे हैं जिसमें जीसीएम विशिष्ट है। तो सबसे पहले, सामान्यीकृत मामला ( iv ) को डिज़ाइन को चलाना चाहिए, न कि विशिष्ट मामले ( nonce )।

दूसरे, केवल byte[] iv से GetNextNonce(Span<byte> writeNonceHere) में स्थानांतरण वास्तव में गैर-समस्या को कैसे हल करता है? आपने समस्या पर केवल नाम/लेबल बदल दिया है, साथ ही साथ इसे और अधिक जटिल बना दिया है।

तीसरा, चूंकि हम iv सुरक्षा पर नीतियों में शामिल हो रहे हैं, क्या हमें प्रमुख सुरक्षा नीतियों में भी शामिल होना चाहिए? प्रमुख वितरण नीतियों के बारे में क्या? वे स्पष्ट रूप से उच्च स्तरीय चिंताएं हैं।

अंत में, उच्च परतों पर उपयोग पर गैर अत्यंत स्थितिजन्य है। आप एक भंगुर वास्तुकला नहीं चाहते हैं जहां क्रॉस-लेयर चिंताओं को एक साथ जोड़ा जा रहा है।

सच कहूं तो अगर हम आदिम को छिपा सकते हैं जब तक कि कोई यह कहने का इशारा नहीं करता कि मुझे पता है कि मैं क्या कर रहा हूं, मैं उसके लिए जोर दूंगा। लेकिन हम नहीं कर सकते। वहाँ बहुत अधिक खराब क्रिप्टो कार्यान्वयन हैं क्योंकि लोग "ओह यह उपलब्ध है, मैं इसका उपयोग करूँगा"। हेक एईएस को ही देखें, मैं बिना एचएमएसी के इसका इस्तेमाल करूंगा।

मैं एपीआई को डिफ़ॉल्ट रूप से सुरक्षित देखना चाहता हूं, और अगर इसका मतलब थोड़ा और दर्द है तो स्पष्ट रूप से मैं इसके लिए तैयार हूं। 99% डेवलपर्स नहीं जानते कि क्रिप्टो के मामले में वे क्या कर रहे हैं और 1% के लिए इसे आसान बनाना जो कम प्राथमिकता होनी चाहिए।

स्पैन मौजूद नहीं है। मुझे इस बात की परवाह नहीं है कि क्या आ रहा है या नहीं - यह NetStandard2 में नहीं है

@sdrapkin जैसा कि @Drawaes बताता है Span<T> .NET मानक 1.0 है इसलिए किसी भी ढांचे पर इसका उपयोग किया जा सकता है। यह ArraySegment<T> से भी सुरक्षित है क्योंकि यह आपको केवल संदर्भित वास्तविक विंडो तक पहुंचने देता है; पूरे सरणी के बजाय।

साथ ही ReadOnlySpan<T> उस विंडो में संशोधन को रोकता है; फिर से सरणी खंड के विपरीत जहां कुछ भी पारित किया गया वह पारित सरणी के संदर्भ को संशोधित और/या बनाए रख सकता है।

सिंक एपिस के लिए स्पैन सामान्य होना चाहिए (तथ्य यह है कि स्पैन का उपयोग करने वाला एक एपीआई अतिरिक्त रूप से स्टैकलॉक, देशी मेमोरी के साथ-साथ सरणियों का सामना कर सकता है; आइसिंग है)

अर्थात
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
    );

हालांकि स्पैन के साथ केवल एपीआई द्वारा लागू किया जाता है; साथ ही सीमा से बाहर सरणियों को रोका जा रहा है

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> किसी भी शिप किए गए नेटस्टैंडर्ड में नहीं है; (2) कि Span<T> _"2.1 समय सीमा के आसपास शिपिंग"_ होगा।

इस विशेष जीथब मुद्दे के लिए, हालांकि, (केवल-पढ़ने के लिए) Span<T> चर्चा अभी बाइकशेडिंग है - एपीआई के डिजाइन के दायरे या उद्देश्य पर कोई स्पष्टता नहीं है।

या तो हम कच्चे निम्न-स्तरीय आदिम AEAD API के साथ जाते हैं (उदा। CAESAR के समान):

• पेशेवरों: एईएस-जीसीएम/सीसीएम के लिए अच्छा फिट, अच्छे स्रोतों (एनआईएसटी, आरएफसी) से मौजूदा परीक्षण वैक्टर। @sidshetye खुश होंगे। @blowdart _ "आदिम को इतना आदिम बनाने" पर ध्यान देगा, लेकिन अंततः यिन और यांग को देखेगा क्योंकि आदिम आदिम हैं और उन्हें चाइल्डप्रूफ करने का कोई तरीका नहीं है।
• विपक्ष: विशेषज्ञ उपयोगकर्ता (कहावत 1%) निम्न-स्तरीय एपीआई का जिम्मेदारी से उपयोग करेंगे, जबकि अन्य गैर-विशेषज्ञ उपयोगकर्ता (99%) टूटे हुए .NET सॉफ़्टवेयर को लिखने के लिए इसका दुरुपयोग करेंगे जो कि .NET के विशाल बहुमत के लिए जिम्मेदार होगा। सीवीई, जो इस धारणा में बहुत योगदान देगा कि .NET एक असुरक्षित मंच है।

या हम उच्च-स्तरीय दुरुपयोग-असंभव या प्रतिरोधी AEAD API के साथ जाते हैं:

• पेशेवरों: 99% गैर-विशेषज्ञ उपयोगकर्ता गलतियाँ करना जारी रखेंगे, लेकिन कम से कम AEAD कोड में नहीं। @blowdart का _ "मैं डिफ़ॉल्ट रूप से एपीआई को सुरक्षित देखना चाहता हूं" _ पारिस्थितिकी तंत्र में गहराई से प्रतिध्वनित होता है, और सुरक्षा, समृद्धि और अच्छे कर्म सभी पर पड़ते हैं। कई अच्छे एपीआई डिजाइन और कार्यान्वयन पहले से ही उपलब्ध हैं।
• विपक्ष: कोई मानक नहीं। कोई परीक्षण वैक्टर नहीं। इस बात पर कोई सहमति नहीं है कि क्या AEAD उच्च-स्तरीय ऑनलाइन स्ट्रीमिंग API के लिए लक्षित करने का सही लक्ष्य है (स्पॉइलर: यह नहीं है - रोगवे का पेपर देखें)।

या, हम दोनों करते हैं। या हम विश्लेषण पक्षाघात में प्रवेश करते हैं और इस मुद्दे को अभी बंद कर सकते हैं।

मैं दृढ़ता से महसूस करता हूं कि मूल भाषा का हिस्सा होने के नाते, क्रिप्टो को एक ठोस, निम्न स्तर की मूलभूत एपीआई की आवश्यकता होती है। एक बार आपके पास यह हो जाने के बाद, उच्च स्तरीय एपीआई या "ट्रेनिंग व्हील्स" एपीआई बनाने से कोर या समुदाय द्वारा जल्दी से ब्रिज किया जा सकता है। लेकिन मैं किसी को भी चुनौती देता हूं कि इसका उल्टा शान से करें। साथ ही विषय " सिफर के लिए सामान्य निम्न स्तर का आदिम " है!

@Drawaes क्या इसे अभिसरण और हल करने के लिए कोई समयरेखा है? ऐसे GitHub अलर्ट से परे गैर-Microsoft लोगों को शामिल करने की कोई योजना? 30 मिनट की कॉन्फ्रेंस कॉल की तरह? मैं एक खरगोश छेद से बाहर रहने की कोशिश कर रहा हूं लेकिन हम शर्त लगा रहे हैं कि .NET कोर क्रिप्टो परिपक्वता और स्थिरता के एक निश्चित स्तर पर होगा .. इसलिए इस तरह की चर्चाओं के लिए ट्राइएज कर सकते हैं।

हम अभी भी इस पर ध्यान दे रहे हैं और काम कर रहे हैं। हमने माइक्रोसॉफ्ट क्रिप्टोग्राफी बोर्ड (शोधकर्ताओं और अन्य विशेषज्ञों का समूह जो माइक्रोसॉफ्ट के क्रिप्टोग्राफी के उपयोग की सलाह देते हैं) से मुलाकात की है और @bartonjs के पास जल्द ही साझा करने के लिए और जानकारी होगी।

थोड़ा डेटा प्रवाह डूडलिंग और क्रिप्टो बोर्ड की सलाह के आधार पर हम निम्नलिखित के साथ आए। हमारा मॉडल GCM, CCM, SIV और CBC+HMAC था (ध्यान दें कि हम अभी SIV या CBC+HMAC करने की बात नहीं कर रहे हैं, बस हम आकार को साबित करना चाहते हैं)।

```सी#
सार्वजनिक इंटरफ़ेस INonceProvider
{
रीड ओनलीस्पैनगेटनेक्स्टनोन्स (इंट नॉनसाइज़);
}

पब्लिक एब्स्ट्रैक्ट क्लास ऑथेंटिकेटेडएन्क्रिप्टर: IDISposable
{
सार्वजनिक int NonceOrIVSizeInBits {प्राप्त करें; }
सार्वजनिक int TagSizeInBits {प्राप्त करें; }
सार्वजनिक बूल एसोसिएटेडडेटा का समर्थन करता है {प्राप्त करें; }
सार्वजनिक केवल पढ़ने के लिए स्पैनLastNonceOrIV {प्राप्त करें; }
सार्वजनिक केवल पढ़ने के लिए स्पैनलास्टटैग {प्राप्त करें; }

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(ReadOnlySpankeySize, INonceProvider गैर-प्रदाता)
: आधार(128, सच, 96)
{
}
}

सार्वजनिक मुहरबंद वर्ग AesCcmEncryptor : AuthenticatedEncryptor
{
सार्वजनिक AesCcmEncryptor(
रीड ओनलीस्पैनचाभी,
इंट नॉनसाइजइनबिट्स,
INonceProvider गैर-प्रदाता,
इंट टैगसाइजइनबिट्स)
: आधार (tagSizeInBits, सच, nonceSizeInBits)
{
एल्गोरिथ्म कल्पना के खिलाफ गैर-आकार और टैग आकार को मान्य करें;
}
}

पब्लिक एब्स्ट्रैक्ट क्लास ऑथेंटिकेटेड डिक्रिप्टर: IDISposable
{
सार्वजनिक सार बूल ट्राईडिक्रिप्ट (
रीड ओनलीस्पैनउपनाम,
रीड ओनलीस्पैनगैर-ओआरआईवी,
रीड ओनलीस्पैनएन्क्रिप्टेड डेटा,
रीड ओनलीस्पैनसंबद्ध डेटा,
अवधिआंकड़े,
आउट इंट बाइट्स राइट);

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कुंजी) => अशक्त फेंक;
}

सार्वजनिक मुहरबंद वर्ग AesCcmDecryptor : AuthenticatedDecryptor
{
सार्वजनिक AesCcmDecryptor(ReadOnlySpanकुंजी) => अशक्त फेंक;
}
```

यह प्रस्ताव डेटा स्ट्रीमिंग को समाप्त करता है। उस बिंदु पर हमारे पास वास्तव में बहुत अधिक लचीलापन नहीं है। वास्तविक दुनिया की आवश्यकता (निम्न) संबद्ध जोखिमों (जीसीएम के लिए अत्यधिक उच्च) या इसकी असंभवता (सीसीएम) के साथ संयुक्त होने का अर्थ है कि यह अभी समाप्त हो गया है।

यह प्रस्ताव एन्क्रिप्शन के लिए गैर के बाहरी स्रोत का उपयोग करता है। हमारे पास इस इंटरफ़ेस का कोई सार्वजनिक कार्यान्वयन नहीं होगा। प्रत्येक एप्लिकेशन/प्रोटोकॉल को संदर्भ की कुंजी को स्वयं बांधना चाहिए ताकि वह चीजों को उचित रूप से खिला सके। जबकि TryEncrypt के लिए प्रत्येक कॉल GetNextNonce को केवल एक कॉल करेगा, इस बात की कोई गारंटी नहीं है कि वह विशेष TryEncrypt सफल होगा, इसलिए यह अभी भी एप्लिकेशन पर निर्भर है कि क्या इसका मतलब है कि इसे गैर-पुन: प्रयास करना चाहिए। सीबीसी+एचएमएसी के लिए हम शब्दावली में गड़बड़ी से बचने के लिए एक नया इंटरफेस, आईआईवीप्रोवाइडर बनाएंगे। SIV के लिए IV बनाया गया है, इसलिए कोई स्वीकार्य पैरामीटर नहीं है; और कल्पना के आधार पर गैर (जब उपयोग किया जाता है) को केवल संबंधित डेटा के हिस्से के रूप में माना जाता है। तो SIV, कम से कम, सुझाव देता है कि TryEncrypt के पैरामीटर के रूप में nonceOrIV का होना आम तौर पर लागू नहीं होता है।

TryDecrypt निश्चित रूप से अमान्य टैग पर फेंकता है। यदि गंतव्य बहुत छोटा है (कोशिश विधियों के नियमों के अनुसार) यह केवल झूठी वापसी करता है

चीजें जो निश्चित रूप से प्रतिक्रिया के लिए खुली हैं:

• क्या आकार बिट्स में होना चाहिए (जैसे चश्मे के महत्वपूर्ण हिस्से) या बाइट्स (चूंकि केवल% 8 मान वैसे भी कानूनी हैं, और हम हमेशा विभाजित करने जा रहे हैं, और चश्मे के कुछ हिस्से बाइट्स में गैर आकार जैसी चीजों के बारे में बात करते हैं )?
• पैरामीटर नाम और आदेश।
• LastTag/LastNonceOrIV गुण। (उन्हें (लिखने योग्य) बनाना एक सार्वजनिक TryEncrypt पर फैला हुआ है, इसका मतलब है कि तीन बफ़र्स हैं जो बहुत छोटे हो सकते हैं, उन्हें किनारे पर बैठने से "कोशिश" अधिक स्पष्ट है; बेस क्लास वादा कर सकता है कि यह होगा कभी भी बहुत छोटा बफर न दें।)
• एक एई एल्गोरिदम पेश करना जिसके लिए यह काम नहीं करता है।
• क्या associatedData को डिफ़ॉल्ट ReadOnlySpan<byte>.Empty के साथ अंत में ले जाया जाना चाहिए?
  
  
  
  • या ओवरलोड ने इसे छोड़ दिया?
  
  
• क्या कोई byte[] -रिटर्निंग विधियों के लिए प्यार, या नफरत का दावा करना चाहता है? (स्पैन विधि का उपयोग करके कम आवंटन प्राप्त किया जा सकता है, यह केवल सुविधा के लिए है)
• आकार सीमा विधियाँ अंत में बोल्ट की तरह थीं।
  
  
  
  • उनका उद्देश्य है कि
  
  
  • यदि गंतव्य अवधि न्यूनतम से कम है, तो तुरंत झूठी वापसी करें।
  
  
  • byte[] -रिटर्निंग विधियां अधिकतम का बफर आवंटित करेंगी, और फिर ऐरे। आवश्यकतानुसार इसे आकार दें।
  
  
  • हाँ, GCM और CCM के लिए min=max=input.Length , लेकिन यह CBC+HMAC या SIV के लिए सही नहीं है
  
  
  • क्या कोई एल्गोरिदम है जिसे संबंधित डेटा लंबाई को ध्यान में रखना होगा?
  
  

निश्चित रूप से बाइट्स - बिट्स नहीं।
गैर-प्रदाता जो की-अवेयर नहीं है, एक बड़ी गलती है।

गैर-प्रदाता जो की-अवेयर नहीं है, एक बड़ी गलती है।

आप अपने गैर-प्रदाता को अपनी पसंद के अनुसार लिख सकते हैं। हम कोई प्रदान नहीं कर रहे हैं।

नियतात्मक सफाई/ IDisposable के बारे में क्या?

नियतात्मक सफाई/आईडीस्पोजेबल के बारे में क्या?

अच्छा निर्णय। इसे AuthenticatedEncryptor/AuthenticatedDecryptor में जोड़ा। मुझे नहीं लगता कि उन्हें नॉन प्रोवाइडर पर डिस्पोज़ेबिलिटी की जांच करनी चाहिए, कॉलर सिर्फ यूजिंग स्टेटमेंट्स को स्टैक कर सकता है।

INonceProvider अवधारणा/उद्देश्य से मुझे कोई मतलब नहीं है (दूसरों को प्रतिध्वनित करना)। प्राइमेटिव को आदिम होने दें - नॉन में उसी तरह से पास करें जैसे आप कुंजी में पास करते हैं (यानी बाइट्स के रूप में - हालांकि घोषित)। कोई एई/एईएडी स्पेक एक एल्गोरिदम को मजबूर नहीं करता है कि कैसे गैर उत्पन्न/व्युत्पन्न होते हैं - यह एक उच्च-परत जिम्मेदारी है (कम से कम लेट-प्राइमिटिव-बी-आदिम मॉडल में)।

कोई स्ट्रीमिंग नहीं? सच में? मूल आधारभूत स्तर पर एईएस-जीसीएम जैसे स्ट्रीम सिफर से स्ट्रीमिंग को जबरन हटाने का क्या औचित्य है?

उदाहरण के लिए, आपका क्रिप्टो बोर्ड हमारे द्वारा समीक्षा की गई इन दो हालिया परिदृश्यों की क्या सिफारिश करता है?

1. क्लाइंट के पास 10-30GB के बीच बड़ी स्वास्थ्य संबंधी फ़ाइलें हैं। कोर केवल दो मशीनों के बीच डेटा स्ट्रीम देखता है, इसलिए यह एक पास स्ट्रीम है। स्पष्ट रूप से प्रत्येक 10GB फ़ाइल के लिए एक नई कुंजी जारी की जाती है, लेकिन आपने ऐसे प्रत्येक वर्कफ़्लो को बेकार कर दिया है। अब आप चाहते हैं कि हम a) उस डेटा को बफर करें (मेमोरी, कोई पाइप-लाइनिंग नहीं) b) एन्क्रिप्शन (पाइपलाइन में सभी मशीनें अब निष्क्रिय हैं!) किया हुआ) ? कृपया मुझे बताएं कि आप मजाक कर रहे हैं। आप लोग जानबूझकर "एन्क्रिप्शन एक बोझ है" खेल में वापस डाल रहे हैं।

2. भौतिक सुरक्षा इकाई में कई 4K धाराएँ होती हैं जो आराम से परिदृश्यों के लिए भी एन्क्रिप्ट की जाती हैं। फ्रेश की इश्यू 15GB की सीमा पर होता है। आप पूरी क्लिप को बफर करने का प्रस्ताव रखते हैं?

मुझे समुदाय से कोई इनपुट नहीं दिख रहा है, वास्तव में वास्तविक-विश्व सॉफ़्टवेयर बनाने वाले लोग, स्ट्रीमिंग समर्थन को हटाने के लिए कह रहे हैं। लेकिन फिर टीम सामुदायिक संवाद से गायब हो जाती है, आंतरिक रूप से उलझ जाती है और फिर किसी ने कुछ नहीं मांगा है, कुछ ऐसा जो वास्तविक अनुप्रयोगों को मारता है और फिर से लागू करता है कि "एन्क्रिप्शन धीमा और महंगा है, इसे छोड़ दें?"

आप Encrypt और EncryptFinal प्रदान कर सकते हैं जो पूरे पारिस्थितिकी तंत्र के लिए अपना निर्णय थोपने के बजाय दोनों विकल्पों का समर्थन करेगा।

सुरुचिपूर्ण डिजाइन जटिलता को समाप्त करता है, नियंत्रण को नहीं।

मूल आधारभूत स्तर पर एईएस-जीसीएम जैसे स्ट्रीम सिफर से स्ट्रीमिंग को जबरन हटाने का क्या औचित्य है?

मुझे लगता है कि यह कुछ ऐसा था

यह प्रस्ताव डेटा स्ट्रीमिंग को समाप्त करता है। उस बिंदु पर हमारे पास वास्तव में बहुत अधिक लचीलापन नहीं है। वास्तविक दुनिया की आवश्यकता (निम्न) संबद्ध जोखिमों (जीसीएम के लिए अत्यधिक उच्च) या इसकी असंभवता (सीसीएम) के साथ संयुक्त होने का अर्थ है कि यह अभी समाप्त हो गया है।

GCM में बहुत अधिक उफ़ क्षण होते हैं जहाँ यह कुंजी पुनर्प्राप्ति की अनुमति देता है। यदि कोई हमलावर चयनित सिफरटेक्स्ट कर सकता है और टैग सत्यापन से पहले स्ट्रीमिंग आउटपुट देख सकता है, तो वे कुंजी को पुनर्प्राप्त कर सकते हैं। (या तो एक क्रिप्टोकरंसी मुझे बताता है)। प्रभावी रूप से, यदि कोई GCM-संसाधित डेटा टैग सत्यापन से पहले किसी भी बिंदु पर देखा जा सकता है तो कुंजी से छेड़छाड़ की जाती है।

मुझे पूरा यकीन है कि क्रिप्टो बोर्ड पहले परिदृश्य के लिए जीसीएम का उपयोग नहीं करने की सिफारिश करेगा, बल्कि सीबीसी + एचएमएसी।

यदि आपका दूसरा परिदृश्य 4k फ़्रेमिंग है, और आप प्रत्येक 4k फ़्रेम को एन्क्रिप्ट कर रहे हैं, तो यह इस मॉडल के साथ काम करता है। प्रत्येक 4k + गैर + टैग फ्रेम बाइट वापस पाने से पहले डिक्रिप्ट और सत्यापित हो जाता है, इसलिए आप कभी भी कीस्ट्रीम/कुंजी को लीक नहीं करते हैं।

तुलना के लिए: मैं वर्तमान में इसे विकसित कर रहा हूं "आदिम को आदिम होने दें" क्रिप्टो एपीआई। यहाँ प्रमाणित एन्क्रिप्शन के लिए मेरी कक्षा है।

मेरे लिए यह एक कुंजी के स्वतंत्र रूप से एक क्रिप्टो आदिम के बारे में बात करने में सक्षम होने के लिए उपयोगी साबित हुआ। उदाहरण के लिए, मैं अक्सर एक विशिष्ट आदिम को उस विधि में प्लग करना चाहता हूं जो किसी भी एईएडी एल्गोरिदम के साथ काम करता है और उस विधि में चाबियों आदि की पीढ़ी को छोड़ देता है। इसलिए वहाँ एक AeadAlgorithm वर्ग और एक अलग कुंजी वर्ग है।

एक और बहुत उपयोगी चीज जिसने पहले से ही कई बगों को रोका है, वह है अलग-अलग आकार के डेटा का प्रतिनिधित्व करने के लिए अलग-अलग प्रकारों का उपयोग करना, उदाहरण के लिए, एक कुंजी और एक गैर , हर चीज के लिए एक सादे byte[] या Span<byte> का उपयोग करने के बजाय।

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 वह सही है/आपको प्रमाणीकरण तक आउटपुट नहीं होने वाले प्रोग्राम पर भरोसा करने की आवश्यकता है। तो उदाहरण के लिए यदि आप प्रमाणीकरण नहीं कर रहे हैं (या अभी तक नहीं) तो आप ब्लॉक के इनपुट को नियंत्रित कर सकते हैं और इसलिए आउटपुट को जान सकते हैं और वहां से पीछे की ओर काम कर सकते हैं ...

उदाहरण के लिए मध्य हमले में एक आदमी ज्ञात ब्लॉक को सीबीसी स्ट्रीम में इंजेक्ट कर सकता है और क्लासिक बिट फ़्लिपिंग हमला कर सकता है।

सुनिश्चित नहीं है कि डेटा समस्या के बड़े हिस्से को कैसे हल किया जाए, वास्तव में उन्हें सीरियल नॉन या इसी तरह के साथ चंक करने के लिए धन्यवाद ... अला टीएलएस।

ठीक है, मुझे फिर से कहना चाहिए कि मैं करता हूं लेकिन केवल नेटवर्क छोटे आकार के मामले में जो सामान्य उद्देश्य के लिए पर्याप्त नहीं है।

खुलेपन की भावना में, क्या यह प्रकट करना संभव है कि माइक्रोसॉफ्ट क्रिप्टोग्राफी रिव्यू बोर्ड में कौन है (और आदर्श रूप से इस विषय की समीक्षा करने वाले विशिष्ट सदस्यों की टिप्पणियां/राय)? ब्रायन लामैचिया और कौन?

_विपरीत मनोविज्ञान का उपयोग करना:_

मुझे खुशी है कि AEAD की स्ट्रीमिंग समाप्त हो गई है। इसका मतलब है कि औसत जो के लिए इन्फर्नो एकमात्र व्यावहारिक CryptoStream -आधारित स्ट्रीमिंग AEAD है। धन्यवाद एमएस क्रिप्टो समीक्षा बोर्ड!

@ektrah की टिप्पणी के आधार पर, उनका (उसका?) दृष्टिकोण RFC 5116 द्वारा संचालित है, जिसका मैंने पहले उल्लेख किया है। RFC 5116 में कई उल्लेखनीय उद्धरण हैं:

3.1. गैर पीढ़ी पर आवश्यकताएँ
सुरक्षा के लिए यह आवश्यक है कि गैरों का निर्माण इस तरह से किया जाए जो इस आवश्यकता का सम्मान करता है कि कुंजी के किसी भी निश्चित मूल्य के लिए प्रमाणित एन्क्रिप्शन ऑपरेशन के प्रत्येक आह्वान के लिए प्रत्येक गैर-मूल्य अलग हो।
...

1. AEAD एल्गोरिथम विनिर्देशों पर आवश्यकताएँ
   प्रत्येक AEAD एल्गोरिथ्म को N_MIN और N_MAX ऑक्टेट के बीच की लंबाई के साथ किसी भी गैर को स्वीकार करना चाहिए, जिसमें N_MIN और N_MAX के मान उस एल्गोरिथम के लिए विशिष्ट हैं। N_MAX और N_MIN MAY के मान बराबर हो सकते हैं। प्रत्येक एल्गोरिथ्म को बारह (12) ऑक्टेट की लंबाई के साथ एक गैर को स्वीकार करना चाहिए। रैंडमाइज्ड या स्टेटफुल एल्गोरिदम, जिनका वर्णन नीचे किया गया है, में N_MAX का मान शून्य हो सकता है।
   ...
   एक प्रमाणित एन्क्रिप्शन एल्गोरिथ्म एक यादृच्छिक स्रोत को शामिल या उपयोग कर सकता है, उदाहरण के लिए, एक आंतरिक आरंभीकरण वेक्टर की पीढ़ी के लिए जिसे सिफरटेक्स्ट आउटपुट में शामिल किया गया है। इस प्रकार के AEAD एल्गोरिथम को यादृच्छिक कहा जाता है; हालांकि ध्यान दें कि केवल एन्क्रिप्शन यादृच्छिक है, और डिक्रिप्शन हमेशा नियतात्मक होता है। एक यादृच्छिक एल्गोरिथ्म में N_MAX का मान हो सकता है जो शून्य के बराबर है।

एक प्रमाणित एन्क्रिप्शन एल्गोरिथ्म आंतरिक स्थिति की जानकारी को शामिल कर सकता है जो कि एन्क्रिप्ट ऑपरेशन के आह्वान के बीच बनाए रखा जाता है, उदाहरण के लिए, अलग-अलग मूल्यों के निर्माण की अनुमति देने के लिए जो एल्गोरिदम द्वारा आंतरिक गैर के रूप में उपयोग किए जाते हैं। इस प्रकार के AEAD एल्गोरिथम को स्टेटफुल कहा जाता है। इस पद्धति का उपयोग एल्गोरिदम द्वारा अच्छी सुरक्षा प्रदान करने के लिए किया जा सकता है, तब भी जब एप्लिकेशन शून्य-लंबाई वाले गैर-इनपुट करता है। एक स्टेटफुल एल्गोरिथम MAY का मान N_MAX है जो शून्य के बराबर है।

संभावित रूप से तलाशने लायक एक विचार शून्य-लंबाई/शून्य नॉन का गुजरना है, जो कि डिफ़ॉल्ट भी हो सकता है। इस तरह के "विशेष" गैर मूल्य के पारित होने से वास्तविक गैर मूल्य यादृच्छिक हो जाएगा, जो एनक्रिप्ट के आउटपुट के रूप में उपलब्ध होगा।

यदि INonceProvider "कारण" के कारण रहता है, तो एक अन्य विचार Reset() कॉल जोड़ना है, जो हर बार AuthenticatedEncryptor को फिर से जोड़ने पर ट्रिगर हो जाएगा। यदि, दूसरी ओर, योजना कभी भी AuthenticatedEncryptor उदाहरणों को पुन: दर्ज करने की नहीं है, तो यह जीसी को मिटा देगा यदि हम एक स्ट्रीमिंग चंक-एन्क्रिप्टिंग एपीआई (उदा। चंक = नेटवर्क पैकेट) बनाना चाहते हैं, और प्रत्येक खंड होना चाहिए एक अलग कुंजी के साथ एन्क्रिप्ट किया गया (उदा। नेटफ्लिक्स एमएसएल प्रोटोकॉल, इन्फर्नो, अन्य)। विशेष रूप से समानांतर एनसी/डीसी संचालन के लिए जहां हम एईएडी इंजनों का एक पूल बनाए रखना चाहते हैं, और उस पूल से एनसी/डीसी करने के लिए उधार लेना चाहते हैं। आइए जीसी को थोड़ा प्यार दें :)

मेरे दृष्टिकोण से क्रिप्टो प्राइमेटिव्स का एकमात्र उद्देश्य अच्छी तरह से डिज़ाइन किए गए उच्च-स्तरीय सुरक्षा प्रोटोकॉल को लागू करना है। ऐसा हर प्रोटोकॉल अपने तरीके से गैर पैदा करने पर जोर देता है। उदाहरण के लिए:

• टीएलएस 1.2 आरएफसी 5116 की सिफारिशों का पालन करता है और 4-बाइट IV को 8-बाइट काउंटर के साथ जोड़ता है,
• TLS 1.3 xor का 8-बाइट काउंटर 12-बाइट IV के साथ 12 बाइट्स तक गद्देदार है,
• शोर एईएस-जीसीएम के लिए बड़े-एंडियन बाइट क्रम में 8-बाइट काउंटर पैडेड 12 बाइट्स का उपयोग करता है और चाचा/पॉली के लिए छोटे-एंडियन बाइट ऑर्डर में 8-बाइट काउंटर पैडेड 12 बाइट्स का उपयोग करता है।

सामान्य गैर आकार (96 बिट) पर यादृच्छिक गैर के लिए जीसीएम बहुत भंगुर है। और मैं किसी भी सुरक्षा प्रोटोकॉल से अवगत नहीं हूं जो वास्तव में यादृच्छिक गैर का समर्थन करता है।

क्रिप्टो प्राइमेटिव प्रदान करने वाले अधिक एपीआई की अधिक मांग नहीं है। 99.9% डेवलपर्स को सुरक्षा-संबंधी परिदृश्यों के लिए उच्च-स्तरीय व्यंजनों की आवश्यकता होती है: डेटाबेस में पासवर्ड संग्रहीत करना, फ़ाइल को आराम से एन्क्रिप्ट करना, सॉफ़्टवेयर अपडेट को सुरक्षित रूप से स्थानांतरित करना आदि।

हालांकि, ऐसे उच्च-स्तरीय व्यंजनों के लिए एपीआई दुर्लभ हैं। उपलब्ध एकमात्र एपीआई अक्सर केवल एचटीटीपीएस और क्रिप्टो प्राइमेटिव होते हैं, जो डेवलपर्स को अपने स्वयं के सुरक्षा प्रोटोकॉल रोल करने के लिए मजबूर करते हैं। आईएमओ समाधान आदिम के साथ काम करने के लिए एपीआई डिजाइन करने में बहुत प्रयास नहीं करना है। यह उच्च स्तरीय व्यंजनों के लिए एपीआई है।

प्रतिक्रिया के लिए सभी को धन्यवाद! कुछ प्रश्न:

1. जबकि स्ट्रीमिंग डिक्रिप्शन भयावह रूप से विफल हो सकता है, स्ट्रीमिंग एन्क्रिप्शन संभव हो सकता है। क्या स्ट्रीमिंग एन्क्रिप्शन (एक गैर-स्ट्रीमिंग विकल्प के साथ) लेकिन केवल गैर-स्ट्रीमिंग डिक्रिप्शन ध्वनि अधिक उपयोगी है? यदि हां, तो हल करने के लिए कुछ समस्याएं हैं:
   ए। कुछ एल्गोरिदम (CCM, SIV) वास्तव में स्ट्रीमिंग का समर्थन नहीं करते हैं। क्या हमें स्ट्रीमिंग एन्क्रिप्शन को बेस क्लास पर रखना चाहिए और स्ट्रीम किए गए इनपुट को बफर करना चाहिए या व्युत्पन्न कक्षाओं से फेंकना चाहिए?
   बी। कार्यान्वयन बाधाओं के कारण स्ट्रीमिंग एएडी संभव नहीं है, लेकिन अलग-अलग एल्गोरिदम को अलग-अलग समय पर इसकी आवश्यकता होती है (कुछ को शुरुआत में इसकी आवश्यकता होती है, कुछ को अंत तक इसकी आवश्यकता नहीं होती है)। क्या हमें इसे पहले की आवश्यकता है या इसे जोड़ने के लिए एक विधि है जो काम करता है जब व्यक्तिगत एल्गोरिदम अनुमति देता है?

1. हम INonceProvider में सुधार के लिए खुले हैं, जब तक बात यह है कि उपयोगकर्ताओं को एक नया गैर उत्पन्न करने वाला कोड लिखने की आवश्यकता होती है। क्या किसी के पास इसके लिए कोई अन्य प्रस्तावित आकार है?

1. ए = मुझे लगता है कि यह एक मुद्दा हो सकता है कि उपयोगकर्ता को जल्दी चेतावनी न दी जाए। ऊपर के किसी व्यक्ति के परिदृश्य की कल्पना करें, एक 10GB फ़ाइल। उन्हें लगता है कि वे स्ट्रीमिंग कर रहे हैं, फिर कुछ समय बाद एक और देव सिफर बदल देता है और अगली बात यह है कि कोड एक मूल्य वापस करने से पहले 10 जीबी (या कोशिश कर रहा) बफरिंग कर रहा है।

1. बी = फिर से "स्ट्रीमिंग" या नेटवर्किंग विचार के साथ, उदाहरण के लिए एईएस जीसीएम आदि आपको डिक्रिप्शन के अंत तक एएडी जानकारी नहीं मिलती है। जहां तक ​​एन्क्रिप्शन का सवाल है, मुझे अभी तक ऐसा कोई मामला नहीं दिख रहा है, जहां आपके पास पहले से डेटा नहीं है। तो मैं कहूंगा कि कम से कम एन्क्रिप्शन के लिए आपको शुरुआत में इसकी आवश्यकता होनी चाहिए, डिक्रिप्शन अधिक जटिल है।

1. मुझे लगता है कि यह वास्तव में एक गैर मुद्दा है, एक इंटरफ़ेस के माध्यम से गैर के लिए "बाइट्स" की आपूर्ति करना या सीधे न तो यहां और न ही वहां है। आप एक ही चीज़ को दोनों तरीकों से प्राप्त कर सकते हैं, मैं इसे एक आदिम के लिए बदसूरत पाता हूं, लेकिन अगर यह लोगों को रात में बेहतर नींद देता है तो मैं इसका जोरदार विरोध नहीं करता हूं। मैं इसे एक पूर्ण सौदे के रूप में बंद कर दूंगा, और अन्य मुद्दों के साथ आगे बढ़ूंगा।

विचार-विमर्श प्रक्रिया के संबंध में

@bartonjs : हम पूरे दिन बहस कर सकते हैं यदि सामुदायिक भागीदारी से रहित बंद दरवाजे के फैसले एक प्रभावी औचित्य है लेकिन हम विषय से हट जाएंगे, इसलिए मैं इसे रहने दूंगा। साथ ही, आमने-सामने या रीयल टाइम कम्युनिकेशन के बिना, मैं वहां किसी को परेशान नहीं करना चाहता।

स्ट्रीमिंग के संबंध में

1. 'स्ट्रीमिंग का मतलब एईएस-जीसीएम सुरक्षा नहीं है' तर्क

विशेष रूप से, स्टीमिंग => टैग सत्यापन से पहले कॉलर को डिक्रिप्टेड डेटा लौटाएं => कोई सुरक्षा नहीं। यह आवाज नहीं है। @bartonjs का दावा है 'चुना हुआ सिफरटेक्स्ट => वॉच आउटपुट => रिकवर की' जबकि @drawaes का दावा है 'ब्लॉक के लिए नियंत्रण इनपुट => इसलिए आउटपुट जानें => "वहां से काम करें" '

खैर, एईएस-जीसीएम में, टैग केवल एक चीज करता है, वह है अखंडता सत्यापन (छेड़छाड़ सुरक्षा)। गोपनीयता पर इसका 0 प्रभाव पड़ता है। वास्तव में, यदि आप AES-GCM से GCM/GHASH टैग प्रोसेसिंग को हटाते हैं, तो आपको बस AES-CTR मोड मिल जाता है। यह निर्माण है जो गोपनीयता पहलू को संभालता है। और सीटीआर बिट फ़्लिप के लिए लचीला है, लेकिन आप दोनों जिस तरह से जोर दे रहे हैं (कुंजी या सादे टेक्स्ट को पुनर्प्राप्त करना) किसी भी तरह से "टूटा" नहीं है क्योंकि इसका मतलब होगा कि मौलिक एईएस आदिम से समझौता किया गया है। यदि आपका क्रिप्टोएनालिस्ट (यह कौन है?) कुछ ऐसा जानता है जो हममें से बाकी लोग नहीं जानते हैं, तो उसे इसे प्रकाशित करना चाहिए। केवल एक चीज संभव है, एक हमला बिट एन को फ्लिप कर सकता है और जान सकता है कि प्लेनटेक्स्ट का बिट एन फ़्लिप किया गया था - लेकिन वे कभी नहीं जानते कि वास्तविक प्लेनटेक्स्ट क्या है।

इसलिए

1) सादा पाठ गोपनीयता हमेशा लागू की जाती है
2) अखंडता सत्यापन को केवल (स्ट्रीम के अंत तक) स्थगित कर दिया गया है और
3) किसी भी कुंजी से कभी समझौता नहीं किया जाता है।

उन उत्पादों और प्रणालियों के लिए जहां स्ट्रीमिंग मूलभूत है, अब आप कम से कम एक ट्रेडऑफ़ इंजीनियर कर सकते हैं जहां एक पल के लिए AEAD से नियमित AES एन्क्रिप्शन की ओर कदम बढ़ाया जाता है - फिर टैग सत्यापन पर AEAD में वापस कदम रखें। यह जाने के बजाय सुरक्षा को अपनाने के लिए कई नवीन अवधारणाओं को अनलॉक करता है "आप वह सब बफर करना चाहते हैं - क्या आप पागल हैं? हम एन्क्रिप्शन नहीं कर सकते!"।

सभी क्योंकि आप Encrypt और EncryptFinal (या समकक्ष) दोनों के बजाय केवल EncryptFinal को लागू करना चाहते हैं।

2. जीसीएम के लिए विशिष्ट नहीं!

अब एईएस-जीसीएम कोई जादुई जानवर नहीं है जिसमें "उफ़ मोमेंट्स" प्रचुर मात्रा में हों। यह केवल AES-CTR + GHASH है (यदि हो सके तो एक प्रकार का हैश)। गोपनीयता से संबंधित गैर-विचार CTR मोड से विरासत में मिले हैं और अखंडता से संबंधित टैग विचार विशिष्ट में अनुमत चर टैग आकारों से आते हैं। फिर भी, AES-CTR + GHASH, AES-CBC + HMAC-SHA256 जैसे कुछ के समान है, जिसमें पहला एल्गोरिथ्म गोपनीयता को संभालता है और दूसरा अखंडता को संभालता है। AES-CBC + HMAC-SHA256 में, सिफरटेक्स्ट में बिट फ़्लिप डिक्रिप्टेड टेक्स्ट (CTR के विपरीत) में संबंधित ब्लॉक को दूषित कर देगा और निम्नलिखित डिक्रिप्टेड प्लेनटेक्स्ट ब्लॉक (जैसे CTR) में निश्चित रूप से फ्लिप बिट्स भी करेगा। फिर, एक हमलावर को पता नहीं चलेगा कि परिणामी प्लेनटेक्स्ट क्या होगा - बस बिट्स फ़्लिप किए गए थे (जैसे CTR)। अंत में, अखंडता जांच (HMAC-SHA256) इसे पकड़ लेगी। लेकिन केवल अंतिम बाइट (जैसे GHASH) को संसाधित करना।

इसलिए यदि अखंडता ठीक होने तक सभी डिक्रिप्टेड डेटा को वापस रखने का आपका तर्क वास्तव में अच्छा है - इसे लगातार लागू किया जाना चाहिए। इसलिए एईएस-सीबीसी पथ से निकलने वाले सभी डेटा को एचएमएसी-एसएचए256 पास होने तक बफर (आंतरिक रूप से पुस्तकालय द्वारा) किया जाना चाहिए। इसका मूल रूप से मतलब है कि .NET पर, कोई भी स्ट्रीमिंग डेटा AEAD अग्रिमों से भी लाभ नहीं उठा सकता है। .NET स्ट्रीमिंग डेटा को डाउनग्रेड करने के लिए बाध्य करता है। कोई एन्क्रिप्शन या नियमित एन्क्रिप्शन के बीच चयन करने के लिए। कोई एईएडी नहीं। जहां बफरिंग तकनीकी रूप से अव्यावहारिक है, आर्किटेक्ट्स के पास कम से कम अंतिम उपयोगकर्ताओं को चेतावनी देने का विकल्प होना चाहिए कि "आपके लिए कोई आंखें नहीं" के बजाय "ड्रोन फुटेज भ्रष्ट हो सकता है"।

3. यह हमारे पास सबसे अच्छा है

डेटा बड़ा हो रहा है और सुरक्षा को मजबूत करने की जरूरत है। स्ट्रीमिंग भी एक रियलिटी डिजाइनरों को गले लगाना है। जब तक दुनिया वास्तव में एकीकृत AEAD एल्गोरिथम तैयार नहीं करती है, जो मूल रूप से भ्रष्टाचार के मध्य-धारा छेड़छाड़ का पता लगा सकता है, हम एन्क्रिप्शन + प्रमाणीकरण के साथ बोल्ट-ऑन-बड्डी के रूप में फंस गए हैं। ट्रू AEAD प्रिमिटिव पर शोध किया जा रहा है लेकिन हमें अभी एन्क्रिप्शन + प्रमाणीकरण मिला है।

मैं "एईएस-जीसीएम" के बारे में उतना ही कम परवाह करता हूं जितना कि मैं एक तेज, लोकप्रिय एईएडी एल्गोरिदम की परवाह करता हूं जो स्ट्रीमिंग वर्कलोड का समर्थन कर सकता है - डेटा-समृद्ध, हाइपर-कनेक्टेड दुनिया में सुपर प्रचलित है।

4. एईएस-सीबीसी-एचएमएसी का उपयोग करें, उपयोग करें (वर्कअराउंड डालें)

क्रिप्टो बोर्ड पहले परिदृश्य के लिए जीसीएम का उपयोग नहीं करने की सिफारिश करेगा, बल्कि सीबीसी + एचएमएसी।

ऊपर वर्णित सब कुछ या परिदृश्य की बारीकियों को छोड़कर - एईएस-सीबीसी-एचएमएसी का सुझाव देना मुफ़्त नहीं है। यह AES-GCM की तुलना में ~ 3x धीमा है क्योंकि AES-CBC एन्क्रिप्ट गैर-समानांतर है और चूंकि GHASH को PCLMULQDQ निर्देश के माध्यम से त्वरित किया जा सकता है। तो अगर आप एईएस-जीसीएम के साथ 1 जीबी/सेकंड पर हैं, तो अब आप एईएस-सीबीसी-एचएमएसी के साथ ~ 300 एमबी/सेकंड हिट करने जा रहे हैं। यह फिर से "क्रिप्टो आपको धीमा कर देता है, इसे छोड़ दें" मानसिकता को समाप्त करता है - एक सुरक्षा लोग लड़ने के लिए कड़ी मेहनत करते हैं।

प्रत्येक 4k फ्रेम को एन्क्रिप्ट करना

वीडियो कोडेक्स को अचानक एन्क्रिप्शन करना चाहिए? या एन्क्रिप्शन परत को अब वीडियो कोडेक को समझना चाहिए? यह डेटा सुरक्षा स्तर पर बस एक बिटस्ट्रीम है। तथ्य यह है कि यह एक वीडियो/जीनोमिक डेटा/छवियां/मालिकाना प्रारूप इत्यादि है, सुरक्षा स्तर की चिंता नहीं होनी चाहिए। एक समग्र समाधान में मुख्य जिम्मेदारियों का मेल नहीं होना चाहिए।

अस्थायी रूप से

NIST 96 बिट से अधिक लंबाई के लिए यादृच्छिक IVs की अनुमति देता है। NIST 800-38D पर खंड 8.2.2 देखें। यहां कुछ भी नया नहीं है, गैर-आवश्यकताएं सीटीआर मोड से आती हैं। जो अधिकांश स्ट्रीम सिफर में भी काफी मानक है । मैं गैर के प्रति अचानक भय को नहीं समझता - यह हमेशा number used once रहा है। फिर भी, इसलिए जबकि INonce बहस एक भद्दे इंटरफ़ेस के लिए बनाती है, कम से कम यह नो-स्ट्रीम-फॉर-यू थोपने जैसे नवाचार को समाप्त नहीं करता है। अगर हम AEAD सुरक्षा + स्ट्रीमिंग वर्कलोड इनोवेशन प्राप्त कर सकते हैं तो मैं किसी भी दिन INonce को स्वीकार करूंगा। मुझे इनोवेशन स्ट्रीमिंग जैसी बुनियादी चीज़ों को कॉल करने से नफरत है - लेकिन मुझे डर है कि हम पीछे हट जाएंगे।

मुझे गलत साबित होना अच्छा लगेगा

मैं सिर्फ एक लड़का हूं जिसने काम पर एक लंबे दिन के बाद अपने बच्चों के साथ मूवी रात को टाइप करने के लिए छोड़ दिया। मैं थक गया हूँ और गलत हो सकता है। लेकिन उपाख्यानों या "समिति कारणों" या कुछ अन्य जादू के बजाय कम से कम एक खुला तथ्य आधारित सामुदायिक संवाद होना चाहिए। मैं सुरक्षित .NET और Azure नवाचारों को बढ़ावा देने के व्यवसाय में हूँ। मुझे लगता है कि हमारे पास संरेखित लक्ष्य हैं।

सामुदायिक संवाद की बात हो रही है ...

क्या हम कृपया एक समुदाय स्काइप कॉल कर सकते हैं? इस तरह के एक जटिल विषय को व्यक्त करने से पाठ की एक विशाल दीवार बन जाती है। मान जाओ ना?

कृपया स्काइप कॉल न करें - यही "क्लोज्ड डोर मीटिंग" की परिभाषा है, जिसमें समुदाय के लिए कोई रिकॉर्ड उपलब्ध नहीं है। सभी पक्षों के लिए नागरिक दस्तावेजी प्रवचन (एमएस-टिप्पणी-निष्कासन उदाहरणों को अनदेखा करना) के लिए जीथब मुद्दे सही वाहन हैं।

एमएस क्रिप्टो रिव्यू बोर्ड ने शायद स्काइप कॉल भी किया था। यह इस धागे में भाग लेने वाले एमएस लोगों की गलती नहीं है - एमएस क्रिप्टो रिव्यू बोर्ड (जो भी/जो भी है) के हाथीदांत टावरों पर उनके पास बहुत सीमित पहुंच और अनुनय शक्ति है।

AEAD स्ट्रीमिंग के संबंध में:

जीसीएम, सीटीआर+एचएमएसी जैसे मैक-अंतिम मोड के लिए बाइट-साइज़ स्ट्रीमिंग _एन्क्रिप्शन_ संभव है, लेकिन सीसीएम जैसे मैक-प्रथम मोड के लिए संभव नहीं है। बाइट-साइज़ स्ट्रीमिंग _decryption_ मौलिक रूप से लीक हो रही है और इसलिए किसी के द्वारा इस पर विचार नहीं किया जाता है। CBC+HMAC के लिए ब्लॉक-साइज़ स्ट्रीमिंग _encryption_ भी संभव है, लेकिन इससे कुछ भी नहीं बदलता है। अर्थात। AEAD स्ट्रीमिंग के लिए बाइट-आकार या ब्लॉक-आकार के दृष्टिकोण त्रुटिपूर्ण हैं।

चंक-साइज़ स्ट्रीमिंग _एन्क्रिप्शन_ और _डिक्रिप्शन_ बढ़िया काम करते हैं, लेकिन उनकी 2 बाधाएं हैं:

• उन्हें बफरिंग (परे-ब्लॉक-आकार) की आवश्यकता होती है। यह लाइब्रेरी/एपीआई द्वारा किया जा सकता है यदि बफरिंग को नियंत्रित/कैप्ड किया जाता है (उदा। इन्फर्नो), या इससे निपटने के लिए ऊपरी परत (कॉलिंग परत) पर छोड़ दिया जाता है। किसी भी तरह से काम करता है।

• खंडित स्ट्रीमिंग AEAD मानकीकृत नहीं है। भूतपूर्व। नैक-स्ट्रीम , इन्फर्नो, एमएस-ओन डेटाप्रोटेक्शन, मेक-योर-ओन।

यह इस बात का सारांश है कि इस चर्चा में शामिल सभी लोग पहले से ही क्या जानते हैं।

@sdrapkin , यह सुनिश्चित करने के लिए कि मैं ठीक से समझता हूं, क्या आप इस एपीआई के साथ स्ट्रीमिंग एन्क्रिप्शन प्रदान करने के लिए ठीक हैं, लेकिन कोई स्ट्रीमिंग डिक्रिप्शन नहीं है?

@sdrapkin अच्छी तरह से, वास्तविक समय में दिमागी तूफान निश्चित रूप से फायदेमंद है, रिकॉर्ड रखने की चिंताओं को मीटिंग मिनटों के साथ हल किया जा सकता है। तकनीकी पक्ष पर वापस, जबकि चंकिंग स्ट्रीमिंग डिक्रिप्शन के लिए काम करता है, यह निम्न स्तर की सुरक्षा आदिम नहीं है। यह एक कस्टम प्रोटोकॉल है। और आपके जैसा एक गैर-मानक एक नोट किया।

@morganbr

_क्या आप स्ट्रीमिंग एन्क्रिप्शन प्रदान करने वाले इस एपीआई के साथ ठीक हैं, लेकिन कोई स्ट्रीमिंग डिक्रिप्शन नहीं है?_

नहीं, मैं नहीं हूँ। यदि ऐसा एपीआई उपलब्ध होता, तो एक आकार का स्ट्रीम-एन्क्रिप्टेड सिफरटेक्स्ट बनाना आसान होता, जिसे कोई बफर-डिक्रिप्शन (मेमोरी से बाहर) डिक्रिप्ट करने में सक्षम नहीं होगा।

^^^^ यह, अब तक बहुत अधिक समझौता नहीं हुआ है, लेकिन मुझे लगता है कि हम सभी सहमत हो सकते हैं कि किसी भी तरह से यह एक असममित एपीआई एक आपदा होगी। दोनों "अरे थे स्ट्रीम डिक्रिप्ट विधियां हैं जिन्हें मैंने सोचा था कि मैं भरोसा करूंगा क्योंकि एन्क्रिप्टेड विधियां थीं", और उपरोक्त @sdrapkin टिप्पणियों के कारण।

@Drawaes सहमत हुए। असममित एनसी/डीसी एपीआई भयानक होगा।

कोई अपडेट दोस्तों?

जाहिर तौर पर मैंने कुछ हमलों का सामना किया।

स्ट्रीम सिफर (जो एईएस-सीटीआर और एईएस-जीसीएम हैं) में निहित कमजोरियां मनमाने ढंग से प्लेनटेक्स्ट रिकवरी की अनुमति देने के लिए चुने हुए सिफरटेक्स्ट हमलों की अनुमति देती हैं। चुने हुए सिफरटेक्स्ट हमलों से बचाव प्रमाणीकरण है; इसलिए एईएस-जीसीएम प्रतिरक्षा है ... जब तक कि आप स्ट्रीमिंग डिक्रिप्शन नहीं कर रहे हैं और आप साइड-चैनल अवलोकनों से पहचान सकते हैं कि सादा पाठ क्या होता। उदाहरण के लिए, यदि डिक्रिप्टेड डेटा को एक्सएमएल के रूप में संसाधित किया जा रहा है तो यह बहुत जल्दी विफल हो जाएगा यदि व्हाइटस्पेस या < के अलावा अन्य वर्ण डिक्रिप्ट किए गए डेटा की शुरुआत में हैं। तो यह "स्ट्रीमिंग डिक्रिप्शन स्ट्रीम सिफर डिज़ाइन के साथ चिंताओं को फिर से पेश करता है" (जो, आपने देखा होगा, .NET में से कोई भी नहीं है)।

यह देखने के लिए कि कुंजी पुनर्प्राप्ति कहां से आ रही थी, प्रमाणीकरण जैसे कागजात हैंजीसीएम (फर्ग्यूसन/माइक्रोसॉफ्ट) में कमजोरियां हैं , लेकिन वह छोटे टैग आकारों के आधार पर प्रमाणीकरण कुंजी को पुनर्प्राप्त कर रहा है (जो कि विंडोज कार्यान्वयन केवल 96-बिट टैग की अनुमति देता है)। मुझे शायद अन्य प्रमाणीकरण कुंजी रिकवरी वैक्टर के बारे में सलाह दी गई थी कि जीसीएम स्ट्रीमिंग खतरनाक क्यों है।

पहले की एक टिप्पणी में @sdrapkin ने उल्लेख किया "बाइट-साइज़ स्ट्रीमिंग डिक्रिप्शन मौलिक रूप से लीक हो रहा है और इसलिए किसी के द्वारा इस पर विचार नहीं किया जाता है। ... AEAD स्ट्रीमिंग के लिए बाइट-आकार या ब्लॉक-आकार के दृष्टिकोण त्रुटिपूर्ण हैं।"। सीसीएम (और एसआईवी) के साथ संयुक्त रूप से स्ट्रीमिंग एन्क्रिप्शन करने में सक्षम नहीं है और इसकी टिप्पणी एक स्ट्रीमिंग के लिए अजीब होगी और दूसरी नहीं, यह सुझाव देता है कि हम केवल एक-शॉट एन्क्रिप्ट होने के प्रस्ताव पर वापस आ गए हैं और डिक्रिप्ट

तो ऐसा लगता है कि हम अपने पिछले एपीआई प्रस्ताव पर वापस आ गए हैं (https://github.com/dotnet/corefx/issues/23629#issuecomment-329202845)। जब तक कि अन्य बकाया मुद्दे न हों जिन्हें मैं कुछ समय के लिए भूलने में कामयाब रहा।

वापस स्वागत है @bartonjs

मैं जल्द ही सोने जा रहा हूँ लेकिन संक्षेप में:

1. हमने इस थ्रेड पर पहले प्रोटोकॉल डिज़ाइन को आदिम डिज़ाइन के साथ जोड़ा है। मैं सिर्फ इतना कहूंगा कि चुने हुए सिफरटेक्स्ट हमले एक प्रोटोकॉल डिजाइन चिंता है, न कि एक आदिम चिंता।

2. स्ट्रीमिंग AEAD डिक्रिप्शन आपको कम से कम गोपनीयता रखने की अनुमति देता है और फिर तुरंत अंतिम बाइट पर गोपनीयता + प्रामाणिकता में अपग्रेड करता है। AEAD (यानी केवल पारंपरिक गोपनीयता) पर स्ट्रीमिंग समर्थन के बिना, आप स्थायी रूप से लोगों को एक निम्न, गोपनीयता केवल आश्वासन तक सीमित कर रहे हैं।

यदि तकनीकी गुण अपर्याप्त हैं या आप (सही) मेरे तर्कों की प्रामाणिकता पर संदेह कर रहे हैं, तो मैं बाहरी प्राधिकरण मार्ग का प्रयास करूंगा। आपको पता होना चाहिए कि आपका वास्तविक अंतर्निहित कार्यान्वयन स्ट्रीमिंग मोड में AEAD (AES GCM सहित) का समर्थन करता है। विंडोज कोर ओएस ( bcrypt ) BCryptEncrypt या BCryptDecrypt फ़ंक्शन के माध्यम से GCM को स्ट्रीम करने की अनुमति देता है। वहां dwFlags देखें। या एक उपयोगकर्ता कोड उदाहरण । या एक माइक्रोसॉफ्ट ने सीएलआर रैपर लिखा है। या कि कार्यान्वयन NIST FIP-140-2 को हाल ही में इस वर्ष की शुरुआत की तरह प्रमाणित किया गया है। या कि माइक्रोसॉफ्ट और एनआईएसटी दोनों ने एईएस कार्यान्वयन के आसपास महत्वपूर्ण संसाधन खर्च किए और इसे यहां और यहां प्रमाणित किया। और इन सबके बावजूद, किसी ने भी आदिमों को दोष नहीं दिया है। इसका कोई मतलब नहीं है कि .NET कोर अचानक चारों ओर आ जाए और शक्तिशाली अंतर्निहित कार्यान्वयन को कम करने के लिए अपनी खुद की क्रिप्टो-थीसिस लागू करे। खासकर जब स्ट्रीमिंग और वन-शॉट दोनों का एक साथ समर्थन किया जा सकता है, बहुत मामूली रूप से।

अधिक? खैर, ऊपर यह ओपनएसएसएल के लिए सच है, यहां तक ​​​​कि उनके 'नए' ईवीपी एपीआई के साथ भी।

और यह बाउंसीकैसल के लिए सच है।

और यह जावा क्रिप्टोग्राफी आर्किटेक्चर के साथ सच है।

चीयर्स!
सिड

@sidshetye ++10 अगर क्रिप्टोबोर्ड इतना चिंतित है तो वे विंडोज़ सीएनजी को ऐसा क्यों करने देते हैं?

यदि आप Microsoft के NIST FIPS-140-2 AES सत्यापन (उदा. # 4064 ) की जाँच करते हैं, तो आप निम्नलिखित पर ध्यान देंगे:

एईएस-जीसीएम:

• सादा पाठ लंबाई: 0, 8, 1016, 1024
• एएडी की लंबाई: 0, 8, 1016, 1024

एईएस-सीसीएम:

• सादा पाठ लंबाई: 0-32
• एएडी लंबाई: 0-65536

स्ट्रीमिंग के लिए कोई सत्यापन नहीं है। मुझे यह भी यकीन नहीं है कि एनआईएसटी उस पूर्व की जांच करता है या नहीं। AES-GCM कार्यान्वयन को 64Gb से अधिक प्लेनटेक्स्ट (GCM की एक और हास्यास्पद सीमा) को एन्क्रिप्ट करने की अनुमति नहीं दी जानी चाहिए।

मैं स्ट्रीमिंग के लिए बड़े पैमाने पर शादी नहीं कर रहा हूं क्योंकि मेरा उपयोग 16k से अधिक की सवारी नहीं करना चाहिए, हालांकि खंडित बफर अच्छे होंगे और इसमें कोई जोखिम नहीं होना चाहिए (मुझे वास्तव में संदेह है कि सीएनजी ने इसका इंटरफ़ेस ठीक उसी तरह से बनाया है जिस तरह से यह उस उद्देश्य के लिए है) ... उदाहरण के लिए मैं कई स्पैन या समान (उदाहरण के लिए लिंक्ड सूची) में पास करने में सक्षम होना चाहता हूं और इसे एक ही बार में डिक्रिप्ट करना चाहता हूं। यदि यह एक सन्निहित बफर को डिक्रिप्ट करता है तो यह ठीक है।

तो मुझे लगता है कि "स्ट्रीमिंग स्टाइल" एपीआई पर छायादार क्रिप्टो बोर्ड को स्थानांतरित करना अभी के लिए नहीं है, तो चलिए आगे बढ़ते हैं एक शॉट एपीआई बनाते हैं। एक एपीआई के विस्तार की गुंजाइश हमेशा होती है यदि पर्याप्त लोग बाद में आवश्यकता दिखाते हैं

@sdrapkin मुद्दा यह है कि यह स्ट्रीमिंग एपीआई है जो एनआईएसटी लैब्स और एमएसएफटी द्वारा व्यापक समीक्षा के माध्यम से चला गया है। प्रत्येक बिल्ड को मान्य किया जा रहा है $80,000 - $50,000 के बीच और MSFT (और OpenSSL और Oracle और अन्य क्रिप्टो हैवीवेट) ने इन एपीआई और कार्यान्वयन को 10 से अधिक वर्षों के लिए मान्य करने में भारी निवेश किया है। आइए परीक्षण योजना के विशिष्ट सादे-पाठ आकारों से विचलित न हों क्योंकि मुझे विश्वास है कि .NET स्ट्रीमिंग या एक-शॉट की परवाह किए बिना 0, 8, 1016, 1024 के अलावा अन्य आकारों का समर्थन करेगा। मुद्दा उन सभी युद्ध-परीक्षणित एपीआई (शाब्दिक रूप से; हथियार समर्थन प्रणालियों पर) है, इन सभी प्लेटफार्मों पर क्रिप्टो-आदिम एपीआई स्तर पर एईएडी स्ट्रीमिंग का समर्थन करता है। दुर्भाग्य से, इसके खिलाफ अब तक का हर तर्क क्रिप्टो-आदिम स्तर पर छद्म-चिंता के रूप में उद्धृत एक आवेदन या प्रोटोकॉल स्तर की चिंता रहा है।

मैं सभी 'सर्वश्रेष्ठ विचार जीतने' के लिए हूं, लेकिन जब तक .net कोर क्रिप्टो टीम (एमएसएफटी या समुदाय) के पास कुछ महत्वपूर्ण खोज नहीं है, मुझे नहीं लगता कि हर कोई क्रिप्टो कर रहा है, सभी अलग-अलग संगठनों से गलत हैं और वे सही हैं।

पुनश्च: मुझे पता है कि हम यहां असहमति में हैं लेकिन हम सभी चाहते हैं कि मंच और उसके ग्राहकों के लिए सबसे अच्छा क्या है।

@Drawaes जब तक AEAD इंटरफ़ेस (जरूरी नहीं कि कार्यान्वयन) आज परिभाषित किया जा रहा है, स्ट्रीमिंग एपीआई सतह का समर्थन करता है, मैं नहीं देखता कि लोग दो इंटरफेस या कस्टम इंटरफेस के बिना इसे कैसे बढ़ा सकते हैं। यह एक आपदा होगी। मुझे उम्मीद है कि यह चर्चा एक ऐसे इंटरफ़ेस की ओर ले जाती है जो भविष्य का प्रमाण है (या बहुत कम, अन्य एईएडी इंटरफेस को दर्पण करता है जो कई सालों से आसपास रहे हैं!)।

मैं सहमत होने की प्रवृत्ति रखता हूं। लेकिन यह मुद्दा कहीं तेजी से नहीं जा रहा है और जब ऐसा होता है तो हम एक संकट बिंदु पर पहुंचने की संभावना रखते हैं या तो यह इसे 2.1 के लिए नहीं बना पाएगा या इसे हल करने के लिए कोई समय नहीं बचेगा। मैं ईमानदारी से कहूँगा कि मैं अपने पुराने रैपर्स पर वापस चला गया हूँ और 2.0 के लिए बस उन्हें नया रूप दे रहा हूँ;)

हमारे पास जावा , ओपनएसएसएल या सी # बाउंसी कैसल या सीएलआर सुरक्षा के लिए कुछ संदर्भ एपीआई हैं। स्पष्ट रूप से उनमें से कोई भी करेगा और दीर्घकालिक, मैं चाहता हूं कि सी # में जावा के 'जावा क्रिप्टोग्राफी आर्किटेक्चर' जैसा कुछ हो, जहां सभी क्रिप्टो कार्यान्वयन एक अच्छी तरह से स्थापित इंटरफेस के खिलाफ हों, जिससे उपयोगकर्ता कोड को प्रभावित किए बिना क्रिप्टो पुस्तकालयों को स्वैप करने की इजाजत मिलती है।

यहाँ वापस, मुझे लगता है कि यह सबसे अच्छा है कि हम .NET कोर के ICryptoTransform इंटरफ़ेस का विस्तार करें:

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

यदि हम Span सभी byte[] s को लागू कर रहे हैं, तो समग्र स्थिरता के लिए System.Security.Cryptography नेमस्पेस में संपूर्ण API को पार करना चाहिए।

संपादित करें: फिक्स्ड जेसीए लिंक

यदि हम सभी बाइट [] एस को स्पैनिंग कर रहे हैं, तो इसे सिस्टम में संपूर्ण एपीआई को पार करना चाहिए। सुरक्षा। क्रिप्टोग्राफी नेमस्पेस समग्र स्थिरता के लिए।

हमने पहले ही ऐसा कर लिया था। ICryptoTransform को छोड़कर सब कुछ, क्योंकि हम इंटरफेस नहीं बदल सकते।

मुझे लगता है कि यह सबसे अच्छा है कि हम .NET कोर के ICryptoTransform का विस्तार करें ...

इसके साथ समस्या यह है कि अंत में टैग प्राप्त करने के साथ कॉलिंग पैटर्न बहुत अजीब है (विशेषकर यदि क्रिप्टोस्ट्रीम शामिल है)। मैंने इसे मूल रूप से लिखा था, और यह बदसूरत था। इनमें से किसी एक को कैसे प्राप्त किया जाए, इसकी भी समस्या है, क्योंकि जीसीएम पैरामीटर सीबीसी/ईसीबी पैरामीटर से अलग हैं।

तो, यहाँ मेरे विचार हैं।

• स्ट्रीमिंग डिक्रिप्शन एई के लिए खतरनाक है।
• सामान्य तौर पर, मैं "मुझे आदिम दे दो, और मुझे अपने जोखिम का प्रबंधन करने दो" का प्रशंसक हूं।
• मैं भी ".NET का प्रशंसक हूं (आसानी से) पूरी तरह से असुरक्षित चीजों की अनुमति नहीं देनी चाहिए, क्योंकि यह इसके कुछ मूल्य प्रस्ताव हैं"
• अगर, जैसा कि मैंने मूल रूप से गलत समझा, GCM डिक्रिप्शन को बुरी तरह से करने के जोखिम इनपुट कुंजी रिकवरी थे तो मैं अभी भी "यह बहुत असुरक्षित है" पर होगा। (.NET और अन्य सभी चीज़ों के बीच का अंतर "ऐसा करने में अधिक समय लगने से दुनिया ने और अधिक सीखा है")
• लेकिन, चूंकि ऐसा नहीं है, अगर आप वाकई चाहते हैं कि प्रशिक्षण के पहिये बंद हो जाएं, तो मुझे लगता है कि मैं उस धारणा का मनोरंजन करूंगा।

उस अंत तक मेरे काफी कच्चे विचार (मौजूदा सुझावों में जोड़ना, इसलिए एक-शॉट बना रहता है, हालांकि मुझे लगता है कि एक सार के बजाय वर्चुअल डिफ़ॉल्ट इम्प्लांट के रूप में):

```सी#
आंशिक वर्ग प्रमाणीकृतएन्क्रिप्टर
{
// फेंकता है अगर कोई ऑपरेशन पहले से ही चल रहा है
सार्वजनिक सार शून्य प्रारंभ करें (केवल पढ़ने के लिए)संबद्ध डेटा);
// सफलता पर सच, "गंतव्य बहुत छोटा" पर झूठा, किसी और चीज पर अपवाद।
सार्वजनिक सार बूल TryEncrypt(ReadOnlySpanडेटा, स्पैनएन्क्रिप्टेडडेटा, इंट बाइट्स से बाहर, इंट बाइट्स से बाहर);
// असत्य यदि शेष एन्क्रिप्टेडडेटा बहुत छोटा है, तो फेंकता है यदि अन्य इनपुट बहुत छोटे हैं, तो NonceOrIVSizeInBits और TagSizeInBits गुण देखें।
// NonceOrIvUsed को इनिशियलाइज़ करने के लिए स्थानांतरित किया जा सकता है, लेकिन फिर इसे एक इनपुट के रूप में व्याख्यायित किया जा सकता है।
सार्वजनिक सार बूल ट्राईफिनिश (केवल पढ़ने के लिए)शेष डेटा, स्पैनशेषएन्क्रिप्टेडडेटा, आउट इंट बाइट्सलिखित, स्पैनटैग, स्पैनnonceOrIvUsed);
}

आंशिक वर्ग प्रमाणीकृतडिक्रिप्टर
{
// फेंकता है अगर कोई ऑपरेशन पहले से ही चल रहा है
सार्वजनिक सार शून्य प्रारंभ करें (केवल पढ़ने के लिए)टैग, ReadOnlySpannonceOrIv, ReadOnlySpanसंबद्ध डेटा);
// सफलता पर सच, "गंतव्य बहुत छोटा" पर झूठा, किसी और चीज पर अपवाद।
सार्वजनिक सार बूल TryDecrypt(ReadOnlySpanडेटा, स्पैनडिक्रिप्टेडडेटा, आउट इंट बाइट्सरीड, आउट इंट बाइट्सराइट);
// खराब टैग पर फेंकता है, लेकिन वैसे भी डेटा लीक कर सकता है।
// (शेष डिक्रिप्टेडडेटा सीबीसी + एचएमएसी के लिए आवश्यक है, और इसलिए शेष डेटा भी जोड़ सकता है, मुझे लगता है?)
सार्वजनिक सार बूल ट्राईफिनिश (केवल पढ़ने के लिए)शेष डेटा, स्पैनशेष डिक्रिप्टेडडेटा, इंट बाइट्स से बाहर);
}
```

एसोसिएटेडडाटा इनिशियलाइज़ पर आता है, क्योंकि जिन एल्गोरिदम को इसकी आवश्यकता होती है, वे उस पर पकड़ बना सकते हैं, और जिन एल्गोरिदम को पहले इसकी आवश्यकता होती है, उनके पास इसका कोई अन्य तरीका नहीं हो सकता है।

एक बार एक आकार तय हो जाता है कि स्ट्रीमिंग कैसी दिखेगी (और क्या लोगों को लगता है कि CCM को आंतरिक रूप से बफर करना चाहिए, या फेंक देना चाहिए, जब स्ट्रीमिंग एन्क्रिप्शन मोड में हो) तो मैं बोर्ड पर वापस जाऊंगा।

@bartonjs मुझे पता है कि एन्क्रिप्ट/डिक्रिप्ट में समरूपता के लिए स्ट्रीम के अंत से टैग को प्लकिंग और प्रोग्रामिंग के बारे में आपका क्या मतलब है। यह मुश्किल है लेकिन इससे भी बदतर अगर प्रत्येक उपयोगकर्ता को हल करने के लिए छोड़ दिया जाए। मेरे पास एक कार्यान्वयन है जिसे मैं एमआईटी के तहत साझा कर सकता हूं; मेरी टीम के साथ आंतरिक रूप से देखने की आवश्यकता होगी (मेरे डेस्क/मोबाइल पर नहीं)

एक बीच का मैदान ओपनएसएसएल या एनटी के बीक्रिप्ट जैसा हो सकता है जहां आपको अंतिम डिक्रिप्ट कॉल से ठीक पहले टैग को प्लग करने की आवश्यकता होती है, जब टैग की तुलना होती है। यानी एक SetExpectedTag (अंतिम डिक्रिप्ट से पहले) और GetTag (अंतिम एन्क्रिप्ट के बाद) काम करेगा लेकिन उपयोगकर्ता को टैग प्रबंधन को ऑफलोड कर देगा। अधिकांश केवल टैग को सिफरस्ट्रीम में जोड़ देंगे क्योंकि यह प्राकृतिक अस्थायी क्रम है।

मुझे लगता है कि Initialize में टैग की अपेक्षा करना (डिक्रिप्ट में) अंतरिक्ष में समरूपता (बाइट प्रवाह) और समय (अंत में टैग जांच, प्रारंभ नहीं) को तोड़ता है जो इसकी उपयोगिता को सीमित करता है। लेकिन उपरोक्त टैग एपीआई इसका समाधान करते हैं।

एन्क्रिप्ट के लिए भी, Initialize को किसी भी क्रिप्टो ट्रांसफॉर्म से पहले IV की आवश्यकता होती है।

अंत में, एन्क्रिप्ट और डिक्रिप्ट के लिए, Initialize को किसी भी परिवर्तन से पहले एईएस एन्क्रिप्शन कुंजी की आवश्यकता होती है। (मुझे कुछ स्पष्ट याद आ रहा है या आप उस बिट को टाइप करना भूल गए हैं?)

मुझे लगता है कि इनिशियलाइज़ में टैग की अपेक्षा करना (डिक्रिप्ट में) समरूपता को तोड़ता है

CBC+HMAC में किसी भी डिक्रिप्शन को शुरू करने से पहले HMAC को सत्यापित करने की सामान्य सिफारिश है, इसलिए यह एक टैग-फर्स्ट डिक्रिप्शन एल्गोरिथम है। इसी तरह, एक "शुद्ध एई" एल्गोरिदम हो सकता है जो गणना के दौरान टैग पर विनाशकारी संचालन करता है और केवल यह जांचता है कि अंतिम उत्तर 0 था। इसलिए, संबंधित डेटा मान की तरह, चूंकि एल्गोरिदम हो सकते हैं जिन्हें पहले इसकी आवश्यकता होती है, यह है पूरी तरह से सामान्यीकृत एपीआई में पहले आने के लिए।

उन्हें SetAssociatedData और SetTag में फ़्लोट करना समस्या है कि बेस क्लास एल्गोरिदम-स्वतंत्र होने पर, उपयोग एल्गोरिदम-निर्भर हो जाता है। AesGcm को AesCbcHmacSha256 या SomeTagDesctructiveAlgorithm में बदलने से अब TryDecrypt थ्रो हो जाएगा क्योंकि टैग अभी तक प्रदान नहीं किया गया था। मेरे लिए यह पॉलिमॉर्फिक नहीं होने से भी बदतर है, इसलिए लचीलेपन की अनुमति मॉडल को तोड़ने के अलावा प्रति एल्गोरिदम पूरी तरह से अलग होने का सुझाव देती है। (हां, इसे NeedsTagFirst जैसे अधिक एल्गोरिदम पहचान विशेषता गुणों द्वारा नियंत्रित किया जा सकता है, लेकिन यह वास्तव में इसका उपयोग करना कठिन होता है)

एन्क्रिप्ट के लिए भी, किसी भी क्रिप्टो ट्रांसफॉर्म से पहले प्रारंभिक को IV की आवश्यकता होती है।

अंत में, एन्क्रिप्ट और डिक्रिप्ट के लिए, किसी भी परिवर्तन से पहले प्रारंभ को एईएस एन्क्रिप्शन कुंजी की आवश्यकता होती है।

कुंजी एक वर्ग ctor पैरामीटर था। IV/nonce ctor पैरामीटर में IV/nonce प्रदाता से आता है।

प्रदाता मॉडल SIV को हल करता है, जहां एन्क्रिप्ट के दौरान कोई IV नहीं दिया जाता है, एक डेटा की ओर से उत्पन्न होता है। अन्यथा SIV के पास पैरामीटर है और इसके लिए आवश्यक है कि एक खाली मान प्रदान किया जाए।

या आप उस बिट को टाइप करना भूल गए?

स्ट्रीमिंग विधियों को मेरे मौजूदा प्रस्ताव में जोड़ा जा रहा था, जिसमें पहले से ही कुंजी और IV/गैर प्रदाता सीटीआर पैरामीटर के रूप में था।

@bartonjs : अच्छी बात यह है कि कुछ एल्गो पहले टैग चाहते हैं जबकि अन्य अंत में और अनुस्मारक के लिए धन्यवाद कि यह मूल कल्पना के अतिरिक्त है। मैंने पाया कि उपयोग के मामले पर विचार करना आसान बनाता है, इसलिए यहां क्लाउड-पहला उदाहरण है:

हम भंडारण में रखी गई एक या अधिक 10GB AES-GCM एन्क्रिप्टेड फ़ाइलों (अर्थात सिफरटेक्स्ट के बाद टैग) पर विश्लेषण करने जा रहे हैं। एक एनालिटिक्स का कार्यकर्ता समवर्ती रूप से कई इनबाउंड स्ट्रीम को अलग मशीन/क्लस्टर में डिक्रिप्ट करता है और अंतिम बाइट + टैग जांच के बाद, प्रत्येक विश्लेषण कार्यभार शुरू करता है। सभी स्टोरेज, वर्कर, एनालिटिक्स VMs Azure US-West में हैं।

यहां, प्रत्येक स्ट्रीम के अंत में टैग लाने और उसे AuthenticatedDecryptor की Initialize विधि में प्रदान करने का कोई तरीका नहीं है। इसलिए यदि कोई उपयोगकर्ता GCM उपयोग के लिए कोड को संशोधित करने के लिए स्वेच्छा से काम करता है, तो भी वे API का उपयोग शुरू नहीं कर सकते हैं।

इसके बारे में सोचने के लिए आओ, हमारे पास एक एपीआई हो सकता है जो विभिन्न एईएडी को समायोजित करता है और कोई उपयोगकर्ता कोड परिवर्तन नहीं होता है, अगर विभिन्न एईएडी एल्गोरिदम के लिए क्रिप्टो प्रदाता ऑटो-जादुई रूप से टैग को संभालते हैं। जावा जीसीएम के लिए सिफरटेक्स्ट के अंत में टैग लगाकर ऐसा करता है और उपयोगकर्ता के हस्तक्षेप के बिना डिक्रिप्टिंग के दौरान इसे बाहर निकाल देता है। इसके अलावा, जब भी कोई व्यक्ति एल्गोरिथम को महत्वपूर्ण रूप से बदलता है (जैसे सीबीसी-एचएमएसी => जीसीएम) तो उन्हें टैग-फर्स्ट और टैग-लास्ट प्रोसेसिंग की परस्पर अनन्य प्रकृति के कारण अपने कोड को संशोधित करना होगा।

आईएमएचओ, हमें पहले यह तय करना चाहिए कि क्या

विकल्प 1) एल्गोरिदम प्रदाता आंतरिक रूप से टैग प्रबंधन (जैसे जावा) को संभालते हैं

या

विकल्प 2) एपीआई पर पर्याप्त एक्सपोज करें ताकि उपयोगकर्ता इसे स्वयं कर सकें (जैसे WinNT bcrypt या openssl)

विकल्प 1 वास्तव में पुस्तकालय उपभोक्ताओं के लिए समग्र अनुभव को सरल करेगा क्योंकि बफर प्रबंधन जटिल हो सकता है। इसे पुस्तकालय में अच्छी तरह से हल करें और प्रत्येक उपयोगकर्ता को इसे हर बार हल करने की आवश्यकता नहीं होगी। साथ ही सभी AEAD को समान इंटरफ़ेस (टैग-प्रथम, टैग-अंतिम, टैग-रहित) मिलता है और एल्गोरिदम को स्वैप करना भी सरल है।

मेरा वोट विकल्प 1 के लिए होगा।

अंत में, हम GCM पर ICryptoTransform स्ट्रीमिंग संचालन की अनुमति देकर अपने कार्यान्वयन को खोदने में सक्षम थे ताकि टैग इन-स्ट्रीम स्रोत को स्वचालित रूप से हटा दिया जा सके। यह सीएलआर सिक्योरिटी के अपने रैपर के लिए एक महत्वपूर्ण अपडेट था और अतिरिक्त बफर प्रतियों के बावजूद यह अभी भी वास्तव में तेज़ है (विंडोज 10 बूटकैंप में हमारे टेस्ट मैकबुक प्रो पर ~ 4 ​​जीबी/सेकंड)। हमने मूल रूप से अपने लिए विकल्प 1 बनाने के लिए सीएलआर सुरक्षा के चारों ओर लपेटा है, इसलिए हमें इसे हर जगह करने की आवश्यकता नहीं है। यह दृश्य वास्तव में यह समझाने में मदद करता है कि ICryptoTransform इंटरफ़ेस के TransformBlock और TransformFinalBlock के भीतर क्या हो रहा है।

@sidshetye मुझे यकीन नहीं है कि आपका क्लाउड-पहला उदाहरण क्यों अवरुद्ध है। यदि आप स्टोरेज से पढ़ रहे हैं तो आप पहले अंतिम कुछ टैग बाइट्स डाउनलोड कर सकते हैं और डिक्रिप्टर सीटीआर को प्रदान कर सकते हैं। यदि Azure संग्रहण API का उपयोग कर रहे हैं तो यह CloudBlockBlob.DownloadRangeXxx के माध्यम से पूरा किया जाएगा।

@GrabYourPitchforks उस उदाहरण पर बहुत अधिक विचलित नहीं होना चाहिए, लेकिन यह Azure Blob Storage की एक विशिष्ट क्षमता है। सामान्य तौर पर, VM आधारित संग्रहण (IaaS) या गैर-Azure संग्रहण वर्कलोड को आमतौर पर एक नेटवर्क स्ट्रीम मिलती है जो खोजने योग्य नहीं होती है।

मैं, व्यक्तिगत रूप से, @GrabYourPitchforks को देखने के लिए बहुत उत्साहित हूं - याय!

हम भंडारण में रखी गई एक या अधिक 10GB AES-GCM एन्क्रिप्टेड फ़ाइलों (अर्थात सिफरटेक्स्ट के बाद टैग) पर विश्लेषण करने जा रहे हैं। एक एनालिटिक्स का कार्यकर्ता समवर्ती रूप से कई इनबाउंड स्ट्रीम को अलग मशीन/क्लस्टर में डिक्रिप्ट करता है और अंतिम बाइट + टैग जांच के बाद, प्रत्येक विश्लेषण कार्यभार शुरू करता है। सभी स्टोरेज, वर्कर, एनालिटिक्स VMs Azure US-West में हैं।

@sidshetye , आप गूंगा-एन-खतरनाक आदिम और स्मार्ट-एन-हग करने योग्य प्रोटोकॉल को अलग रखने के बारे में बहुत अडिग थे! मेरा एक सपना था - और मैंने उस पर विश्वास किया। और फिर आप इसे हम पर फेंक देते हैं। यह एक प्रोटोकॉल है - एक सिस्टम डिज़ाइन। जिसने भी उस प्रोटोकॉल को डिजाइन किया है जिसका आपने वर्णन किया है - गड़बड़ है। चौकोर खूंटी को गोल छेद में फिट करने में असमर्थता पर रोने का कोई मतलब नहीं है।

जो कोई भी जीसीएम-एन्क्रिप्टेड 10 जीबी फाइलें न केवल खतरनाक रूप से आदिम किनारे के करीब रह रहा है (जीसीएम 64 जीबी के बाद अच्छा नहीं है), बल्कि यह भी एक निहित दावा था कि पूरे सिफरटेक्स्ट को बफर करने की आवश्यकता होगी।

जो कोई भी GCM- 10Gb फ़ाइलों को एन्क्रिप्ट करता है, वह अत्यधिक संभावना के साथ एक प्रोटोकॉल गलती कर रहा है। समाधान: खंडित एन्क्रिप्शन। टीएलएस में चर-लंबाई 16k-सीमित चंकिंग है, और अन्य, सरल, पीकेआई-मुक्त स्वाद हैं। इस काल्पनिक उदाहरण की "क्लाउड-फर्स्ट" सेक्स अपील डिजाइन की गलतियों को कम नहीं करती है।

(मेरे पास इस धागे पर करने के लिए बहुत कुछ है।)

@sdrapkin ने डेटा सुरक्षा परत से IAuthenticatedEncryptor इंटरफ़ेस का पुन: उपयोग करने के बारे में एक बिंदु उठाया। ईमानदार होने के लिए मुझे नहीं लगता कि यह एक आदिम के लिए सही अमूर्तता है, क्योंकि डेटा सुरक्षा परत इस बात पर काफी विचार करती है कि यह क्रिप्टोग्राफी कैसे करता है। उदाहरण के लिए, यह IV या गैर के स्व-चयन को मना करता है, यह अनिवार्य करता है कि एक अनुरूप कार्यान्वयन AAD की अवधारणा को समझता है, और यह एक परिणाम उत्पन्न करता है जो कुछ हद तक मालिकाना है। एईएस-जीसीएम के मामले में, IAuthenticatedEncryptor.Encrypt से वापसी मूल्य उपकुंजी व्युत्पत्ति के लिए उपयोग की जाने वाली अजीब लगभग-गैर-चीज का संयोजन है, प्रदान किए गए सादे टेक्स्ट पर एईएस-जीसीएम चलाने के परिणामस्वरूप सिफरटेक्स्ट (लेकिन नहीं एएडी!), और एईएस-जीसीएम टैग। इसलिए जबकि संरक्षित पेलोड उत्पन्न करने में शामिल प्रत्येक चरण सुरक्षित है, पेलोड स्वयं किसी भी प्रकार के स्वीकृत सम्मेलन का पालन नहीं करता है, और आपको डेटा सुरक्षा लाइब्रेरी से अलग कोई भी नहीं मिल रहा है जो परिणामी सिफरटेक्स्ट को सफलतापूर्वक डिक्रिप्ट कर सकता है। यह ऐप डेवलपर-सामना करने वाली लाइब्रेरी के लिए एक अच्छा उम्मीदवार बनाता है लेकिन एक इंटरफ़ेस के लिए एक भयानक उम्मीदवार को प्राइमेटिव द्वारा कार्यान्वित किया जाता है।

मुझे यह भी कहना चाहिए कि मुझे वन ट्रू इंटरफेस (टीएम) IAuthenticatedEncryptionAlgorithm होने में काफी मूल्य नहीं दिखता है कि सभी प्रमाणित एन्क्रिप्शन एल्गोरिदम लागू करने वाले हैं। ये आदिम "जटिल" हैं, साधारण ब्लॉक सिफर प्राइमेटिव या हैशिंग प्राइमेटिव के विपरीत। इन जटिल आदिमों में बस बहुत अधिक चर हैं। क्या आदिम AE ही है, या यह AEAD है? क्या एल्गोरिथ्म एक IV / गैर को बिल्कुल स्वीकार करता है? (मैंने कुछ ऐसे देखे हैं जो नहीं करते हैं।) क्या कोई चिंता है कि इनपुट IV / नॉन या डेटा को कैसे संरचित किया जाना चाहिए? आईएमओ जटिल प्राइमेटिव्स को केवल स्टैंडअलोन एपीआई होना चाहिए, और उच्च स्तरीय पुस्तकालय उन विशिष्ट जटिल प्राइमेटिव्स के समर्थन में सेंकना चाहिए जिनकी वे परवाह करते हैं। फिर उच्च-स्तरीय पुस्तकालय अपने परिदृश्यों के लिए उपयुक्त किसी भी समान एपीआई को उजागर करता है।

@sdrapkin हम फिर से विषय से हट रहे हैं। मैं सिर्फ इतना कहूंगा कि एक सिस्टम प्राइमेटिव का उपयोग करके बनाया गया है। यहां क्रिप्टो प्राइमेटिव नंगे और शक्तिशाली हैं। जबकि सिस्टम/प्रोटोकॉल परत बफरिंग को संभालती है; वह भी एक क्लस्टर स्तर पर, निश्चित रूप से मुख्य सिस्टम मेमोरी में नहीं जो कि वन शॉट प्रिमिटिव्स को मजबूर करेगा। 'चंकिंग' सीमा X (X=10GB यहाँ) है क्योंकि <64GB, क्योंकि क्लस्टर की बफरिंग क्षमता लगभग असीमित थी और क्लस्टर में अंतिम बाइट लोड होने तक कुछ भी शुरू नहीं हो सकता था। यह वास्तव में चिंताओं का अलगाव है, प्रत्येक परत को इसकी ताकत के लिए अनुकूलित करना जिसके बारे में मैं बात कर रहा हूं। और यह केवल तभी हो सकता है जब अंतर्निहित प्राइमेटिव उच्च परत डिज़ाइन/सीमाओं को बाधित नहीं करते हैं (ध्यान दें कि अधिक वास्तविक दुनिया ऐप्स अपनी विरासत बाधाओं के साथ आते हैं)।

NIST 800-38d sec9.1 कहता है:

किसी अनधिकृत पार्टी को IVs की पीढ़ी को नियंत्रित करने या प्रभावित करने से रोकने के लिए,
GCM को केवल एक क्रिप्टोग्राफ़िक मॉड्यूल के भीतर लागू किया जाएगा जो की आवश्यकताओं को पूरा करता है
FIPS पब। 140-2. विशेष रूप से, मॉड्यूल की क्रिप्टोग्राफ़िक सीमा में शामिल होना चाहिए a
"जेनरेशन यूनिट" जो सेक में एक निर्माण के अनुसार IVs का उत्पादन करती है। 8.2 ऊपर।
FIPS 140-2 की आवश्यकताओं के विरुद्ध इसके सत्यापन के लिए मॉड्यूल का दस्तावेज़ीकरण करना चाहिए
वर्णन करें कि मॉड्यूल IVs पर विशिष्टता की आवश्यकता का अनुपालन कैसे करता है।

इसका मतलब है कि GCM IVs आंतरिक रूप से स्वतः उत्पन्न होना चाहिए (और बाहरी रूप से पारित नहीं होना चाहिए)।

@sdrapkin अच्छा बिंदु लेकिन अगर आप और भी करीब से पढ़ते हैं तो आप देखेंगे कि 96 बिट्स और उससे अधिक की IV लंबाई के लिए, खंड 8.2.2 एक यादृच्छिक बिट जनरेटर (RBG) के साथ IV उत्पन्न करने की अनुमति देता है जहां कम से कम 96 बिट्स यादृच्छिक हैं (आप सिर्फ 0 अन्य बिट्स हो सकता है)। मैंने पिछले महीने इस धागे पर ही इसका जिक्र किया था ( यहां नॉन के तहत)।

एलटी; डीआर: INonce एक जाल है जो एनआईएसटी और एफआईपीएस दिशानिर्देशों का अनुपालन नहीं करता है।

धारा 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 के कारण इसे प्रमाणित नहीं करेगा। (कुछ विदेशी सैन्य/सरकारी प्रतिष्ठानों को छोड़ दें)।

... अधिकांश क्रिप्टो लाइब्रेरी (Oracle's Java, WinNT's bcryptprimitives, OpenSSL आदि देखें) जो FIPS प्रमाणन प्राप्त कर रहे हैं, IV के लिए RBG रूट का उपयोग करते हैं और इनपुट के लिए बस एक बाइट ऐरे लेते हैं। ध्यान दें कि INonce इंटरफ़ेस का होना वास्तव में NIST और FIPS के दृष्टिकोण से एक जाल है क्योंकि यह स्पष्ट रूप से सुझाव देता है कि उपयोगकर्ता को उस इंटरफ़ेस के कार्यान्वयन को क्रिप्टो फ़ंक्शन में पास करना चाहिए। लेकिन INonce के किसी भी उपयोगकर्ता कार्यान्वयन की लगभग गारंटी है कि वह 9 महीने + और $50K+ NIST प्रमाणन प्रक्रिया से नहीं गुजरा है। फिर भी, अगर उन्होंने आरजीबी निर्माण (पहले से ही क्रिप्टो लाइब्रेरी में) का उपयोग करके एक बाइट सरणी भेजी थी, तो वे दिशानिर्देशों का पूरी तरह से अनुपालन करेंगे।

मैंने पहले कहा है - इन मौजूदा क्रिप्टो पुस्तकालयों ने अपनी एपीआई सतह विकसित की है और कई परिदृश्यों में युद्ध परीक्षण किया गया है। इससे भी अधिक हमने इस लंबे सूत्र में जिस पर बात की है। मेरा वोट फिर से उन सभी पुस्तकालयों, उन सभी मान्यताओं और उन सभी प्रतिष्ठानों में उस ज्ञान और अनुभव का लाभ उठाने के लिए है, न कि पहिया को फिर से शुरू करने का प्रयास करने के लिए। पहिया का पुन: आविष्कार न करें। रॉकेट का आविष्कार करने के लिए इसका इस्तेमाल करें :)

हाय दोस्तों,

इस पर कोई अपडेट? @karelz के क्रिप्टो रोडमैप थ्रेड या एईएस जीसीएम थ्रेड पर कोई अपडेट नहीं देखा।

धन्यवाद
सिड

तो अंतिम ठोस प्रस्ताव 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);
}

तब से केवल कुछ संभावित मुद्दों को उठाया गया है:

• टैग की अग्रिम रूप से आवश्यकता होती है, जो कुछ परिदृश्यों में बाधा डालता है। या तो एपीआई को और अधिक लचीलेपन की अनुमति देने के लिए काफी अधिक जटिल होना चाहिए, या इस मुद्दे को एक प्रोटोकॉल (अर्थात उच्च-स्तरीय) समस्या माना जाना चाहिए।
• INonceProvider अनावश्यक रूप से जटिल हो सकता है और/या एनआईएसटी और एफआईपीएस दिशानिर्देशों का अनुपालन नहीं कर सकता है।
• प्रमाणीकृत एन्क्रिप्शन प्राइमेटिव्स का इच्छित अमूर्त एक पाइप सपना हो सकता है, क्योंकि मतभेद बहुत अधिक हो सकते हैं। इस सुझाव पर आगे कोई चर्चा नहीं हुई है।

मैं निम्नलिखित का सुझाव देना चाहता हूं:

1. टैग अपफ्रंट की आवश्यकता नहीं होने की अतिरिक्त जटिलता गंभीर लगती है, संबंधित समस्या परिदृश्य असामान्य लगता है, और समस्या वास्तव में प्रोटोकॉल के मामले की तरह लगती है। अच्छा डिज़ाइन बहुत कुछ समायोजित कर सकता है, लेकिन सब कुछ नहीं। व्यक्तिगत रूप से मैं इसे प्रोटोकॉल पर छोड़ने में सहज महसूस करता हूं। (मजबूत प्रतिरूपों का स्वागत है।)
2. चर्चा लगातार एक लचीले, निम्न-स्तरीय कार्यान्वयन की ओर बढ़ी है जो IV पीढ़ी के अपवाद के साथ दुरुपयोग से रक्षा नहीं करता है। चलो सुसंगत रहें। आम सहमति यह प्रतीत होती है कि एक उच्च-स्तरीय एपीआई एक महत्वपूर्ण अगला कदम है, जो अधिकांश डेवलपर्स द्वारा उचित उपयोग के लिए महत्वपूर्ण है - इस तरह हम निम्न-स्तरीय एपीआई में दुरुपयोग के खिलाफ सुरक्षा नहीं करते हैं। लेकिन ऐसा लगता है कि डर की एक अतिरिक्त खुराक ने IV पीढ़ी के क्षेत्र में दुरुपयोग की रोकथाम के विचार को कायम रखा है। निम्न-स्तरीय API के संदर्भ में, और सुसंगत होने के लिए, मैं एक byte[] -समतुल्य की ओर झुकता हूँ। लेकिन इंजेक्शन INonceProvider के साथ कार्यान्वयन स्वैपिंग अधिक निर्बाध है। क्या @sidshetye की टिप्पणी अकाट्य है, या एक साधारण INonceProvider इम्प्लांटेशन जो केवल RNG को कॉल करता है, उसे अभी भी आज्ञाकारी माना जा सकता है?
3. अमूर्त उपयोगी प्रतीत होते हैं, और उन्हें डिजाइन करने में इतना प्रयास किया गया है, कि अब तक मुझे विश्वास हो गया है कि वे नुकसान से ज्यादा अच्छा करेंगे। इसके अलावा, उच्च-स्तरीय एपीआई अभी भी निम्न-स्तरीय एपीआई को लागू करना चुन सकते हैं जो निम्न-स्तरीय एब्स्ट्रैक्शन के अनुरूप नहीं हैं।
4. IV सामान्य शब्द है, और एक गैर एक विशिष्ट प्रकार का IV है, सही है? यह INonceProvider से IIVProvider , और nonceOrIv* से iv* के नाम बदलने की मांग करता है। आखिरकार, हम हमेशा एक IV के साथ काम कर रहे हैं, लेकिन जरूरी नहीं कि एक नॉन के साथ।

टैग अपफ्रंट मेरे परिदृश्य के लिए एक गैर स्टार्टर है इसलिए मैं शायद अपना खुद का कार्यान्वयन रखूंगा। जो ठीक है, मुझे यकीन नहीं है कि इस क्षेत्र में हाई परफ कोड लिखना हर किसी के बस की बात है।

समस्या यह है कि यह अनावश्यक विलंबता का कारण बनेगा। फ्रेम को डिकोड करना शुरू करने के लिए अंत में टैग प्राप्त करने के लिए आपको एक संपूर्ण संदेश पूर्व बफर करना होगा। इसका मतलब है कि आप मूल रूप से IO और डिक्रिप्टिंग को ओवरलैप नहीं कर सकते।

मुझे यकीन नहीं है कि अंत में इसे अनुमति देना इतना कठिन क्यों है। लेकिन मैं इस एपीआई के लिए एक रोड ब्लॉक नहीं करने जा रहा हूं, यह मेरे परिदृश्य में कोई दिलचस्पी नहीं होगी।

IV सामान्य शब्द है, और एक गैर एक विशिष्ट प्रकार का IV है, सही है?

नहीं, एक nonce एक बार उपयोग की जाने वाली संख्या है। एक एल्गोरिथ्म जो एक गैर को निर्दिष्ट करता है वह इंगित करता है कि पुन: उपयोग एल्गोरिथ्म की गारंटी का उल्लंघन करता है। GCM के मामले में, एक ही कुंजी और एक अलग संदेश के साथ एक ही गैर का उपयोग करने से GHASH कुंजी का समझौता हो सकता है, GCM को CTR तक कम कर सकता है।

http://nvlpubs.nist.gov/nistpubs/ir/2013/NIST.IR.7298r2.pdf से :

Nonce: सुरक्षा प्रोटोकॉल में उपयोग किया जाने वाला मान जो एक ही कुंजी के साथ कभी भी दोहराया नहीं जाता है। उदाहरण के लिए, चुनौती-प्रतिक्रिया प्रमाणीकरण प्रोटोकॉल में चुनौतियों के रूप में उपयोग किए जाने वाले गैर को आम तौर पर तब तक दोहराया नहीं जाना चाहिए जब तक प्रमाणीकरण कुंजी नहीं बदली जाती। अन्यथा, रीप्ले हमले की संभावना है। एक चुनौती के रूप में एक गैर का उपयोग करना एक यादृच्छिक चुनौती की तुलना में एक अलग आवश्यकता है, क्योंकि एक गैर आवश्यक रूप से अप्रत्याशित नहीं है।

एक "IV" में समान कठोर आवश्यकताएं नहीं होती हैं। उदाहरण के लिए, सीबीसी के साथ एक IV को दोहराने से केवल लीक होता है कि क्या एन्क्रिप्टेड संदेश समान IV के साथ पिछले वाले की तुलना में समान है, या उससे भिन्न है। यह एल्गोरिदम को कमजोर नहीं करता है।

एक गैर एक बार उपयोग की जाने वाली संख्या है।
एक "IV" में समान कठोर आवश्यकताएं नहीं होती हैं।

@bartonjs हाँ। मैं तर्क दूंगा कि, चूंकि क्रिप्टो आदिम को प्रारंभ करने के लिए एक गैर का उपयोग किया जाता है, यह इसका प्रारंभिक वेक्टर है। यह 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 को इस दस्तावेज़ के शेष भाग में एक गैर के रूप में संदर्भित किया जाता है।"_ RFC 5647 (SSH के लिए GCM) कहता है _"नोट: [RFC5116] में, IV को गैर कहा जाता है।"_ RFC 4543 ( IPSec में GCM) कहता है _ "हम AES-GMAC IV इनपुट को नॉन के रूप में संदर्भित करते हैं, ताकि इसे पैकेट में IV फ़ील्ड से अलग किया जा सके।"_ RFC 7714 (SRTP के लिए GCM) 12-बाइट IV के बारे में बात करता है

अधिकांश GCM स्पेक्स में एकरूपता की पूर्ण कमी को देखते हुए, nonceOrIv थोड़े समझ में आता है। $0.02

टैग अपफ्रंट एक नॉन-स्टार्टर है

अन्य ग्राहकों की तरह यहां खुद को आवाज देने के लिए, टैग अपफ्रंट की आवश्यकता हमारे लिए भी एक गैर-शुरुआत है। कोई रास्ता नहीं है .NET इस कृत्रिम रूप से शुरू की गई सीमा के साथ समवर्ती धाराओं को संसाधित कर सकता है। पूरी तरह से स्केलेबिलिटी को मारता है।

क्या आप इस दावे का समर्थन कर सकते हैं कि यह जटिलता जोड़ता है? क्योंकि यह वास्तव में तुच्छ होना चाहिए। साथ ही किसी भी प्लेटफ़ॉर्म-विशिष्ट क्रिप्टो कार्यान्वयन (जिसे आप लपेटेंगे) में यह सीमा नहीं है। विशेष रूप से, इसका कारण यह है कि गणना किए गए टैग की तुलना में इनपुट टैग को केवल स्थिर-समय होना चाहिए। और परिकलित टैग TryFinish के दौरान अंतिम ब्लॉक को डिक्रिप्ट किए जाने के बाद ही उपलब्ध होता है। तो अनिवार्य रूप से, जब आप अपना कार्यान्वयन शुरू करते हैं, तो आप पाएंगे कि आप केवल tag को अपने उदाहरण के अंदर TryFinish तक संग्रहीत कर रहे हैं। आप इसे एक वैकल्पिक इनपुट के रूप में बहुत अच्छी तरह से प्राप्त कर सकते हैं

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

मुझे यह भी लगता है कि हम सभी क्रिप्टो परिदृश्यों को कवर करने वाले एकल इंटरफ़ेस को सामान्य करने के लिए बहुत कठिन प्रयास कर रहे हैं। मैं भी सामान्यीकृत इंटरफेस पसंद करता हूं, लेकिन कभी भी कार्यक्षमता या मापनीयता की कीमत पर नहीं - विशेष रूप से भाषा की मानक क्रायो लाइब्रेरी जैसी मूलभूत परत पर। आईएमएचओ, अगर कोई खुद को ऐसा करते हुए पाता है, तो इसका आमतौर पर मतलब है कि अमूर्तन दोषपूर्ण है।

यदि एक सरल सुसंगत इंटरफ़ेस की आवश्यकता है, तो मैं जावा दृष्टिकोण को प्राथमिकता देता हूं - जिसे पहले यहां विकल्प 1 के रूप में उठाया गया था । यह टैग पहले/टैग के उपरोक्त मुद्दे को एल्गोरिदम कार्यान्वयन (आईएमएचओ, जैसा कि मुझे लगता है कि इसे करना चाहिए) के भीतर रखकर भी दूर कर देता है। मेरी टीम इसे लागू नहीं कर रही है, इसलिए यह हमारा निर्णय नहीं है लेकिन अगर हमें कोई निर्णय लेना है और लागू करना शुरू करना है - तो हम निश्चित रूप से इस मार्ग पर जाएंगे।

कृपया INonce इंटरफ़ेस से बचें एक साधारण byte[] या span<> एक आज्ञाकारी निम्न स्तर के इंटरफ़ेस के लिए पर्याप्त होना चाहिए।

IV बनाम नॉन - सामान्यीकृत मामला वास्तव में IV है। GCM के लिए IV को एक नॉन (जैसे कार बनाम RedOrCar) होना आवश्यक है। और जैसा कि मैं इसे कॉपी-पेस्ट कर रहा हूं, मैंने अभी देखा है कि @timovzl ने एक बहुत ही समान उदाहरण का उपयोग किया है :)

@sidshetye क्या आप एक सटीक प्रस्ताव दे सकते हैं कि दोनों (1) एल्गोरिदम का समर्थन करते हैं जिन्हें टैग की आवश्यकता होती है, और (2) अन्य सभी स्थितियों में केवल TryFinish तक टैग की आवश्यकता होती है?

मुझे लगता है कि आप निम्नलिखित दिशा में कुछ सोच रहे हैं?

• Initialize में टैग को शून्य होने की अनुमति है। केवल वे एल्गोरिदम जिन्हें इसकी आवश्यकता है, वे शून्य पर फेंक देंगे।
• TryFinish में टैग की आवश्यकता है, या (वैकल्पिक रूप से) उन एल्गोरिदम के लिए शून्य होने की अनुमति है जिन्हें पहले से ही इसकी आवश्यकता है।

मुझे लगता है कि उपरोक्त केवल दस्तावेज़ीकरण और जानकारी के रूप में जटिलता जोड़ता है। निम्न-स्तरीय एपीआई के लिए इसे एक छोटा बलिदान माना जा सकता है, क्योंकि वैसे भी पर्याप्त दस्तावेज और जानकारी की आवश्यकता होती है।

मैं आश्वस्त होना शुरू कर रहा हूं कि यह संभव होना चाहिए, अन्य कार्यान्वयन और स्ट्रीमिंग के साथ संगतता के लिए।

@timovzl ज़रूर, मुझे इसके लिए कल कुछ समय बजट की उम्मीद है।

@Timovzl , मेरे पास आज ही समय समाप्त हो गया और यह काफी खरगोश का छेद बन गया! यह लंबा है लेकिन मुझे लगता है कि यह अधिकांश उपयोग के मामलों को कैप्चर करता है, .NET क्रिप्टो की ताकत ( ICryptoTransform ) को कैप्चर करता है जबकि .NET कोर/स्टैंडर्ड दिशा ( Span<> ) को गले लगाता है। मैंने फिर से पढ़ा है, लेकिन आशा है कि नीचे कोई टाइपो नहीं है। मुझे यह भी लगता है कि कुछ वास्तविक समय के संचार (चैट, कॉन्फ कॉल आदि) तेजी से विचार-मंथन के लिए महत्वपूर्ण हैं; मुझे आशा है कि आप इस पर विचार कर सकते हैं।

प्रोग्रामिंग मॉडल

मैं पहले एपीआई के उपयोगकर्ताओं के लिए परिणामी प्रोग्रामिंग मॉडल के बारे में बात करूंगा।

स्ट्रीमिंग एन्क्रिप्ट

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 (नीचे परिभाषित) पर सहायक विधियों में लपेट सकते हैं। अर्थात

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

यह एक सरल एपीआई पेश करने के रूप में दोगुना हो सकता है जैसे

गैर-स्ट्रीमिंग एन्क्रिप्ट

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

हुड के नीचे

कोरएफएक्स स्रोत को देखते हुए, स्पैन<> हर जगह है। इसमें शामिल है System.Security.Cryptography.* - सिमेट्रिक सिफर को छोड़कर, तो चलिए उस पहले और लेयर ऑथेंटिकेटेड एन्क्रिप्शन को शीर्ष पर ठीक करते हैं।

1. स्पैन I/O . के लिए ICipherTransform बनाएं

यह ICryptoTransform के स्पैन जागरूक संस्करण की तरह है। मैं फ्रेमवर्क अपग्रेड के हिस्से के रूप में इंटरफ़ेस को ही बदल दूंगा लेकिन चूंकि लोग इसके बारे में भावुक हो सकते हैं, इसलिए मैं इसे 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. अवधि 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. अवधि I/O . के लिए मौजूदा CryptoStream बढ़ाएँ

यह System.Runtime में Stream की तरह ही है। साथ ही हम अपने AEAD मामले का अनुसरण करने के लिए एक c'tor जोड़ेंगे।

महत्वपूर्ण: CryptoStream को एन्क्रिप्शन के दौरान स्ट्रीम के अंत में टैग जोड़ने और डिक्रिप्शन के दौरान टैग (टैगसाइज बाइट्स) को स्वचालित रूप से निकालने के लिए FlushFinalBlock में एक अनिवार्य अपग्रेड की आवश्यकता होगी । यह जावा के क्रिप्टोग्राफिक आर्किटेक्चर या सी # बाउंसीकास्टल जैसे अन्य युद्ध परीक्षण एपीआई के समान है। यह अपरिहार्य है फिर भी ऐसा करने के लिए सबसे अच्छी जगह है क्योंकि स्ट्रीमिंग में टैग अंत में उत्पन्न होता है, फिर भी डिक्रिप्शन के दौरान अंतिम ब्लॉक को बदलने तक इसकी आवश्यकता नहीं होती है। उल्टा यह प्रोग्रामिंग मॉडल को बहुत सरल करता है।

नोट: 1) सीबीसी-एचएमएसी के साथ, आप पहले टैग को सत्यापित करना चुन सकते हैं। यह सुरक्षित विकल्प है लेकिन यदि ऐसा है तो यह वास्तव में इसे दो पास एल्गोरिदम बनाता है। पहला पास एचएमएसी टैग की गणना करता है और दूसरा पास वास्तव में डिक्रिप्शन करता है। इसलिए मेमोरी स्ट्रीम या नेटवर्क स्ट्रीम को हमेशा मेमोरी में बफ़र करना होगा और इसे एक-शॉट मॉडल में कम करना होगा; स्ट्रीमिंग नहीं। जीसीएम या सीसीएम जैसे ट्रू एईएडी एल्गोरिदम कुशलता से स्ट्रीम कर सकते हैं।

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) के साथ प्रमाणित एन्क्रिप्शन की अनुमति देने के लिए लापता बिट्स को जोड़ सकते हैं

AEAD के लिए नया ICipherTransform बढ़ाएँ

इससे CryptoStream अपना काम ठीक से कर सकता है। हम अपने स्वयं के कस्टम स्ट्रीमिंग क्लास/उपयोग को लागू करने के लिए IAuthenticatedCipherTransform इंटरफ़ेस का भी उपयोग कर सकते हैं लेकिन CryptoStream के साथ काम करने से एक सुपर-कोसिव और सुसंगत .net क्रिप्टो एपीआई बन जाता है।

  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 {...}
  ...
}

एईएस जीसीएम वर्ग

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 के माध्यम से सही प्रमाणीकरण होना चाहिए।
• सुरक्षित नहीं। "रिलीज़ ऑफ़ असत्यापित प्लेनटेक्स्ट" (RUP) सेटिंग में एल्गोरिदम के सुरक्षित होने की एक सुरक्षा धारणा है। 2014 के पेपर में एंड्रीवा-एट-अल द्वारा आरयूपी सुरक्षा को औपचारिक रूप दिया गया है। RUP सेटिंग में GCM सुरक्षित नहीं है. CAESAR प्रतियोगिता जहां प्रत्येक प्रविष्टि की GCM से तुलना की जाती है, RUP सुरक्षा को वांछनीय संपत्ति के रूप में सूचीबद्ध करती है। GCM से जारी किए गए असत्यापित प्लेनटेक्स्ट में मामूली रूप से बिट-फ़्लिपिंग हमलों का खतरा होता है।

इससे पहले इस धागे में असममित एन्क्रिप्ट/डिक्रिप्ट एपीआई की संभावना (वैचारिक रूप से) लाई गई थी, और मुझे लगता है कि आम सहमति यह थी कि यह एक बहुत बुरा विचार होगा।

संक्षेप में, आपके पास GCM डिक्रिप्शन के लिए उच्च-स्तरीय बाइट-ग्रेन्युलर स्ट्रीमिंग API नहीं हो सकता है। मैंने इसे पहले भी कई बार कहा था, और मैं इसे फिर से कह रहा हूं। स्ट्रीमिंग एपीआई रखने का एकमात्र तरीका खंडित एन्क्रिप्शन है। मैं खंडित एन्क्रिप्शन पर सभी को आनंदमय-गो-राउंड बख्श दूँगा ..

जीसीएम एपीआई के लिए एमएस जो कुछ भी करने का फैसला करता है, आरयूपी की अनुमति नहीं दी जा सकती है।

@sdrapkin RUP पर यहां विस्तार से चर्चा की गई थी और हम पहले ही उस पुल को पार कर चुके हैं। संक्षेप में, आरयूपी का तात्पर्य है कि डिक्रिप्ट किए गए डेटा को टैग सत्यापित होने तक उपयोग करने की आवश्यकता नहीं है, लेकिन जावा जेसीई, विनएनटी बीक्रिप्ट, ओपनएसएसएल इत्यादि की तरह इसे विधि सीमा पर लागू करने की आवश्यकता नहीं है। अधिकांश क्रिप्टो प्राइमेटिव की तरह, निम्न स्तर वाले विशेष रूप से, सावधानी के साथ उपयोग करें।

^^^ इतना। मैं उच्च स्तरीय स्ट्रीम एपीआई आदि पर सहमत हूं, फिर इसे ठीक से लागू करें। लेकिन जब मैं निम्न स्तर के आदिम का उपयोग करना चाहता हूं तो मुझे स्प्लिट बफर इत्यादि जैसी चीजों का उपयोग करने में सक्षम होना चाहिए, और यह सुनिश्चित करने के लिए मेरे ऊपर है कि डेटा का उपयोग नहीं किया जाता है। टैग कैलकुलेशन/चेकिंग पॉइंट में एक अपवाद फेंकें, लेकिन निम्न स्तर के प्राइमेटिव को हैमस्ट्रिंग न करें।

यह सुनिश्चित करना मेरे ऊपर है कि डेटा का उपयोग नहीं किया जाता है

गलत। यह आप पर निर्भर नहीं है। AES-GCM की एक बहुत ही _specific_ परिभाषा है, और यह परिभाषा सुनिश्चित करती है कि यह आप पर निर्भर नहीं है। आप जो चाहते हैं वह एक अलग एईएस-सीटीआर आदिम है, और एक अलग GHASH आदिम है, जिसे आप तब जोड़ सकते हैं और जैसा आप फिट देखते हैं, लागू कर सकते हैं। लेकिन हम अलग AES-CTR और GHASH आदिम पर चर्चा नहीं कर रहे हैं, है ना? हम एईएस-जीसीएम पर चर्चा कर रहे हैं। और एईएस-जीसीएम के लिए आवश्यक है कि आरयूपी की अनुमति न हो।

मैं क्रिप्टो.स्टैकएक्सचेंज से इल्मरी करोनन के उत्तर की समीक्षा करने का भी सुझाव देता हूं।

@sdrapkin आप एक अच्छी बात करते हैं। यह वांछनीय होगा, हालांकि, अंततः एक एल्गोरिदम है जो आरयूपी के तहत सुरक्षित है, और उस एल्गोरिदम को एपीआई में फिट करने के लिए यहां तय किया गया है। तो हमें चुनना होगा:

1. एपीआई स्ट्रीमिंग का समर्थन नहीं करता है। सरल, लेकिन निम्न-स्तरीय API की कमी है। हमें इसका एक दिन पछतावा हो सकता है।
2. एईएस-जीसीएम कार्यान्वयन एपीआई को सीमित किए बिना विनिर्देश का पालन करते हुए स्ट्रीमिंग को रोकता है।

क्या हम स्ट्रीमिंग परिदृश्य का पता लगा सकते हैं और एक अपवाद फेंक सकते हैं जो बताता है कि यह उपयोग गलत क्यों है? या क्या हमें इसके स्ट्रीमिंग कार्यान्वयन को पूरे बफर का उपभोग करने का सहारा लेना होगा? उत्तरार्द्ध दुर्भाग्यपूर्ण होगा: आप सोच सकते हैं कि आप स्ट्रीमिंग कर रहे हैं, लेकिन आप नहीं हैं।

हम एक SupportsStreaming(out string whyNot) विधि जोड़ सकते हैं जिसे स्ट्रीमिंग कार्यान्वयन द्वारा जांचा गया है।

क्या हमारे पास सामान्य रूप से स्ट्रीमिंग/टैग-एट-द-एंड के खिलाफ कोई ठोस तर्क है? यदि नहीं, तो मेरा मानना ​​है कि हमें इसे एपीआई के साथ बाहर नहीं करने का लक्ष्य रखना चाहिए।

@sdrapkin : आइए आरयूपी का व्यापक दृष्टिकोण लें क्योंकि यह पुस्तकालय है, आवेदन नहीं। तो यह असत्यापित डेटा के वास्तविक रिलीज/उपयोग की तुलना में एक बफरिंग और परत डिजाइन समस्या से अधिक है। AES GCM के लिए NIST विशेष प्रकाशन 800-38D को देखते हुए, हम देखते हैं कि

1. GCM विनिर्देश अधिकतम प्लेनटेक्स्ट लंबाई को 2^39-256 बिट ~ 64 GB के रूप में परिभाषित करता है। सिस्टम मेमोरी में इसके करीब कहीं भी बफरिंग करना अनुचित है।

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)

कहां
ए अनुप्रयोग परत पर एईएस जीसीएम है
B, भाषा स्तर पर AES-GCM है
C प्लेटफॉर्म परत पर AES-GCM है

प्लेनटेक्स्ट को (ए) पर जारी किया जाता है यदि टैग चेक आउट हो जाता है लेकिन यदि अन्यथा विफल हो जाता है तो वापस आ जाता है। हालाँकि बिल्कुल नहीं जहाँ कल्पना में यह सुझाव दिया गया है कि मुख्य मेमोरी प्लेनटेक्स्ट-इन-प्रोग्रेस को बफर करने का एकमात्र स्थान है, न ही वह बफरिंग (बी) या (सी) या कहीं और होनी चाहिए। वास्तव में ओपनएसएसएल, विंडोज एनटी बीक्रिप्ट (सी) के उदाहरण पर जहां स्ट्रीमिंग उच्च स्तर पर बफरिंग की अनुमति देती है। और जावा जेसीए, माइक्रोसॉफ्ट की सीएलआर सुरक्षा और उपरोक्त मेरा प्रस्ताव (बी) के उदाहरण हैं जहां स्ट्रीमिंग एप्लिकेशन परत पर बफरिंग की अनुमति देती है। यह मान लेना बेमानी है कि प्लेनटेक्स्ट जारी करने से पहले A के डिजाइनरों के पास बेहतर बफरिंग क्षमता नहीं है। सिद्धांत और व्यवहार में वह बफर पूरे नेटवर्क में मेमोरी या एसएसडी या स्टोरेज क्लस्टर हो सकता है। या पंच कार्ड;)!

यहां तक ​​कि बफरिंग को छोड़कर, पेपर अन्य व्यावहारिक चिंताओं पर चर्चा करता है (देखें धारा 9.1, डिजाइन विचार और 9.2, परिचालन संबंधी विचार ) जैसे कुंजी ताजगी या IV बिजली अनिश्चितकालीन विफलताओं में गैर-पुनरावृत्ति। हम स्पष्ट रूप से इसे लेयर B यानी यहाँ पर बेक नहीं करेंगे।

@timovzl ऊपर दिया गया हालिया प्रस्ताव दोनों परिदृश्यों को संबोधित करता है - एक-शॉट (वास्तुकार बफरिंग की परवाह नहीं करता है) और साथ ही स्ट्रीमिंग (वास्तुकार के पास बेहतर बफरिंग क्षमताएं हैं)। जब तक निम्न स्तर की स्ट्रीमिंग एपीआई प्रलेखन स्पष्ट है कि उपभोक्ता अब इसे बफर करने के लिए जिम्मेदार है, सुरक्षा प्रमाण में शून्य कमी है और विनिर्देश से कोई विचलन नहीं है।

संपादित करें: व्याकरण, टाइपो और मार्कडाउन काम करने की कोशिश कर रहा है

बिंगो .. फिर से यह परत डिजाइनरों का निर्णय है कि टैग सत्यापन कहां होता है। मैं किसी भी तरह से एप्लिकेशन परत पर असत्यापित डेटा जारी करने की वकालत नहीं कर रहा हूं।

चर्चा वापस आती है कि ये "उपभोक्ता" स्तर एपीआई हैं या वे असली प्राइमेटिव हैं। यदि वे सच्चे आदिम हैं तो उन्हें कार्यक्षमता का पर्दाफाश करना चाहिए ताकि उच्च स्तर "सुरक्षित" एपीआई शीर्ष पर बनाया जा सके। यह पहले से ही गैर-चर्चा के साथ ऊपर तय किया गया था कि ये सच्चे आदिम होने चाहिए, जिसका अर्थ है कि आप अपने आप को पैर में गोली मार सकते हैं, मुझे लगता है कि यह स्ट्रीमिंग/आंशिक सिफरटेक्स्ट डिकोडिंग पर भी लागू होता है।

यह कहते हुए कि, "उच्च" स्तर और सुरक्षित एपीआई प्रदान करना अनिवार्य होगा ताकि लोगों को इनके ऊपर "रोलिंग" करने से रोका जा सके।

मेरी रुचि नेटवर्किंग/पाइपलाइनों से आती है और यदि आप आंशिक बफर नहीं कर सकते हैं और "एक शॉट" करना है तो इन एपीआई के सिर्फ नकारात्मक पक्ष का कोई फायदा नहीं होगा, इसलिए मैं सीधे बीसीआरपीटी/ओपनएसएसएल आदि पर जाना जारी रखूंगा।

मेरी रुचि नेटवर्किंग/पाइपलाइनों से आती है और यदि आप आंशिक बफर नहीं कर सकते हैं और "एक शॉट" करना है तो इन एपीआई के सिर्फ नकारात्मक पक्ष का कोई फायदा नहीं होगा, इसलिए मैं सीधे बीसीआरपीटी/ओपनएसएसएल आदि पर जाना जारी रखूंगा।

बिल्कुल। आवश्यकता समाप्त नहीं होगी, इसलिए लोग अन्य कार्यान्वयन का उपयोग करेंगे या अपना स्वयं का रोल करेंगे। जरूरी नहीं कि यह अच्छे चेतावनी दस्तावेज़ों के साथ स्ट्रीमिंग की अनुमति देने से अधिक सुरक्षित परिणाम हो।

@Timovzl , मुझे लगता है कि हमने पिछले प्रस्ताव के आसपास बहुत सारी तकनीकी प्रतिक्रिया और डिजाइन आवश्यकताओं को प्राप्त किया है। कार्यान्वयन और रिलीज पर विचार?

@Sidshetye ने एक विस्तृत प्रस्ताव दिया है जो मुझे लगता है कि सभी आवश्यकताओं को पूरा करता है। आरयूपी के संबंध में एकल आलोचना को बिना किसी विरोध के संबोधित किया गया है। (विशेष रूप से, आरयूपी को कई परतों में से एक में रोका जा सकता है, और निम्न-स्तरीय एपीआई को यह निर्देशित नहीं करना चाहिए; और _no_ स्ट्रीमिंग की पेशकश के खराब प्रभाव होने की उम्मीद है।)

प्रगति के हित में, मैं नवीनतम प्रस्ताव के साथ किसी और को आमंत्रित करना चाहता हूं, कृपया बोलें - और निश्चित रूप से, विकल्पों की पेशकश करें।

मैं इस प्रस्ताव और एक एपीआई के आकार लेने के बारे में उत्साहित हूं।

@Sidshetye , मेरे कुछ प्रश्न और सुझाव हैं:

1. क्या मौजूदा SymmetricAlgorithm से इनहेरिट करना वांछनीय है? क्या कोई मौजूदा घटक हैं जिन्हें हम एकीकृत करना चाहते हैं? जब तक मैं उस दृष्टिकोण के लिए कुछ लाभ नहीं खो रहा हूं, मैं बिना किसी बेस क्लास के AuthenticatedEncryptionAlgorithm देखूंगा। यदि और कुछ नहीं, तो यह अवांछित CreateEncryptor / CreateDecryptor (गैर-प्रमाणित!) विधियों को उजागर करने से बचता है।
2. शामिल घटकों में से कोई भी असममित क्रिप्टो के साथ प्रयोग योग्य नहीं है, हां? लगभग सभी घटक अपने नाम से "सममित" छोड़ देते हैं, कुछ ऐसा जिससे मैं सहमत हूं। जब तक हम SymmetricAlgorithm विरासत में नहीं लेते, AuthenticatedSymmetricAlgorithm का नाम बदलकर AuthenticatedEncryptionAlgorithm $ कर दिया जा सकता है, पारंपरिक शब्द प्रमाणित एन्क्रिप्शन का पालन करते हुए।
3. एल्गोरिथम पर सेटटेबल Tag संपत्ति होने के बजाय, टैग को लिखने/प्राप्त करने के लिए TryEncrypt / TryDecrypt बदलें।
4. सार्वजनिक बसने वालों के माध्यम से key , iv , और authenticatedAdditionalData को सेट करने का उद्देश्य क्या है? मैं कई मान्य दृष्टिकोणों और जितना संभव हो सके परिवर्तनशील गुणों से दूर रहूँगा। क्या आप उनके बिना एक अद्यतन प्रस्ताव बना सकते हैं?
5. क्या हम किसी भी राज्य को AesGcm में चाहते हैं? मेरी प्रवृत्ति निश्चित रूप से iv और authenticatedAdditionalData को बाहर रखना है, क्योंकि ये प्रति-संदेश हैं। key राज्य के रूप में होने लायक हो सकता है, क्योंकि हम आम तौर पर एक ही कुंजी के साथ कई संचालन करना चाहते हैं। फिर भी, प्रति-कॉल के आधार पर भी कुंजी लेना संभव है। वही प्रश्न CreateAuthenticatorEncryptor के लिए जाते हैं। किसी भी मामले में, हमें मापदंडों को पारित करने के लिए _one way_ पर समझौता करना चाहिए। मैं पेशेवरों और विपक्षों पर चर्चा करने के लिए उत्सुक हूं। मैं प्रमुख स्थिति की ओर झुकाव कर रहा हूं AesGcm , और शेष क्रमशः CreateAuthenticatedEncryptor या TryEncrypt में। यदि हम पहले से सहमत हैं, तो कृपया हमें एक अद्यतन प्रस्ताव दिखाएं। :-)
6. ICipherTransform शायद एक अमूर्त वर्ग होना चाहिए, CipherTransform , ताकि मौजूदा कार्यान्वयन को तोड़े बिना विधियों को जोड़ा जा सके।
7. सभी फ़ंक्शन पैरामीटर को कैमलकेस का उपयोग करना चाहिए, अर्थात लोअरकेस में प्रारंभ करें। साथ ही, क्या हमें authenticatedData या authenticatedAdditionalData कहना चाहिए? इसके अतिरिक्त, मुझे लगता है कि हमें पैरामीटर नाम plaintext और ciphertext चुनना चाहिए।
8. जहां कहीं भी IV पास किया जाता है, मैं इसे एक वैकल्पिक पैरामीटर के रूप में देखना चाहता हूं, जिससे अपना खुद का प्रदान करने की तुलना में एक उचित रूप से उत्पन्न (क्रिप्टोरेन्डम) IV प्राप्त करना आसान हो जाता है। निचले स्तर के एपीआई के दुरुपयोग को कम से कम कठिन बना देता है, और हमें यह मुफ्त में मिलता है।
9. मैं अभी भी यह पता लगाने की कोशिश कर रहा हूं कि TryEncrypt का क्लाइंट कोड ciphertext प्रदान करने के लिए आवश्यक अवधि की लंबाई कैसे जान सकता है! TryDecrypt और plaintext की लंबाई के लिए समान। निश्चित रूप से हमें सफलता तक लूप में कोशिश नहीं करनी चाहिए, प्रत्येक असफल पुनरावृत्ति के बाद लंबाई को दोगुना करना?

अंत में, आगे की सोच, इस के शीर्ष पर निर्मित एक उच्च-स्तरीय एपीआई कैसा दिख सकता है? पूरी तरह से एपीआई के उपयोग को देखते हुए, सुधार के लिए बहुत कम जगह लगती है, क्योंकि स्ट्रीमिंग और गैर-स्ट्रीमिंग एपीआई दोनों पहले से ही इतने सीधे हैं! मुख्य अंतर जो मैं कल्पना करता हूं वह एक स्वचालित IV, स्वचालित आउटपुट आकार और संभवतः एन्क्रिप्टेड डेटा की मात्रा पर एक सीमा है।

विंडोज स्ट्रीमिंग की अनुमति देता है। ओपनएसएसएल भी करता है। उन दोनों ने ज्यादातर इसे मौजूदा अवधारणाओं में कबूतर कर दिया (हालांकि वे दोनों एक रिंच में फेंक दिया "और यह उस तरफ है जिस तरफ आपको निपटना है या मैं त्रुटि करूँगा")।

जाओ नहीं, और लिबसोडियम नहीं करता है।

ऐसा लगता है कि पहली लहर ने इसकी अनुमति दी, और बाद में लोगों ने नहीं। चूँकि हम निश्चित रूप से बाद की लहर में हैं, मुझे लगता है कि हम इसे अनुमति नहीं देने के साथ बने रहेंगे। यदि एक-शॉट मॉडल (एन्क्रिप्शन/डिक्रिप्शन के लिए, कुंजी को कॉल के दौरान बनाए रखा जा सकता है) पेश करने के बाद स्ट्रीमिंग की मांग बढ़ी है, तो हम पुनर्मूल्यांकन कर सकते हैं। तो उस पैटर्न का पालन करने वाला एक एपीआई प्रस्ताव फायदेमंद लगता है। हालांकि न तो एसआईवी और न ही सीसीएम स्ट्रीमिंग एन्क्रिप्शन का समर्थन करते हैं, इसलिए उनके लिए स्ट्रीमिंग एपीआई संभावित रूप से भारी बफरिंग है। चीजों को साफ रखना बेहतर लगता है।

प्रस्तावों को पेलोड में टैग को एम्बेड नहीं करना चाहिए (जीसीएम और सीसीएम इसे एक अलग डेटा के रूप में कहते हैं), जब तक कि एल्गोरिदम स्वयं (एसआईवी) इसे एन्क्रिप्शन के आउटपुट में शामिल नहीं करता है। ( E(...) => (c, t) बनाम E(...) => c || t या E(...) => t || c )। एपीआई के उपयोगकर्ता निश्चित रूप से इसे कॉन्सैट के रूप में उपयोग कर सकते हैं (बस स्पैन को उचित रूप से खोलें)।

GCM विनिर्देश टैग बेमेल होने पर FAIL के अलावा कुछ भी जारी करने की अनुमति नहीं देता है। एनआईएसटी इसके बारे में बिल्कुल स्पष्ट है। मैकग्रे और वीगा द्वारा मूल जीसीएम पेपर भी कहता है:

डिक्रिप्ट ऑपरेशन प्लेनटेक्स्ट के बजाय FAIL लौटाएगा, और डिकैप्सुलेशन रुक जाएगा और प्लेनटेक्स्ट को फॉरवर्ड या आगे प्रोसेस करने के बजाय खारिज कर दिया जाएगा।

पिछली टिप्पणियों में से किसी ने भी आरयूपी को संबोधित नहीं किया - उन्होंने इसे केवल हाथ से लहराया ("उच्च परत इसका ख्याल रखेगी" - हाँ, ठीक है)।

यह आसान है: GCM एन्क्रिप्शन स्ट्रीम कर सकता है। GCM डिक्रिप्शन स्ट्रीम नहीं कर सकता. और कुछ भी अब GCM नहीं है.

ऐसा लगता है कि पहली लहर ने इसकी अनुमति दी, और बाद में लोगों ने नहीं। चूँकि हम निश्चित रूप से बाद की लहर में हैं, मुझे लगता है कि हम इसे अनुमति नहीं देने के साथ बने रहेंगे।

@bartonjs आप सचमुच सभी तकनीकी और तार्किक विश्लेषणों को अनदेखा कर रहे हैं और वास्तविक विश्लेषण के लिए कमजोर प्रॉक्सी के रूप में गो और libsodium परियोजनाओं की तारीखों का उपयोग कर रहे हैं? कल्पना कीजिए कि क्या मैं परियोजनाओं के नाम के आधार पर एक समान तर्क देता हूं। साथ ही हम इंटरफ़ेस और कार्यान्वयन पर निर्णय ले रहे हैं। आप जानते हैं कि एईएडी के लिए एक गैर-स्ट्रीमिंग इंटरफ़ेस का निर्णय लेने से सड़क के नीचे ऐसे सभी कार्यान्वयन नहीं होते हैं, है ना?

यदि एक-शॉट मॉडल (एन्क्रिप्शन/डिक्रिप्शन के लिए, कुंजी को कॉल के दौरान बनाए रखा जा सकता है) पेश करने के बाद स्ट्रीमिंग की मांग बढ़ी है, तो हम पुनर्मूल्यांकन कर सकते हैं।

गिटहब पर अब तक प्रदर्शित मांग अपर्याप्त क्यों है? यह उस बिंदु पर पहुंच रहा है जहां यह किसी भी तकनीकी या ग्राहक मांग योग्यता की तुलना में कम काम करने का समर्थन करने के लिए पूरी तरह से सनकी प्रतीत होता है।

@bartonjs आप सचमुच सभी तकनीकी और तार्किक विश्लेषणों को अनदेखा कर रहे हैं और वास्तविक विश्लेषण के लिए कमजोर प्रॉक्सी के रूप में गो और libsodium परियोजनाओं की तारीखों का उपयोग कर रहे हैं?

नहीं, मैं पेशेवर क्रिप्टोग्राफरों की सलाह का उपयोग कर रहा हूं जो कहते हैं कि यह असाधारण रूप से खतरनाक है और हमें AEAD स्ट्रीमिंग से बचना चाहिए। फिर मैं सीएनजी टीम की जानकारी का उपयोग कर रहा हूं "बहुत से लोग कहते हैं कि वे इसे सिद्धांत रूप में चाहते हैं, लेकिन व्यवहार में लगभग कोई भी ऐसा नहीं करता है" (मुझे नहीं पता कि टेलीमेट्री बनाम क्षेत्ररक्षण सहायता अनुरोधों से कितना वास्तविक है)। तथ्य यह है कि अन्य पुस्तकालय एक-शॉट मार्ग पर चले गए हैं बस निर्णय को _reinforces_ करते हैं।

गिटहब पर अब तक प्रदर्शित मांग अपर्याप्त क्यों है?

कुछ परिदृश्यों का उल्लेख किया गया है। खंडित बफ़र्स को संसाधित करना संभवतः ReadOnlySequence स्वीकार करने के साथ संबोधित किया जा सकता है, अगर ऐसा लगता है कि कॉलर को डेटा पुन: संयोजन करने के बजाय एपीआई को जटिल बनाने के लिए पर्याप्त परिदृश्य है।

बड़ी फाइलें एक समस्या है, लेकिन बड़ी फाइलें पहले से ही एक समस्या है क्योंकि जीसीएम का कटऑफ सिर्फ 64GB है, जो कि "इतना बड़ा नहीं है" (ठीक है, यह बहुत बड़ा है, लेकिन यह "वाह, यह बड़ा नहीं है" यह हुआ करता था)। मेमोरी-मैप की गई फ़ाइलें 2GB RAM की आवश्यकता के बिना स्पैन (2^31-1 तक) का उपयोग करने की अनुमति देंगी। इसलिए हमने अधिकतम से कुछ बिट्स का मुंडन कर दिया है... जो शायद समय के साथ हो जाएगा।

आप जानते हैं कि एईएडी के लिए एक गैर-स्ट्रीमिंग इंटरफ़ेस का निर्णय लेने से सड़क के नीचे ऐसे सभी कार्यान्वयन नहीं होते हैं, है ना?

मैं अधिक से अधिक आश्वस्त हूं कि @GrabYourPitchforks सही था (https://github.com/dotnet/corefx/issues/23629#issuecomment-334638891) कि शायद एक समझदार एकीकृत इंटरफ़ेस नहीं है। GCM _requiring_ a nonce/IV और SIV _forbidding_ इसका मतलब है कि AEAD मोड/एल्गोरिदम के इनिशियलाइज़ेशन के लिए पहले से ही इस बारे में ज्ञान की आवश्यकता है कि क्या होने वाला है... AEAD के लिए वास्तव में "एब्सट्रैक्ट अवे" धारणा नहीं है। SIV तय करता है कि "टैग" कहाँ जाता है। जीसीएम/सीसीएम नहीं। SIV टैग-प्रथम है, कल्पना के अनुसार।

SIV तब तक एन्क्रिप्ट करना शुरू नहीं कर सकता जब तक कि उसके पास सारा डेटा न हो। तो इसका स्ट्रीमिंग एन्क्रिप्ट या तो फेंकने वाला है (जिसका अर्थ है कि आपको इसे कॉल नहीं करना है) या बफर (जिसके परिणामस्वरूप एन ^ 2 ऑपरेशन समय हो सकता है)। लंबाई ज्ञात होने तक CCM प्रारंभ नहीं हो सकता; लेकिन सीएनजी लंबाई में पूर्व-एन्क्रिप्ट संकेत की अनुमति नहीं देता है, इसलिए यह एक ही नाव में है।

हमें एक नया घटक डिज़ाइन नहीं करना चाहिए जहाँ डिफ़ॉल्ट रूप से सही चीज़ की तुलना में गलत काम करना आसान हो। स्ट्रीमिंग डिक्रिप्शन एक स्ट्रीम क्लास (क्रिप्टोस्ट्रीम के साथ ऐसा करने का आपका प्रस्ताव) को तार-तार करना बहुत आसान और आकर्षक बनाता है, जिससे टैग सत्यापित होने से पहले डेटा सत्यापन बग प्राप्त करना बहुत आसान हो जाता है, जो एई के लाभ को लगभग पूरी तरह से समाप्त कर देता है। . ( IGcmDecryptor => CryptoStream => StreamReader => XmlReader => "रुको, यह कानूनी XML नहीं है..." => अनुकूली सिफरटेक्स्ट ऑरैकल) .

यह बिंदु पर हो रहा है ... ग्राहक की मांग।

जैसा कि, दुर्भाग्य से, मैंने अपने जीवन में कई बार सुना है: मुझे क्षमा करें, लेकिन आप हमारे मन में ग्राहक नहीं हैं। मैं मानता हूँ कि शायद आप जानते हैं कि GCM को सुरक्षित रूप से कैसे करना है। आप टैग सत्यापन के बाद तक केवल एक अस्थिर फ़ाइल/बफर/आदि को स्ट्रीम करना जानते हैं। आप जानते हैं कि गैर प्रबंधन का क्या अर्थ है, और आप इसे गलत होने के जोखिमों को जानते हैं। आप स्ट्रीम के आकार पर ध्यान देना और 2^36-64 बाइट्स के बाद एक नए GCM सेगमेंट में कटौती करना जानते हैं। आप जानते हैं कि यह सब कहा और किया जाने के बाद यदि आप उन चीजों को गलत पाते हैं तो यह आपकी बग है।

दूसरी ओर, मेरे मन में जो ग्राहक है, वह वह है जो जानता है कि "मुझे इसे एन्क्रिप्ट करना है" क्योंकि उनके बॉस ने उन्हें बताया था। और वे जानते हैं कि एन्क्रिप्शन कैसे करें की खोज करते समय कुछ ट्यूटोरियल ने कहा "हमेशा AE का उपयोग करें" और GCM का उल्लेख करता है। फिर उन्हें ".NET में एन्क्रिप्शन" ट्यूटोरियल मिलता है जो क्रिप्टोस्ट्रीम का उपयोग करता है। फिर वे पाइपलाइन को जोड़ते हैं, इस बात का कोई अंदाजा नहीं है कि उन्होंने SSLv2 चुनने जैसा ही काम किया है ... सिद्धांत रूप में एक बॉक्स की जाँच की, लेकिन वास्तव में व्यवहार में नहीं। और जब वे ऐसा करते हैं तो _वह_बग उन सभी का होता है जो बेहतर जानते थे, लेकिन गलत काम को करना बहुत आसान हो जाता है।

आप वह ग्राहक नहीं हैं जो हमारे मन में है [...] मेरे मन में जो ग्राहक है, दूसरी ओर, वह कोई है जो जानता है कि "मुझे इसे एन्क्रिप्ट करना है" क्योंकि उनके बॉस ने उन्हें बताया था [...]

@bartonjs महीने पहले हमने पहले ही तय कर लिया था कि लक्ष्य निम्न स्तर के एपीआई (कुछ शर्तों के तहत शक्तिशाली लेकिन असुरक्षित) और एक उच्च स्तरीय एपीआई (फुलप्रूफ) के द्वारा दो ग्राहक प्रोफाइल को लक्षित करना था। यह शीर्षक में भी है। यह निश्चित रूप से एक स्वतंत्र देश है लेकिन अब अन्यथा दावा करके गोलपोस्ट को स्थानांतरित करना मूर्खता है।

दूसरी ओर, मेरे मन में जो ग्राहक है, वह वह है जो जानता है कि "मुझे इसे एन्क्रिप्ट करना है" क्योंकि उनके बॉस ने उन्हें बताया था। और वे जानते हैं कि एन्क्रिप्शन कैसे करें की खोज करते समय कुछ ट्यूटोरियल ने कहा "हमेशा AE का उपयोग करें" और GCM का उल्लेख करता है। फिर उन्हें ".NET में एन्क्रिप्शन" ट्यूटोरियल मिलता है जो क्रिप्टोस्ट्रीम का उपयोग करता है। फिर वे पाइपलाइन को जोड़ते हैं, इस बात का कोई अंदाजा नहीं है कि उन्होंने SSLv2 चुनने जैसा ही काम किया है ... सिद्धांत रूप में एक बॉक्स की जाँच की, लेकिन वास्तव में व्यवहार में नहीं। और जब वे ऐसा करते हैं तो वह बग हर उस व्यक्ति का होता है जो बेहतर जानता था, लेकिन गलत काम को बहुत आसान होने दें।

@bartonjs रुको, निम्न-स्तर के आदिम का क्या हुआ? मैंने सोचा था कि इस विशेष मुद्दे का उद्देश्य बच्चों की देखभाल पर लचीलापन था। निश्चित रूप से हमें बताएं कि क्या योजना बदल गई है, ताकि हम सभी एक ही चीज़ के बारे में बात कर रहे हों।

साथ ही, क्या प्रति-ब्लॉक विधियां अभी भी विचाराधीन हैं, या केवल एक-शॉट विधियां हैं?

मैं अधिक से अधिक आश्वस्त हूं कि @GrabYourPitchforks सही था (# 23629 (टिप्पणी)) कि शायद एक समझदार एकीकृत इंटरफ़ेस नहीं है।

सभी उदाहरणों को देखते हुए, यह अधिक से अधिक निरर्थक लगने लगता है - विशेष रूप से निम्न-स्तरीय एपीआई के लिए जहां कार्यान्वयन में इस तरह के अलग-अलग प्रतिबंध हैं। शायद हमें एकीकृत इंटरफ़ेस के बजाय एईएस-जीसीएम के साथ केवल एक ठोस उदाहरण स्थापित करना चाहिए। एक साइड नोट के रूप में, बाद वाला अभी भी भविष्य के उच्च-स्तरीय एपीआई के लिए दिलचस्प हो सकता है। अधिक प्रतिबंधात्मक होने की इसकी संपत्ति शायद एक एकीकृत इंटरफ़ेस को वहां हासिल करना बहुत आसान बना देगी।

क्या प्रति-ब्लॉक विधियाँ अभी भी विचाराधीन हैं, या केवल एक-शॉट विधियाँ हैं?

जैसा कि https://github.com/dotnet/corefx/issues/23629#issuecomment -378605071 में उल्लेख किया गया है, हमें लगता है कि जोखिम बनाम इनाम बनाम व्यक्त-उपयोग-मामलों का कहना है कि हमें एई के केवल एक-शॉट संस्करणों की अनुमति देनी चाहिए।

मैंने पूरी चर्चा नहीं पढ़ी है, केवल यादृच्छिक भाग। मुझे नहीं पता कि तुम किस दिशा में जा रहे हो। क्षमा करें यदि मैं जो लिखता हूं वह इस संदर्भ में समझ में नहीं आता है। मेरा 2¢:

• धाराएँ महत्वपूर्ण हैं। यदि आप सीधे उनका समर्थन नहीं कर सकते क्योंकि इसका मतलब सुरक्षा भेद्यता होगा, तो यदि संभव हो तो अपने निम्न-स्तरीय एपीआई के शीर्ष पर निर्मित एक उच्च-स्तरीय आवरण प्रदान करें जो धाराओं को उजागर करेगा (एक अक्षम लेकिन सुरक्षित तरीके से)।
• यदि एईएस-जीसीएम किसी भी परिदृश्य में धाराओं का उपयोग नहीं कर सकता है, तो एईएस-सीबीसी-एचएमएसी का कानूनी कार्यान्वयन प्रदान करें जो धाराओं पर आधारित है। या कुछ अन्य एई एल्गोरिदम।
• स्तर जितना ऊंचा होगा, उतना अच्छा होगा। उपयोगकर्ता द्वारा गलती करने के लिए जितने कम क्षेत्र होंगे, उतना ही बेहतर होगा। अर्थ - एपीआई का पर्दाफाश करें जो जितना संभव हो उतना सामान छुपाएगा (उदाहरण के लिए यह प्रमाणीकरण टैग)। बेशक, अधिक विशिष्ट अधिभार भी हो सकते हैं (चाहिए)।
• आईएमएचओ अन्य एन्क्रिप्शन सेवाओं के साथ इंटरफेस को एकीकृत करने से परेशान नहीं है अगर वे बस फिट नहीं हैं। ओपनएसएल ने अपने सीएलआई के साथ यही किया है और परिणाम खराब है (उदाहरण के लिए प्रमाणीकरण टैग प्रदान करने की कोई संभावना नहीं है)।

हम (.NET सुरक्षा टीम) आपस में और Microsoft के भीतर व्यापक क्रिप्टो टीम के साथ सम्मानित हुए। हमने इस सूत्र में उल्लिखित कई मुद्दों और चिंताओं पर चर्चा की। अंततः ये चिंताएँ पर्याप्त प्रेरक नहीं थीं कि एक स्ट्रीमिंग GCM API को ढांचे के भीतर एक मुख्य बिल्डिंग ब्लॉक के रूप में पेश किया जाए।

भविष्य में जरूरत पड़ने पर इस फैसले पर दोबारा विचार किया जा सकता है। और इस बीच हमने चीजों को आज की तुलना में बदतर नहीं बनाया है: डेवलपर्स जो वर्तमान में जीसीएम समर्थन स्ट्रीमिंग के लिए तीसरे पक्ष की क्रिप्टो लाइब्रेरी का उपयोग कर रहे हैं, वे ऐसा करना जारी रख सकते हैं, और वे हमारे इच्छित परिचय से नहीं टूटेंगे। गैर-स्ट्रीमिंग GCM API.

डेटा के एन्क्रिप्शन से कैसे निपटें जो मेमोरी में फिट नहीं होता है?

@pgolebiowski आप उच्च-स्तरीय .NET क्रिप्टो लाइब्रेरी का उपयोग करते हैं जो विशेष रूप से सुरक्षित स्ट्रीमिंग एन्क्रिप्शन की पेशकश करने के लिए डिज़ाइन की गई हैं।

@sdrapkin यह करने से आसान कहा जाता है। "सुरक्षित" पूछने के लिए बहुत कुछ है। ऐसा क्या है जो सिद्ध होता है और जिस पर वास्तव में भरोसा किया जा सकता है? आप खुद कहते हैं:

बाउंसी कैसल सी # लाइब्रेरी (एक सामान्य स्टैक ओवरफ्लो अनुशंसा)। बाउंसी कैसल c# एक विशाल (145k LOC) है, क्रिप्टो का खराब प्रदर्शन करने वाला संग्रहालय कैटलॉग (इसमें से कुछ प्राचीन), पुराने जावा कार्यान्वयन के साथ समान रूप से पुराने .NET (2.0?) पर पोर्ट किया गया है।

ठीक है, तो विकल्प क्या हैं? शायद आपकी अपनी लाइब्रेरी? वास्तव में नहीं । हम्म... शायद लिबसोडियम-नेट? वास्तव में नहीं ।

जब आप वास्तव में एक लेखापरीक्षित पुस्तकालय की तलाश करते हैं जो एक भरोसेमंद स्रोत (जैसे माइक्रोसॉफ्ट या समुदाय द्वारा व्यापक रूप से उपयोग किया जाता है) से आता है, तो मुझे नहीं लगता कि ऐसी लाइब्रेरी .NET कोर दुनिया में मौजूद है।

• ग्राहक: डेटा का प्रमाणित एन्क्रिप्शन जो मेमोरी में फिट नहीं होता है?
• माइक्रोसॉफ्ट: मुझे खेद है, लेकिन आप हमारे मन में ग्राहक नहीं हैं। एक पुस्तकालय का उपयोग करें जिसका ऑडिट नहीं किया गया है और इसकी सुरक्षा संदिग्ध है, अगर आप साइड-चैनल हमले के तहत हमारी समस्या नहीं हैं।
• ग्राहक:

@pgolebiowski विकल्प एक स्थापित .NET ढांचे का उपयोग करना है - यानी। वही चीज जो सिद्ध हो चुकी है और जिस पर विश्वास किया जा सकता है, जैसा आप चाहते हैं। अन्य पुस्तकालय (मेरे सहित) माइक्रोसॉफ्ट के लिए नेटस्टैंडर्ड में ईसीडीएच जैसे लापता क्रिप्टो प्राइमेटिव को जोड़ने की प्रतीक्षा करते हैं।

आप इन्फर्नो फोर्क्स को भी देख सकते हैं। कम से कम 2 कांटे हैं जहां कुछ मामूली बदलावों ने NetStandard20 हासिल किया।

आपकी लाइब्रेरी का 2 साल पहले 2 दिनों के भीतर एक आदमी द्वारा ऑडिट किया गया था। मुझे उस पर भरोसा नहीं है, क्षमा करें। Microsoft में, उसके लिए एक समर्पित टीम होगी -- जिन लोगों पर मुझे Cure53 के लोगों की तुलना में अधिक भरोसा है।

गंभीरता से, हम बहुत सी चीजों के लिए तीसरे पक्ष के समर्थन के बारे में बात कर सकते हैं। लेकिन सुरक्षा संबंधी सभी आवश्यक सामग्री मानक पुस्तकालय द्वारा प्रदान की जानी चाहिए।

@pgolebiowski किसी भी चीज़ पर भरोसा करने के लिए किसी को समझाने की कोशिश करना मुझसे दूर है, लेकिन आपका कथन सटीक नहीं है। Inferno का "Cure53" संगठन के 2 पेशेवरों द्वारा ऑडिट किया गया था। ऑडिट में 2 दिन लगे, और पूरी लाइब्रेरी ~1,000 लाइन ऑफ कोड थी। यह प्रति लेखा परीक्षक/दिन कोड की ~ 250 लाइनें है - काफी प्रबंधनीय।

वास्तव में, आसान ऑडिटेबिलिटी इन्फर्नो की प्रमुख विशेषताओं में से एक है, ठीक उन लोगों के लिए जो भरोसा नहीं करना चाहते हैं।

इस थ्रेड का लक्ष्य एईएस-जीसीएम के लिए समर्थन जोड़ना है। आपका पुस्तकालय एईएस-जीसीएम का भी समर्थन नहीं करता है। यदि आप चाहते हैं कि लोग आपके कोड का उपयोग करें, तो इसे corefx के प्रस्ताव के रूप में सबमिट करें। एक उपयुक्त सूत्र में।

एक और बात, भले ही यह इस एल्गोरिथम का समर्थन करता हो - इसकी .net क्रिप्टो बोर्ड द्वारा समीक्षा नहीं की गई है और यह कोरएफएक्स का हिस्सा नहीं है। यह इस तरह की समीक्षा के लिए एक उम्मीदवार भी नहीं है। इसका मतलब है कि इस व्यर्थ चर्चा और विज्ञापन का अंत।

@pgolebiowski मैंने कुछ भी विज्ञापित नहीं किया - केवल आपके प्रश्न का उत्तर दिया, आपके उपयोगकेस के लिए सुझाए गए विकल्प, और गलत दावों को ठीक किया। एईएस-जीसीएम एन्क्रिप्शन स्ट्रीमिंग के लिए उपयुक्त नहीं है, और यह कुछ ऐसा है जिसकी .NET सुरक्षा टीम द्वारा समीक्षा की गई है और सहमति हुई है, ताकि आप उस पर भरोसा कर सकें।

क्या मैं कहीं भी स्ट्रीमिंग एईएस-जीसीएम का बचाव कर रहा हूं? याद नहीं कर सकता। लेकिन यह कहते हुए याद कर सकते हैं:

• धाराएँ महत्वपूर्ण हैं। यदि आप सीधे उनका समर्थन नहीं कर सकते क्योंकि इसका मतलब सुरक्षा भेद्यता होगा, तो यदि संभव हो तो अपने निम्न-स्तरीय एपीआई के शीर्ष पर निर्मित एक उच्च-स्तरीय आवरण प्रदान करें जो धाराओं को उजागर करेगा (एक अक्षम लेकिन सुरक्षित तरीके से)।
• यदि एईएस-जीसीएम किसी भी परिदृश्य में धाराओं का उपयोग नहीं कर सकता है, तो एईएस-सीबीसी-एचएमएसी का कानूनी कार्यान्वयन प्रदान करें जो धाराओं पर आधारित है। या कुछ अन्य एई एल्गोरिदम।

या corefx के लिए एक खुली समस्या बताते हुए:

डेटा के एन्क्रिप्शन से कैसे निपटें जो मेमोरी में फिट नहीं होता है?

बक्शीश:

आप इन्फर्नो फोर्क्स को भी देख सकते हैं। कम से कम 2 कांटे हैं जहां कुछ मामूली बदलावों ने NetStandard20 हासिल किया। [...] इन्फर्नो का "Cure53" संगठन के 2 पेशेवरों द्वारा ऑडिट किया गया था [...] आसान ऑडिटेबिलिटी इन्फर्नो की प्रमुख विशेषताओं में से एक है, ठीक उन लोगों के लिए जो भरोसा नहीं करना चाहते हैं।

मैंने कुछ भी विज्ञापन नहीं किया

एक तरफ के रूप में मैं वास्तव में "स्ट्रीमिंग" इस अर्थ में कभी नहीं चाहता था कि ज्यादातर सोच रहे हैं। मैं सिर्फ पूर्ण और स्मृति उपयोग कारणों के लिए "ब्लॉक" प्रसंस्करण चाहता था। मैं वास्तव में परिणामों को "स्ट्रीम" नहीं करना चाहता हूं। यह वही है जो ओपनएसएल और सीएनजी समर्थन को खोने के लिए शर्म की बात है और मूल रूप से "प्राइमेटिव्स" को किसी भी परिदृश्य में बेकार बना देता है जिसके बारे में मैं सोच सकता हूं।

@Drawaes इसके बारे में सोचें, धाराओं का उपयोग करने से ब्लॉक ऑपरेशन अधिक सुरक्षित हो सकता है। एक आम आदमी धाराओं को छू सकता है, लेकिन वह ब्लॉक ऑपरेशन के बजाय एक-शॉट एपीआई का अधिक उपयोग करेगा। इसके अलावा, ब्लॉक ऑपरेशन _srightforwardly_ को XmlReader के साथ जोड़ा नहीं जा सकता है। तो वास्तव में, चर्चा किए गए कई खतरे वस्तुओं को स्ट्रीम करने के लिए लागू होते हैं, लेकिन ऑपरेशन को अवरुद्ध करने के लिए नहीं।

एक-शॉट एपीआई भी उपलब्ध होने पर ब्लॉक ऑपरेशन के साथ काम करने के लिए, यह सुझाव देता है कि हम जानते हैं कि हम क्या कर रहे हैं, और हमें विशेष रूप से निम्न-स्तरीय ट्विकिंग की आवश्यकता है। हम आम आदमी की रक्षा कर सकते हैं _और_ में लचीलापन है।

आरयूपी से बचने के लिए, मैं अभी भी सोच रहा हूं कि जीसीएम के लिए वास्तव में कितना लाभ ब्लॉक ऑपरेशन है। एन्क्रिप्शन का पूरा लाभ मिलता है, जबकि डिक्रिप्शन से कुछ ही लाभ होता है। हम पूर्ण सिफरटेक्स्ट को संग्रहीत करने से बच सकते हैं, लेकिन हमें अभी भी पूर्ण प्लेनटेक्स्ट को बफर करना होगा। एक डिक्रिप्टर इंटरमीडिएट प्लेनटेक्स्ट को डिस्क पर स्टोर करना चुन सकता है। लेकिन बदले में, हमने त्रुटि के लिए और अधिक जगह पेश की है। क्या हमारे पास इस समस्या को उच्च स्तर पर हल नहीं करने के लिए एक ठोस तर्क है (उदाहरण के लिए वहां खंड, या वास्तव में स्ट्रीमिंग एल्गोरिदम का उपयोग करें)?

टीएलएस और पाइपलाइन। वर्तमान में (और निकट भविष्य के लिए) पाइपलाइन 4k ब्लॉक का उपयोग करती है लेकिन एक tls संदेश 16k सिफर टेक्स्ट का हो सकता है। एक शॉट के साथ आपको डिक्रिप्ट करने से पहले 16k को एक एकल आकस्मिक बफर में कॉपी करने की आवश्यकता होगी। ब्लॉक के साथ आप 4 या 5 कह सकते हैं और प्रतिस्पर्धा ब्लॉक सुनिश्चित करने के लिए आपको 16 बाइट्स तक बफर करने की आवश्यकता हो सकती है।

@Drawaes 16k अभी भी स्थिर है और विशाल नहीं है। क्या इस संदर्भ में इससे बहुत फर्क पड़ता है?

हां, इसका मतलब पाइपलाइन में एक और प्रति है। इसका perf पर एक बड़ा और औसत दर्जे का प्रभाव पड़ता है।

ऐसा करने के लिए क्या आवश्यक है? अगले चरण क्या हैं? @Drawaes

एईएस-जीसीएम के लिए, मुझे लगता है कि संबंधित समस्या के लॉक होने के कारण इसकी डिलीवरी बाधित है: https://github.com/dotnet/corefx/issues/7023। @blowdart , क्या आप अनलॉक कर सकते हैं? जब लोग चर्चा नहीं कर सकते तो प्रगति करना वास्तव में कठिन है। या, यदि यह एक विकल्प नहीं है, तो शायद एक वैकल्पिक समाधान प्रस्तावित करें जो इस सुविधा को जनता के लिए लाने की अनुमति देता है।

नहीं, मैं इसे अनलॉक नहीं कर रहा हूं। एक निर्णय किया गया है, विषय किया गया है।

@blowdart उत्तर के लिए धन्यवाद। मैं समझता हूं कि शायद यह पर्याप्त स्पष्ट नहीं था:

या, यदि यह एक विकल्प नहीं है, तो शायद एक वैकल्पिक समाधान प्रस्तावित करें जो इस सुविधा को जनता के लिए लाने की अनुमति देता है।

मैं सराहना करता हूं कि एईएस-जीसीएम का समर्थन करने का निर्णय लिया गया है। यह बहुत अच्छा है, मैं निश्चित रूप से वह एल्गोरिदम चाहता हूं। इस प्रकार, अब वास्तव में इसका समर्थन करना अच्छा होगा। क्या आप चाहते हैं कि एईएस-जीसीएम डिजाइन और कार्यान्वयन पर चर्चा यहां हो या किसी नए अंक में?

साथ ही, यदि वह विषय किया जाता है, तो उसे बंद क्यों नहीं किया जाता? और उस मुद्दे का शीर्षक बदलकर इसे और स्पष्ट करें, क्योंकि अभी यह सुझाव देता है कि कार्यान्वयन पर चर्चा यहां होगी: https://github.com/dotnet/corefx/issues/7023। शायद कुछ ऐसा तय करें कि पहले कौन सा एईएडी एल्गोरिदम समर्थन करना है ।

दूसरे शब्दों में: मैं फीडबैक प्रदान करता हूं कि वर्तमान स्थिति में यह स्पष्ट नहीं है कि एईएस-जीसीएम को आगे बढ़ाने के लिए क्या आवश्यक है।

@ करेल्ज़

@pgolebiowski पहले से ही एक पीआर आउट है। यह संभवत: अगले सप्ताह बुधवार को मास्टर में उपलब्ध होगा।