summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMatt David <matt@netki.com>2016-04-27 10:01:03 -0700
committerMatt David <matt@netki.com>2016-04-27 10:01:03 -0700
commit057591da8c25e296e71333b355d12fe6fa6e81d2 (patch)
treef836e1a97582fbfaf994842fbed655c785fcfef8
parentdcbbc871dc552f946a1ddf56190f3bf22ed1fcdf (diff)
downloadbips-057591da8c25e296e71333b355d12fe6fa6e81d2.tar.xz
Fix spacing again and pull IV size down to 12 bytes in accord with NIST 800-38D
-rw-r--r--bip-0075.mediawiki6
1 files changed, 4 insertions, 2 deletions
diff --git a/bip-0075.mediawiki b/bip-0075.mediawiki
index b3e3498..27dbc44 100644
--- a/bip-0075.mediawiki
+++ b/bip-0075.mediawiki
@@ -200,6 +200,7 @@ The process of communicating using encrypted Payment Protocol messages is enumer
# The PaymentRequest is processed according to [[bip-0070.mediawiki|BIP70]], including optional Payment and PaymentACK messages encapsulated in EncryptedProtocolMessage messages.
'''NOTE:''' See [[#Initial_Public_Key_Retrieval_for_InvoiceRequest_Encryption|Initial Public Key Retrieval for InvoiceRequest Encryption]] for possible options to retrieve Receiver's public key.
+
<img src="bip-0075/encrypted-invoice-request-process.png" alt="Flow diagram of Encrypted InvoiceRequest">
==Message Interaction Details==
@@ -310,11 +311,11 @@ For the following we assume the Sender already knows the Receiver's public key,
** Use the given message's '''nonce''' field for Nonce
* Initialize AES-256 in GCM Mode
** Use HMAC_DRBG.GENERATE(32) as the Encryption Key (256 bits)
-** Use HMAC_DRBG.GENERATE(16) as the Initialization Vector (IV) (128 bits)
+** Use HMAC_DRBG.GENERATE(12) as the Initialization Vector (IV) (96 bits)
====AES-256 GCM Authentication Tag Use====
The 16 byte authentication tag resulting from the AES-GCM encrypt operation MUST be prefixed to the returned ciphertext. The decrypt operation will use the first 16 bytes of the ciphertext as the GCM authentication tag and the remainder of the ciphertext as the ciphertext in the decrypt operation.
-
+
====AES-256 GCM Additional Authenticated Data====
When either '''status_code''' OR '''status_message''' are present, the AES-256 GCM authenticated data used in both the encrypt and decrypt operations MUST be: STRING(status_code) || status_message. Otherwise, there is no additional authenticated data. This provides that, while not encrypted, the status_code and status_message are authenticated.
@@ -367,6 +368,7 @@ The following diagram shows a sample flow in which one mobile client is sending
* [[bip-0070.mediawiki|BIP70 - Payment Protocol]]
* [https://en.wikipedia.org/wiki/Elliptic_curve_Diffie–Hellman ECDH]
* [http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf HMAC_DRBG]
+* [http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf NIST Special Publication 800-38D - Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC]
* [https://tools.ietf.org/html/rfc6979 RFC6979]
* [https://en.bitcoin.it/wiki/Address_reuse Address Reuse]
* [http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf FIPS 180-4 (Secure Hash Standard)]