Implementation: Test vectors

[jaromil]

To help align with other implementations of this protocol I’m sharing my test vectors for design 1, which are the expected results of two cryptographic transformations in DP3T given known inputs.

Zenroom passes SHA256 FIPS140–2 and AES-CTR NIST compliancy and the vectors below match the reference implementation. ✔️

The Zenroom code used to derive a new SK is:

SK2 = HASH.new('sha256'):process(SK1)

The Zenroom code used to derive EphIDs (see the dp3t scenario implementation) is:

		local PRF = SHA256:hmac(ACK.secret_day_key, BROADCAST_KEY)
		local epd = (24*60)/ACK.epoch -- num epochs per day
		local zero = OCTET.new(epd*16):zero() -- 0 byte buffer
		ACK.ephemeral_ids = { }
		for i = 0,epd,1 do
		   local PRG = AES.ctr(PRF, zero, O.from_number(i))
		   local l,r = OCTET.chop(PRG,16)
		   table.insert(ACK.ephemeral_ids, l)
		end

Zencode used for ephids derivation:

scenario 'dp3t': Decentralized Privacy-Preserving Proximity Tracing
rule check version 1.0.0
rule input encoding hex
rule output encoding hex
Given nothing
When I set 'secret day key' to '0000000000000000000000000000000000000000000000000000000000000000' as 'hex'
and I set 'epoch' to '15' base '10'
and I set 'broadcast key' to '42726f616463617374206b6579' as 'hex'
and I create the ephemeral ids for today
Then print the 'ephemeral ids'

More info about Zenroom is available at https://dev.zenroom.org

"Broadcast Key": 42726f616463617374206b6579 (13 bytes)
SK: 0000000000000000000000000000000000000000000000000000000000000000
SK rotate (SHA256):
66687aadf862bd776c8fc18b8e9f8e20089714856ee233b3902a591d0d5f2925
SK -> PRF (HMAC):
d59d48e21935f3389e3bd3eb02cf66989190b7b09ed6c0a4b9616f49455c4f9a

EphIDs derivation (not randomized)
00000000000000000000000000000000 8fd521e6c47060efcbfdb9b801c30743
00000000000000000000000000000001 d86e56bb702117b8cf20dc4aadd42310
00000000000000000000000000000002 964ae662b3f174814660846d4f9c11e2
00000000000000000000000000000003 374d270a0c559ad1e4672fb1688ae5ad
00000000000000000000000000000004 b5d017a67940300cd28b59a94f739c0e
00000000000000000000000000000005 3208756abf0314be9ffc27a0c391ee91
00000000000000000000000000000006 75b14e4879cd0d5b06cf2b460ab5559a
00000000000000000000000000000007 6ebfd0d03f8ba78086054f313af52c81
00000000000000000000000000000008 c3db7c504dd6172d1e48804bedbaebba
00000000000000000000000000000009 72860d2d1d5a433c1e0f6bbcbefc594d
0000000000000000000000000000000a b9f56e22504d8c5742db013dfe5e55a5
0000000000000000000000000000000b be3e50ab4bed94fe5d770c3395a9295d
0000000000000000000000000000000c a1acf86d88d704498fb7cb963cc33842
0000000000000000000000000000000d a8f37052baa486f68bb26e9422d964d4
0000000000000000000000000000000e 648d8ee1ac6cb9c89e0e3e638840adba
0000000000000000000000000000000f 94ac006996b7ae34202d59f65da4ddcb
...
0000000000000000000000000000005b bd0088543e940a13eddc29aa4afd8e88
0000000000000000000000000000005c 54068ddb9836fd45ae5b8b595c7b4de9
0000000000000000000000000000005d 05ea0e9e1960975d66eddbec65c9b2fc
0000000000000000000000000000005e aa73fde541bb69b67a0876b3517178c3
0000000000000000000000000000005f f38403173134f2c65682ee799e817ef3
00000000000000000000000000000060 441a550d0872384e1d35e797623c49ae

Vectors using the public broacast key: "Broadcast key" with BOM, in hexadecimals: EFBBBF42726f616463617374206b6579 (:warning: its weird to have a BOM)

BOM prefixed Broadcast key: EFBBBF42726f616463617374206b6579
EphIDs derivation (not randomized)
00000000000000000000000000000000 fe1b1ea676d68530085ae1cc723c4d31
00000000000000000000000000000001 0243e3179c23a473ba8b4c86e1d7b1aa
00000000000000000000000000000002 fd124935dabeecf9a617d7a86b1e28b0
00000000000000000000000000000003 b8641411323c46d87fb5f0bfe08f3b56
00000000000000000000000000000004 51b5aa36a7b4b7de25d8b16a0a8bd26a
00000000000000000000000000000005 527aaf695a01e322ca4b94c8308b5be2
00000000000000000000000000000006 895ae5c00ec8bfc5e56b1c9ca51c15ec
00000000000000000000000000000007 9b608619aed1c56168dfe628f8affa5a
00000000000000000000000000000008 2f20ab131e988456e11fd73e5dc5f1c8
00000000000000000000000000000009 61e7edcb5cadd93c50f4a6d4adfb48b0
0000000000000000000000000000000a fdb4af327e25e8ab4de630ec286943f6
0000000000000000000000000000000b 2ba59ecb7218e40721cee94b0b346383
0000000000000000000000000000000c cf4264bcfec4ca4d7eb0931b0812a589
0000000000000000000000000000000d 7e3621ed6f644bcb8b4ef77a5f9db669
0000000000000000000000000000000e 5fd4044bfd7888db0e84f884b3e62a47
0000000000000000000000000000000f 251ab5cbc2071e048fff5f1dfa703e48
...
0000000000000000000000000000005b 4a670240419efe09aa43e60b06d22949
0000000000000000000000000000005c 0b504b6010892aebdf4644c92abc4819
0000000000000000000000000000005d 2a90f3179ac914b9178a4dcb9d480f75
0000000000000000000000000000005e 4274e0a715285f60a6f50a0ead03ce8c
0000000000000000000000000000005f 8fa0f78f64bac6baf0e10646df60b1ce
00000000000000000000000000000060 a43ce27ca99c2ae107dd755757edd801

