Comorbilidades

In this section, we look at the X3DH scenario and how much CPU cycles (Section 6.2.1), key storage (Section6.2.2) and network load (Section6.2.3) the X3DH Scenario uses withSIDH503andSIDH751instead ofECDH.

In the X3DH scenario Alice is going to send the first message to Bob. She has received the pre-key bundle from Bob and will use the X3DH protocol and initiate the Double Ratchet chain to do so. To do that Alice generates one ephemeral key pair and three shared secrets, created as described in Section5.2. The X3DH scenario is tested withECDH,SIDH503andSIDH751(as was explained in Section 5.3).

6.2.1

CPU cycles

In this section, we evaluate the average number of CPU cycles the X3DH scenario needs with bothECDHandSIDH. The X3DH scenario was executed 1000 times,

which means we created one EK key pair and three shared secrets 1000 times. For every iteration we measured the number of CPU cycles. We took the average number of CPU cycles for one X3DH scenario and calculated the time it would take to do one scenario on the minimal phone.

The number of CPU cycles needed for one contact; to create one key pair and three shared secrets, can be seen in Table6.4.

X3DH scenario 1 contact (creating: 1 key pair and 3 shared secrets)

Algorithm Average CPU cycles Standard deviation CPU cycles Time (ms) Factor

ECDH 591010.82 51696 0.0004 1.00

SIDH503 23227464 508919.78 0.0166 39.30

SIDH751 64376866 3915170.33 0.0460 108.93

Tab. 6.4.: The number of CPU cycles needed to generate the shared secrets for one contact, following the X3DH scenario. The factor is the ratio between SIDH andECDH. The time is the time it would take to add that many contacts on the minimal phone.

We see thatSIDH751 needs almost a factor 109 more CPU cycles thanECDH, whileSIDH503needs a factor 39 more. For our average user it would roughly take0.017seconds to add one new contact withSIDH503and0.046seconds with SIDH751, as can be seen in Table6.4. For an average user this delay is acceptable because it is below 0.1 second

To get the number of CPU cycles and time it takes for an average user to initiate contact with 100 contacts at the same time, we multiply the time and CPU cycles with 100. Hundred contacts is the number of contacts an average user had. It would take1.7and4.6seconds forSIDH503andSIDH751respectively, where it would only take0.04seconds withECDH. The standard deviation is a lot smaller forECDH in this scenario than it was with the initial scenario.

We assumed that both the initial scenario and the X3DH scenario was linear, and when this assumption was tested we found that it was. The complete data table for this linearity can be found in the AppendixC, TableC.1and figureC.1.

6.2.2

Key storage

In this section, we evaluate how much storage space is required for the X3DH scenario. The key pair,EK, is used to generate the shared secret and then the public part ofEK is send to Bob. After that the key does not have to be stored. The created shared secrets are put in a key derivation function, to derive the message key, and are not needed after that. In the initial scenario, therefore, no storage space required for the used keys.

There are, of course, keys that need storage: the message keys and chain keys. In this thesis we focus on the post-quantum algorithms. Therefore, we excluded the storage space needed for the symmetric message keys and the CPU cycles for to create those as well. Both in our post-quantum Signal Protocol, and the Signal Protocol withECDHthe same KDF function is used, namely SHA-512. So whether we use a post-quantum algorithm orECDH the shared secrets and the symmetric message key will have the same length. Therefore, we will not take the size of those into account here.

Note that for the first Double Ratchet step a key should be stored, namely the key pairA1. However, this key is excluded from the X3DH scenario because it is already included in the Double Ratchet scenario.

6.2.3

Bandwidth and network utilisation

In this section, we look at the bandwidth and network utilisation needed for the X3DH scenario, in which the first message is sent. The created public keyEK should be send to the other users, together with the public identity key of Alice, IK. The three shared secrets are obviously not shared over the network. In Table 6.5the size of one public key is shown, together with the network utilisation and the bandwidth for 200 public keys.

Algorithm 1 public key 200 public keys sec Factor

ECDH 32 B 6400 B 0.006 1

SIDH503 378 B 75600 B 0.072 11.8 SIDH751 564 B 112800 B 0.108 17.6

Tab. 6.5.: The different algorithms in the X3DH key exchange and the storage space they require to store the 102 private keys, for the user, and 102 public keys, for the server.

If a user would send all his 100 contacts the first message at once, this would result in sending 200 keys. The network utilisation for 200 keys withECDHis 6.3 KB and it would take 0.006 seconds to send that data. SIDHwill require a factor 11.8 more forSIDH503and 17.6 forSIDH751in comparison toECDH. This results in a network utilisation of73.8KB forSIDH503and110.2KB forSIDH751, as can be seen in Table. Sending this data over a 1 MBps connection will result in a bandwidth of0.072and0.108seconds in total. Again for an average user this delay is acceptable because it is below 0.1 second

6.2.4

A post-quantum X3DH scenario

In this section, we summarise the previous three sections, to see how much CPU cycles are needed, storage space is required and bandwidth is needed for the X3DH scenario. The overview can be seen in Table6.6.

X3DH scenario Creating and generating Network load CPU Time Storage Time Size ECDH 59101082 0.04 s 0 KB 0.006 s 6.3 KB SIDH503 2322746441 1.66 s 0 KB 0.072 s 73.8 KB SIDH751 6437686648 4.60 s 0 KB 0.108 s 110.2 KB

Tab. 6.6.: The values for an average user in the X3DH scenario, withECDHandSIDH. The number of CPU cycles, time (s), storage space (KB), bandwidth (s) and network utilisation (KB) are shown.

Remember that the average user has 100 contacts, and that the table shows what would happen if the user would send them all a first message at once (follow the X3DH scenario 100 times). In most cases the X3DH scenario would not be done for 100 contacts at the same time. However, there is a case: if you lost your phone on new years eve, instantly bought a new one, and want to send all your contacts a first message wishing them a happy new year. In that specific case the Table shows, for an average user, what the impact will be on CPU cycles, time and network load for all three algorithms.

In that worst case scenario it would takeSIDH503only 1.7 seconds to create the keys and shared secrets and another 0.07 seconds to send them. ForSIDH751 this will be a bit longer: 4.6 seconds to create the keys and shared secrets, and 0.1 second to send them. It is below 10 seconds which we define as fine, but annoying for the user. Luckily this worst case scenario will not happen daily. In a better case, in which a user maybe initiate the first message with a few users at the time, the extra delay, usingSIDH instead ofECDH, is not that big. For example it will take less than half a second forSIDH751and less than 0.2 seconds forSIDH503to send ten contacts a first message. In this case the average user will have to wait less than a 1second, which we defined as a doable but noticeable delay for an average user. Again this first message is only sent once to each contact the user has, not daily or weekly.