Ethereum Improvement Proposal - EIP8

 

 

 

 

v4wire_test.go파일을 읽어보다가 EIP8에 대해서 파악하게 됐습니다.

공부하게된 김에 원문에 있는 내용을 이해하고자 포스팅해봅니다.

EIP8: 

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8.md

GitHub - ethereum/EIPs: The Ethereum Improvement Proposal repository

Postel(포스텔)의 법칙:
https://johngrib.github.io/wiki/jargon/postel-s-law/#:~:text='%EA%B2%AC%EA%B3%A0%ED%95%A8%20%EC%9B%90%EC%B9%99'%EC%9D%B4%EB%9D%BC%EA%B3%A0%20%EB%B6%88%EB%A6%AC%EA%B8%B0,%ED%95%B4%EC%95%BC%20%ED%95%A8%EC%9D%84%20%EC%9D%98%EB%AF%B8%ED%95%9C%EB%8B%A4.

포스텔의 법칙(Postel's law)

 

 

eip	title	author	status	type	category	created
8	devp2p Forward Compatibility Requirements for Homestead	Felix Lange <felix@ethdev.com>	Final	Standards Track	Networking	2015-12-18

 

제목 : 홈스테드를 위한 devp2p  전방적 호환성 요구 사항

 

요약

 

이 EIP(Ethereum Improvement Proposal)은 devp2p 와이어 프로토콜, RLPx 검색 프로토콜 및 RLPx TCP 전송 프로토콜 구현을 위한 새로운 전방 호환성 요구 사항을 소개합니다. EIP-8을 구현하는 클라이언트는 Postel의 법칙에 따라 작동합니다.

당신이 하는 일에서는 보수적이고, 다른 사람으로부터 받아들이는 것에서는 자유로워라.

 

 

명세

 

devp2p 와이어 프로토콜 구현은 hello 패킷의 버전 번호를 무시해야 합니다. hello 패킷을 보낼 때, 버전 요소는 지원되는 가장 높은 devp2p 버전으로 설정되어야 합니다. 구현은 또한 hello 패킷 끝에 추가적인 리스트 요소를 무시해야 합니다.

마찬가지로, RLPx 검색 프로토콜의 구현은 ping 패킷의 버전 번호를 검증하지 않아야 하며, 어떤 패킷에서든지 추가적인 리스트 요소를 무시하고, 패킷의 첫 번째 RLP 값 이후의 데이터를 무시해야 합니다. 알 수 없는 패킷 유형의 검색 패킷은 조용히 삭제되어야 합니다. 검색 패킷의 최대 크기는 여전히 1280 바이트입니다.

 

마지막으로, RLPx TCP 전송 프로토콜의 구현은 암호화된 키 설정 핸드셰이크 패킷의 새로운 인코딩을 허용해야 합니다. EIP-8 스타일의 RLPx 인증 패킷이 수신되면, 해당하는 ack 패킷은 아래 규칙을 사용하여 전송되어야 합니다.

auth-body 및 ack-body의 RLP 데이터를 디코딩할 때 auth-vsn 및 ack-vsn의 불일치, 추가적인 리스트 요소 및 리스트 이후의 임의 데이터는 무시해야 합니다. 전환 기간 동안 (즉, 이전 형식이 폐기될 때까지), 구현은 auth-body를 적어도 100바이트의 쓰레기 데이터로 패딩해야 합니다. 패킷 크기를 다양화하기 위해 [100, 300] 범위의 임의의 양을 추가하는 것이 권장됩니다.

 

auth-vsn         = 4
auth-size        = size of enc-auth-body, encoded as a big-endian 16-bit integer
auth-body        = rlp.list(sig, initiator-pubk, initiator-nonce, auth-vsn)
enc-auth-body    = ecies.encrypt(recipient-pubk, auth-body, auth-size)
auth-packet      = auth-size || enc-auth-body

ack-vsn          = 4
ack-size         = size of enc-ack-body, encoded as a big-endian 16-bit integer
ack-body         = rlp.list(recipient-ephemeral-pubk, recipient-nonce, ack-vsn)
enc-ack-body     = ecies.encrypt(initiator-pubk, ack-body, ack-size)
ack-packet       = ack-size || enc-ack-body

where

X || Y
    denotes concatenation of X and Y.
X[:N]
    denotes an N-byte prefix of X.
rlp.list(X, Y, Z, ...)
    denotes recursive encoding of [X, Y, Z, ...] as an RLP list.
sha3(MESSAGE)
    is the Keccak256 hash function as used by Ethereum.
ecies.encrypt(PUBKEY, MESSAGE, AUTHDATA)
    is the asymmetric authenticated encryption function as used by RLPx.
    AUTHDATA is authenticated data which is not part of the resulting ciphertext,
    but written to HMAC-256 before generating the message tag.

동기

 

devp2p 프로토콜에 대한 변경 사항은 오래된 버전을 실행하는 클라이언트가 로컬 예상과 일치하지 않는 버전 번호 또는 구조를 가진 hello (discovery ping, RLPx handshake) 패킷에 대해 통신을 거부하기 때문에 배포하기 어렵습니다.

Homestead 합의 업그레이드의 일부로 전방 호환성 요구 사항을 도입하면, 역방향 호환성이 유지되는 한 이더리움 네트워크에서 사용되는 모든 클라이언트 소프트웨어가 미래의 네트워크 프로토콜 업그레이드를 대처할 수 있습니다.

이유

제안된 변경 사항은 프로토콜 스택 전체에 Postel의 법칙 (또는 견고성 원칙)을 적용하여 전방 호환성을 다룹니다. 이 접근 방식의 장점과 적용 가능성은 RFC 761에서 처음 적용된 이후 반복적으로 연구되어 왔습니다. 최근의 관점으로는 "The Robustness Principle Reconsidered" (Eric Allman, 2011)를 참조하십시오.

devp2p Wire Protocol 변경 사항
모든 클라이언트에는 현재 다음과 같은 문장이 포함되어 있습니다:

 

# pydevp2p/p2p_protocol.py
if data['version'] != proto.version:
    log.debug('incompatible network protocols', peer=proto.peer,
        expected=proto.version, received=data['version'])
    return proto.send_disconnect(reason=reasons.incompatibel_p2p_version)

이러한 체크들은 hello 패킷의 버전이나 구조를 변경하는 것을 불가능하게 만듭니다. 이러한 체크들을 제거하면 더 높은 프로토콜 버전으로 전환할 수 있습니다. 새로운 버전을 사용하는 클라이언트는 더 높은 버전과 추가적인 리스트 요소를 포함한 패킷을 보내면 됩니다.

만약 낮은 버전을 사용하는 노드가 이러한 패킷을 받으면, 이 노드는 뒤로 호환 가능하다고 가정하고 오래된 핸드쉐이크로 응답합니다. 만약 동일한 버전을 사용하는 노드가 이 패킷을 받으면, 새로운 프로토콜 기능을 사용할 수 있습니다. 그리고 더 높은 버전을 사용하는 노드가 이 패킷을 받으면, 뒤로 호환 가능한 로직을 활성화하거나 연결을 끊을 수 있습니다.

 

RLPx Discovery 프로토콜 변경

 

발견 패킷 디코딩 규칙의 완화는 대부분의 구현에서 현재 사용되는 관행을 대부분 코드화합니다. 리스트 요소 수에 대해 신경쓰지 않는 구현이 많으며(go-ethereum를 제외하고), 버전이 일치하지 않는 노드를 거부하지 않습니다. 하지만 이러한 동작은 명세서에 보장되지는 않습니다.

 

이 변경이 채택된다면, 개발자 피어 hello 변경과 유사한 방식으로 프로토콜 변경을 배포할 수 있게 됩니다. 단순히 버전을 올리고 추가 정보를 보내면 됩니다. 이전 클라이언트는 추가적인 요소를 무시하고 대다수의 네트워크가 더 높은 프로토콜로 이동한 경우에도 계속 작동할 수 있습니다.

 

 

 

 

 

 

 

RLPx TCP 핸드셰이크 변경 사항

RLPx v5 변경 사항 (청크 패킷, 키 파생 변경)에 대한 논의는 일부분에서 v4 핸드셰이크 인코딩은 버전 번호를 추가하는 유일한 인밴드 방법으로 nonce의 무작위 부분을 줄이는 것뿐이기 때문에 중단되었습니다. 심지어 RLPx v5 핸드셰이크 제안이 승인되더라도 핸드셰이크 패킷은 알려진 레이아웃을 가진 고정 크기 ECIES 암호화문입니다.

핸드셰이크 패킷에 다음과 같은 변경 사항을 제안합니다:

• 암호화문의 길이를 평문 헤더로 추가합니다.
• 핸드셰이크의 본문을 RLP로 인코딩합니다.
• 토큰 플래그(미사용) 대신 두 패킷에 버전 번호를 추가합니다.
• 일시적인 공개 키의 해시를 제거합니다(중복).

이러한 변경으로 다른 프로토콜과 같은 방식으로 RLPx TCP 전송 프로토콜을 업그레이드 할 수 있습니다. 즉, 리스트 요소를 추가하고 버전을 올리는 것입니다. 이것이 RLPx 핸드셰이크 패킷에 대한 첫 번째 변경이므로 현재 사용되지 않는 모든 필드를 제거할 수 있는 기회입니다.

RLP 리스트 이후에 추가 데이터가 허용되고(실제로 필요합니다) 핸드셰이크 패킷이 이전 형식과 구별될 수 있도록 성장해야 합니다. 클라이언트는 다음과 같은 유사 코드를 사용하여 두 형식을 동시에 처리할 수 있습니다.

packet = read(307, connection)
if decrypt(packet) {
    // process as old format
} else {
    size = unpack_16bit_big_endian(packet)
    packet += read(size - 307 + 2, connection)
    if !decrypt(packet) {
        // error
    }
    // process as new format
}

이 문서에서 평문 크기 접두사는 아마도 가장 논란이 많은 측면입니다. 이 접두사는 네트워크 수준에서 RLPx 연결을 필터링하고 식별하려는 이들에게 도움이 되는 것으로 주장되었습니다.

이것은 대부분 적대자가 얼마나 많은 노력을 기울일 의지가 있는지에 따른 문제입니다. 길이를 무작위화하는 권장 사항을 따르면, 순수한 패턴 기반 패킷 인식은 성공할 가능성이 적습니다.

일반적인 방화벽 운영자들에게는, 첫 두 바이트가 [300,600] 범위의 정수를 형성하는 모든 연결을 차단하는 것은 너무 침해적일 수 있습니다. 포트 기반 차단은 대부분의 RLPx 트래픽을 필터링하는 더 효과적인 방법입니다.

여러 기준을 연관시킬 수 있는 공격자는 크기 접두사가 추가되어 인디케이터 집합에 기여하므로 인식하기 쉬울 수 있습니다. 그러나 이러한 공격자는 RLPx Discovery 트래픽을 읽거나 참여할 것으로 예상됩니다. 이는 그들이 어떤 형식이든 RLPx TCP 연결을 차단할 수 있도록 충분합니다.

하위 호환성 이 EIP는 하위 호환성이 있으며, 모든 유효한 버전 4 패킷이 여전히 허용됩니다.

 

 

Implementation

go-ethereum libweb3core pydevp2p

Test Vectors

devp2p Base Protocol

devp2p hello packet advertising version 22 and containing a few additional list elements:

f87137916b6e6574682f76302e39312f706c616e39cdc5836574683dc6846d6f726b1682270fb840
fda1cff674c90c9a197539fe3dfb53086ace64f83ed7c6eabec741f7f381cc803e52ab2cd55d5569
bce4347107a310dfd5f88a010cd2ffd1005ca406f1842877c883666f6f836261720304

RLPx Discovery Protocol

Implementations should accept the following encoded discovery packets as valid. The packets are signed using the secp256k1 node key

b71c71a67e1177ad4e901695e1b4b9ee17ae16c6668d313eac2f96dbcda3f291

ping packet with version 4, additional list elements:

e9614ccfd9fc3e74360018522d30e1419a143407ffcce748de3e22116b7e8dc92ff74788c0b6663a
aa3d67d641936511c8f8d6ad8698b820a7cf9e1be7155e9a241f556658c55428ec0563514365799a
4be2be5a685a80971ddcfa80cb422cdd0101ec04cb847f000001820cfa8215a8d790000000000000
000000000000000000018208ae820d058443b9a3550102

ping packet with version 555, additional list elements and additional random data:

577be4349c4dd26768081f58de4c6f375a7a22f3f7adda654d1428637412c3d7fe917cadc56d4e5e
7ffae1dbe3efffb9849feb71b262de37977e7c7a44e677295680e9e38ab26bee2fcbae207fba3ff3
d74069a50b902a82c9903ed37cc993c50001f83e82022bd79020010db83c4d001500000000abcdef
12820cfa8215a8d79020010db885a308d313198a2e037073488208ae82823a8443b9a355c5010203
040531b9019afde696e582a78fa8d95ea13ce3297d4afb8ba6433e4154caa5ac6431af1b80ba7602
3fa4090c408f6b4bc3701562c031041d4702971d102c9ab7fa5eed4cd6bab8f7af956f7d565ee191
7084a95398b6a21eac920fe3dd1345ec0a7ef39367ee69ddf092cbfe5b93e5e568ebc491983c09c7
6d922dc3

pong packet with additional list elements and additional random data:

09b2428d83348d27cdf7064ad9024f526cebc19e4958f0fdad87c15eb598dd61d08423e0bf66b206
9869e1724125f820d851c136684082774f870e614d95a2855d000f05d1648b2d5945470bc187c2d2
216fbe870f43ed0909009882e176a46b0102f846d79020010db885a308d313198a2e037073488208
ae82823aa0fbc914b16819237dcd8801d7e53f69e9719adecb3cc0e790c57e91ca4461c9548443b9
a355c6010203c2040506a0c969a58f6f9095004c0177a6b47f451530cab38966a25cca5cb58f0555
42124e

findnode packet with additional list elements and additional random data:

c7c44041b9f7c7e41934417ebac9a8e1a4c6298f74553f2fcfdcae6ed6fe53163eb3d2b52e39fe91
831b8a927bf4fc222c3902202027e5e9eb812195f95d20061ef5cd31d502e47ecb61183f74a504fe
04c51e73df81f25c4d506b26db4517490103f84eb840ca634cae0d49acb401d8a4c6b6fe8c55b70d
115bf400769cc1400f3258cd31387574077f301b421bc84df7266c44e9e6d569fc56be0081290476
7bf5ccd1fc7f8443b9a35582999983999999280dc62cc8255c73471e0a61da0c89acdc0e035e260a
dd7fc0c04ad9ebf3919644c91cb247affc82b69bd2ca235c71eab8e49737c937a2c396

neighbours packet with additional list elements and additional random data:

c679fc8fe0b8b12f06577f2e802d34f6fa257e6137a995f6f4cbfc9ee50ed3710faf6e66f932c4c8
d81d64343f429651328758b47d3dbc02c4042f0fff6946a50f4a49037a72bb550f3a7872363a83e1
b9ee6469856c24eb4ef80b7535bcf99c0004f9015bf90150f84d846321163782115c82115db84031
55e1427f85f10a5c9a7755877748041af1bcd8d474ec065eb33df57a97babf54bfd2103575fa8291
15d224c523596b401065a97f74010610fce76382c0bf32f84984010203040101b840312c55512422
cf9b8a4097e9a6ad79402e87a15ae909a4bfefa22398f03d20951933beea1e4dfa6f968212385e82
9f04c2d314fc2d4e255e0d3bc08792b069dbf8599020010db83c4d001500000000abcdef12820d05
820d05b84038643200b172dcfef857492156971f0e6aa2c538d8b74010f8e140811d53b98c765dd2
d96126051913f44582e8c199ad7c6d6819e9a56483f637feaac9448aacf8599020010db885a308d3
13198a2e037073488203e78203e8b8408dcab8618c3253b558d459da53bd8fa68935a719aff8b811
197101a4b2b47dd2d47295286fc00cc081bb542d760717d1bdd6bec2c37cd72eca367d6dd3b9df73
8443b9a355010203b525a138aa34383fec3d2719a0

RLPx Handshake

In these test vectors, node A initiates a connection with node B. The values contained in all packets are given below:

Static Key A:    49a7b37aa6f6645917e7b807e9d1c00d4fa71f18343b0d4122a4d2df64dd6fee
Static Key B:    b71c71a67e1177ad4e901695e1b4b9ee17ae16c6668d313eac2f96dbcda3f291
Ephemeral Key A: 869d6ecf5211f1cc60418a13b9d870b22959d0c16f02bec714c960dd2298a32d
Ephemeral Key B: e238eb8e04fee6511ab04c6dd3c89ce097b11f25d584863ac2b6d5b35b1847e4
Nonce A:         7e968bba13b6c50e2c4cd7f241cc0d64d1ac25c7f5952df231ac6a2bda8ee5d6
Nonce B:         559aead08264d5795d3909718cdd05abd49572e84fe55590eef31a88a08fdffd

(Auth₁) RLPx v4 format (sent from A to B):

048ca79ad18e4b0659fab4853fe5bc58eb83992980f4c9cc147d2aa31532efd29a3d3dc6a3d89eaf
913150cfc777ce0ce4af2758bf4810235f6e6ceccfee1acc6b22c005e9e3a49d6448610a58e98744
ba3ac0399e82692d67c1f58849050b3024e21a52c9d3b01d871ff5f210817912773e610443a9ef14
2e91cdba0bd77b5fdf0769b05671fc35f83d83e4d3b0b000c6b2a1b1bba89e0fc51bf4e460df3105
c444f14be226458940d6061c296350937ffd5e3acaceeaaefd3c6f74be8e23e0f45163cc7ebd7622
0f0128410fd05250273156d548a414444ae2f7dea4dfca2d43c057adb701a715bf59f6fb66b2d1d2
0f2c703f851cbf5ac47396d9ca65b6260bd141ac4d53e2de585a73d1750780db4c9ee4cd4d225173
a4592ee77e2bd94d0be3691f3b406f9bba9b591fc63facc016bfa8

(Auth₂) EIP-8 format with version 4 and no additional list elements (sent from A to B):

01b304ab7578555167be8154d5cc456f567d5ba302662433674222360f08d5f1534499d3678b513b
0fca474f3a514b18e75683032eb63fccb16c156dc6eb2c0b1593f0d84ac74f6e475f1b8d56116b84
9634a8c458705bf83a626ea0384d4d7341aae591fae42ce6bd5c850bfe0b999a694a49bbbaf3ef6c
da61110601d3b4c02ab6c30437257a6e0117792631a4b47c1d52fc0f8f89caadeb7d02770bf999cc
147d2df3b62e1ffb2c9d8c125a3984865356266bca11ce7d3a688663a51d82defaa8aad69da39ab6
d5470e81ec5f2a7a47fb865ff7cca21516f9299a07b1bc63ba56c7a1a892112841ca44b6e0034dee
70c9adabc15d76a54f443593fafdc3b27af8059703f88928e199cb122362a4b35f62386da7caad09
c001edaeb5f8a06d2b26fb6cb93c52a9fca51853b68193916982358fe1e5369e249875bb8d0d0ec3
6f917bc5e1eafd5896d46bd61ff23f1a863a8a8dcd54c7b109b771c8e61ec9c8908c733c0263440e
2aa067241aaa433f0bb053c7b31a838504b148f570c0ad62837129e547678c5190341e4f1693956c
3bf7678318e2d5b5340c9e488eefea198576344afbdf66db5f51204a6961a63ce072c8926c

(Auth₃) EIP-8 format with version 56 and 3 additional list elements (sent from A to B):

01b8044c6c312173685d1edd268aa95e1d495474c6959bcdd10067ba4c9013df9e40ff45f5bfd6f7
2471f93a91b493f8e00abc4b80f682973de715d77ba3a005a242eb859f9a211d93a347fa64b597bf
280a6b88e26299cf263b01b8dfdb712278464fd1c25840b995e84d367d743f66c0e54a586725b7bb
f12acca27170ae3283c1073adda4b6d79f27656993aefccf16e0d0409fe07db2dc398a1b7e8ee93b
cd181485fd332f381d6a050fba4c7641a5112ac1b0b61168d20f01b479e19adf7fdbfa0905f63352
bfc7e23cf3357657455119d879c78d3cf8c8c06375f3f7d4861aa02a122467e069acaf513025ff19
6641f6d2810ce493f51bee9c966b15c5043505350392b57645385a18c78f14669cc4d960446c1757
1b7c5d725021babbcd786957f3d17089c084907bda22c2b2675b4378b114c601d858802a55345a15
116bc61da4193996187ed70d16730e9ae6b3bb8787ebcaea1871d850997ddc08b4f4ea668fbf3740
7ac044b55be0908ecb94d4ed172ece66fd31bfdadf2b97a8bc690163ee11f5b575a4b44e36e2bfb2
f0fce91676fd64c7773bac6a003f481fddd0bae0a1f31aa27504e2a533af4cef3b623f4791b2cca6
d490

(Ack₁) RLPx v4 format (sent from B to A):

049f8abcfa9c0dc65b982e98af921bc0ba6e4243169348a236abe9df5f93aa69d99cadddaa387662
b0ff2c08e9006d5a11a278b1b3331e5aaabf0a32f01281b6f4ede0e09a2d5f585b26513cb794d963
5a57563921c04a9090b4f14ee42be1a5461049af4ea7a7f49bf4c97a352d39c8d02ee4acc416388c
1c66cec761d2bc1c72da6ba143477f049c9d2dde846c252c111b904f630ac98e51609b3b1f58168d
dca6505b7196532e5f85b259a20c45e1979491683fee108e9660edbf38f3add489ae73e3dda2c71b
d1497113d5c755e942d1

(Ack₂) EIP-8 format with version 4 and no additional list elements (sent from B to A):

01ea0451958701280a56482929d3b0757da8f7fbe5286784beead59d95089c217c9b917788989470
b0e330cc6e4fb383c0340ed85fab836ec9fb8a49672712aeabbdfd1e837c1ff4cace34311cd7f4de
05d59279e3524ab26ef753a0095637ac88f2b499b9914b5f64e143eae548a1066e14cd2f4bd7f814
c4652f11b254f8a2d0191e2f5546fae6055694aed14d906df79ad3b407d94692694e259191cde171
ad542fc588fa2b7333313d82a9f887332f1dfc36cea03f831cb9a23fea05b33deb999e85489e645f
6aab1872475d488d7bd6c7c120caf28dbfc5d6833888155ed69d34dbdc39c1f299be1057810f34fb
e754d021bfca14dc989753d61c413d261934e1a9c67ee060a25eefb54e81a4d14baff922180c395d
3f998d70f46f6b58306f969627ae364497e73fc27f6d17ae45a413d322cb8814276be6ddd13b885b
201b943213656cde498fa0e9ddc8e0b8f8a53824fbd82254f3e2c17e8eaea009c38b4aa0a3f306e8
797db43c25d68e86f262e564086f59a2fc60511c42abfb3057c247a8a8fe4fb3ccbadde17514b7ac
8000cdb6a912778426260c47f38919a91f25f4b5ffb455d6aaaf150f7e5529c100ce62d6d92826a7
1778d809bdf60232ae21ce8a437eca8223f45ac37f6487452ce626f549b3b5fdee26afd2072e4bc7
5833c2464c805246155289f4

(Ack₃) EIP-8 format with version 57 and 3 additional list elements (sent from B to A):

01f004076e58aae772bb101ab1a8e64e01ee96e64857ce82b1113817c6cdd52c09d26f7b90981cd7
ae835aeac72e1573b8a0225dd56d157a010846d888dac7464baf53f2ad4e3d584531fa203658fab0
3a06c9fd5e35737e417bc28c1cbf5e5dfc666de7090f69c3b29754725f84f75382891c561040ea1d
dc0d8f381ed1b9d0d4ad2a0ec021421d847820d6fa0ba66eaf58175f1b235e851c7e2124069fbc20
2888ddb3ac4d56bcbd1b9b7eab59e78f2e2d400905050f4a92dec1c4bdf797b3fc9b2f8e84a482f3
d800386186712dae00d5c386ec9387a5e9c9a1aca5a573ca91082c7d68421f388e79127a5177d4f8
590237364fd348c9611fa39f78dcdceee3f390f07991b7b47e1daa3ebcb6ccc9607811cb17ce51f1
c8c2c5098dbdd28fca547b3f58c01a424ac05f869f49c6a34672ea2cbbc558428aa1fe48bbfd6115
8b1b735a65d99f21e70dbc020bfdface9f724a0d1fb5895db971cc81aa7608baa0920abb0a565c9c
436e2fd13323428296c86385f2384e408a31e104670df0791d93e743a3a5194ee6b076fb6323ca59
3011b7348c16cf58f66b9633906ba54a2ee803187344b394f75dd2e663a57b956cb830dd7a908d4f
39a2336a61ef9fda549180d4ccde21514d117b6c6fd07a9102b5efe710a32af4eeacae2cb3b1dec0
35b9593b48b9d3ca4c13d245d5f04169b0b1

Node B derives the connection secrets for (Auth₂, Ack₂) as follows:

aes-secret = 80e8632c05fed6fc2a13b0f8d31a3cf645366239170ea067065aba8e28bac487
mac-secret = 2ea74ec5dae199227dff1af715362700e989d889d7a493cb0639691efb8e5f98

Running B's ingress-mac keccak state on the string "foo" yields the hash

ingress-mac("foo") = 0c7ec6340062cc46f5e9f1e3cf86f8c8c403c5a0964f5df0ebd34a75ddc86db5

Copyright

Copyright and related rights waived via CC0.