DER（Distinguished Encoding Rules）は、ASN.1構造を標準的かつ曖昧さのない方法で表現するために使用されるバイナリエンコーディング形式です。X.509証明書はASN.1を使用して定義され、DERはBER（Basic Encoding Rules）の厳密なサブセットを提供し、任意のデータ構造に対して単一の一意のエンコーディングを保証します。
「一意のエンコード」特性は、ハッシュやデジタル署名などの暗号化操作にとって重要です。なぜなら、同じ抽象データの異なるエンコードによって異なるハッシュが生成され、署名検証が破綻する可能性があるからです。対照的に、PEMはバイナリエンコードではありません。これは基本的に、ヘッダー/フッター行（例：「BEGIN CERTIFICATE」）で囲まれた、DERデータをBase64エンコードしたテキストラッパーです。PKIは、証明書の発行、信頼、ライフサイクル管理のための全体的なフレームワークであり、エンコードではありません。RSAは、暗号化/署名に使用される非対称アルゴリズムであり、証明書のエンコード形式ではありません。したがって、オプションの中でバイナリベースの証明書エンコードプロセスはDERです。

ビットコインでは、取引はブロックに組み込まれることで承認され、ネットワークは平均約10分のブロック生成間隔を目指しています。つまり、取引はビットコインのブロックチェーンに約10分ごとに「追加」され、その周期で一連の取引を含む新しいブロックが追加されることになります。
10分という目標は、ネットワーク全体のハッシュパワーの変化に関わらず平均間隔を安定させることを目的とした、約2016ブロックごとにマイニング難易度を再調整する難易度調整メカニズムによって達成されます。これは平均値であることに注意が必要です。プルーフ・オブ・ワーク・マイニングの確率的な性質上、短期的にはブロックがより速く、またはより遅く見つかる可能性があります。他のブロックチェーンではブロック生成時間が異なります（数秒から数分）が、質問の選択肢と一般的なカリキュラムの文脈は、ビットコインの10分設計と一致しています。
したがって、正解はおよそ10分ごとです。

OTPシステム（HOTPやTOTPなど）は、共有秘密鍵と変動要素（カウンタまたは時間）を使用してパスワードのシーケンスを生成します。過去または将来のOTP値を計算する機能の基盤となる重要な秘密鍵は、シード（共有秘密鍵とも呼ばれる）です。HOTPでは、シードはHMAC関数とインクリメントされるカウンタとともに使用され、TOTPでは、シードはHMACとタイムステップ値とともに使用されます。攻撃者がシードを入手し、アルゴリズムと変動要素を知っていれば、将来のOTPを計算できます。「関数」と「暗号化アルゴリズム」は通常標準化され公開されていますが、セキュリティはシードを秘密に保つことに依存しています。初期化ベクトルは、HOTPの標準的なOTPコンポーネントではありません。
/TOTP生成。したがって、将来のOTP値を予測するために必要な要素はシードです。
シードの保護は不可欠です。シードは安全な場所に保管し（例：ハードウェアトークンによる安全な保管）、管理されたプロビジョニングプロセスを通じてのみ送信する必要があります。シードが漏洩した場合、OTPは予測可能になり、強力な第二認証要素として機能しなくなります。

対称暗号化だけでは通常は機密性は確保されるが、完全性は自動的に確保されるわけではない。
多くの暗号化モード（特に認証なしのCBCのような古いモード）は改ざんされやすく、攻撃者が暗号文を改変して復号後に平文に予測可能な変化を引き起こす可能性があります。完全性を高めるために、システムは通常、対称暗号化と、HMAC（ハッシュベースメッセージ認証コード）で使用されるハッシュ関数や、内部的に認証タグを使用するGCMのような専用の認証付き暗号化モードなどの暗号学的ハッシュベースの完全性メカニズムを組み合わせます。これらのオプションの中で、ハッシュ関数は完全性チェックを可能にする基本的な追加要素です。ハッシュ関数を使用すると、受信者が改ざんを検出するために検証するMAC（例：HMAC-SHA-256）を構築できます。初期化ベクトルとnonce値は、暗号化の一意性とランダム性を保証するために使用されますが、それ自体では完全性を保証するものではありません。エンコードアルゴリズムは表現を変更するだけで、セキュリティを変更するわけではありません。したがって、対称暗号化と並行して完全性を実装するための適切な追加入力要素はハッシュ関数であり、通常はHMACまたは同様のMAC構築の一部として使用されます。

ソフトウェアにデジタル署名を行う場合、組織はソフトウェア（またはそのマニフェスト）の暗号学的ハッシュ（ダイジェスト）を計算し、組織の秘密鍵を使用してそのダイジェストに署名します。検証は逆の方向で行われます。顧客（検証者）は組織の公開鍵を使用して署名を検証し、復元します。
署名済みのダイジェストを確認した後、受信したソフトウェアを独自にハッシュ化し、結果を比較します。ダイジェストが一致し、公開鍵で署名が検証された場合、顧客はソフトウェアが署名されてから改ざんされていないこと、および対応する秘密鍵の所有者によって署名されたことを強く確信できます。顧客は組織の秘密鍵を共有する必要はありません。共有するとセキュリティが損なわれ、偽造が可能になるためです。同様に、顧客自身の鍵は発行者の署名の検証には関係ありません。組織の公開鍵は通常、証明書チェーン（コード署名証明書）内に含まれており、検証者は発行者の身元と信頼性も検証できます。したがって、顧客は署名検証（署名済みダイジェストの「復号化」と表現されることが多い）に組織の公開鍵を使用します。