[snakehand]

Could you maybe also add a few test vectors for the SK -> AES-CTR key hmac ?

[jaromil]

Sure! They are now included above below the line SK -> PRF (HMAC):

[snakehand]

I am still having problems recreating your ephemeral. From issue #57 it was pointed out that the IV starts at 0, but I suspect that you have started from 1 - still this is not the only discrepancy that I am dealing with.

[snakehand]

I have included some of these test vectors in the unit tests for the Rust library here : https://github.com/snakehand/dp-3t-client - but the epehemeral IV is is still off by 1 compared to Zenroom.

[dirkx]

@jaromil , @snakehand - having trouble generating exactly the same with Apple's crypto.

Could either of you be so kind to describe how this "n * 10000" string is serialised to uint8_t's ?

I.e some slightly lower level pseudo code ?

[snakehand]

I think you are looking at older code, the IV is a simple counter now, and nonce=0.

In Rust I do this:

            let mut serial = [0u8; 16];
            serial[12..16].copy_from_slice(&i.to_be_bytes());
            let mut block = GenericArray::clone_from_slice(&serial);
            cipher.encrypt_block(&mut block);

I.e just copy the counter to big endian bytes at the end of the 16 byte AES input block.

[dirkx]

So I see you do Aes256::new( ... with the key as HMAC of Sk and a password = "Decen.."
which yields (for me) 4d91fd2e6c3b27ed696d9a2c971cd148da9d6e13a95749e140d37c3087053ea1 if I do not include the \0.

You then do serial = 16 bytes; top 4 bytes contain a 32 bit/4byte unsigned integer in Big endian order.

And AES encrypt this rolling. And the result is again 16 bytes.

Correct ?

[jeffallen]

(This comment has been edited to sync to the reference implementation released recently.)

The following Kotlin results in the same output as the reference implementation (see DP-3T/reference_implementation#9).

    fun ephIDs(n: Int):  List<EphID> {
        val sha256_HMAC: Mac = Mac.getInstance("HmacSHA256")
        sha256_HMAC.init(SecretKeySpec(sk, "HmacSHA256"))
        val prf = sha256_HMAC.doFinal("Broadcast key".toByteArray())
        val cipher = Cipher.getInstance("AES/CTR/NoPadding")
        val b = ByteArray(16 * n)
        cipher.init(Cipher.ENCRYPT_MODE, SecretKeySpec(prf, "AES"), IvParameterSpec(ByteArray(16)))
        cipher.update(b, 0, b.size, b, 0)
        var out = mutableListOf<EphID>();
        for (i in 0 until n) {
            out.add(EphID(b.sliceArray(i*16 until i*16+16)));
        }
        return out
    }

This was useful to me in confirming that the performance would be manageable on low-spec Android phones.

[dirkx]

Ok - so in C this would be:

uint8_t b[16 = [ 0x0, 0x0 .... 0x0 ];

and I take it that IvParameterSpec(ByteArray(16) is simply an IV of 16 bytes that are 0x0 each ?

And we then create 16 byte of zero's plaintext blocks with cipher.update(). Correct.

What is your second EphiID ?

[snakehand]

I am no Java / Kotlin (?) expert but I think MessageDigest.getInstance("SHA-256") yields the wrong digest. You want to somehow use HMAC-SHA256 with SK as the key, and not just feed it into the digest algorithm

[jaromil]

To avoid further ambiguity I have updated the first post in this issue with the actual code used and with two columns for the EphID vectors: left shows the counter (used as IV / nonce) and right shows the result. In all EphID generation the AES-CTR is used with a plaintext all set to zero. It is also true that I start the counter from 01 rather than 00 as indicated in the whitepaper The vectors are now in correct order and starting from 00.

[snakehand]

@jaromil I think you have the IVs backwards, your loop is counting down in : https://github.com/DECODEproject/Zenroom/blob/master/src/lua/zencode_dp3t.lua

[snakehand]

I updated https://github.com/snakehand/dp-3t-client with a small example that prints some test vectors, including the 0 IV:

eph: 0 - Ephemeral(day:0, token:c7044845a6a0da7a61687e1bb08afca4)
eph: 1 - Ephemeral(day:0, token:a747e729bf2e3de3ec6ecbdb0f889f5b)
eph: 2 - Ephemeral(day:0, token:034015608c5a55672315cb614f5a94a3)
eph: 3 - Ephemeral(day:0, token:6c4902c119d6a7ada139677983ef02b6)
eph: 4 - Ephemeral(day:0, token:c71d3e89927435b2aae42be7e7aea70a)
eph: 5 - Ephemeral(day:0, token:b5ced4fff0f319d40a924f91aecdf1dd)
eph: 6 - Ephemeral(day:0, token:17c93fce14a191a832e217ec2e9347df)
eph: 7 - Ephemeral(day:0, token:282917263748673f63ab3416fc2e3ee9)