ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Signature size128
2
metadata (name, size, digest) for a single image or layer71
3
Total overhead for image with 1 layer199
4
Overhead as percent of image size0.0001%
5
These tables compare the client's metadata overhead for a signature only solution with the metadata overhead for design options 1 and 2. The first table shows how much metadata clients will need to download for a registry with a single image, and the second table shows the numbers for a registry with 50,000 images. As you can see, design option 1 does not scale well for large registries. The third table includes the amount of storage on the registry needed for each image.
6
A registry with a single image
7
No snapshot proposal (Lasker)TUF Design Option 1TUF Design Option 2 fresh clientDesign Option 2 using all prior snapshots (15 prior snapshots)
8
Estimated per-client d/l
9
Image only200,000,000200,000,000200,000,000200,000,000
10
Existing OCI metadata3,5830.00179%3,5830.00179%3,5830.0018%3,5830.00179%
11
Added signatures / metadata1990.00010%6330.00032%1,5410.0008%94950.00475%
12
total200,003,7820.00189%200,004,2160.00211%200,005,1240.0026%200,013,0780.00654%
13
Security issues, reason for redinstant snapshot protection, efficientDaily limit on snapshot replayDaily limit on snapshot replay
14
See https://docs.google.com/document/d/1w8PFELVxt4p1aMk5oJv0RbDyd5J4OyvwguNSNZ1sJNw/edit?ts=5ed53663&pli=1#heading=h.5zk0sv9j8kvw
15
16
A large public registry
17
No snapshot proposal (Lasker)TUF Design Option 1Design Option 2 with succinct hash bins fresh clientDesign Option 2 with succinct hash bins using all prior snapshots (15 prior snapshots)
18
Image only200,000,000200,000,000200,000,000200,000,000
19
Existing OCI metadata3,5830.00179%3,5830.00179%3,5830.00179%3,5830.00179%
20
Added signatures / metadata1990.00010%18,330,000,2369165%5,5540.00278%83,3100.04166%
21
total200,003,7820.00189%18,530,003,8199165%200,009,1370.00457%200,086,8930.04345%
22
Security issues, reason for redinstant snapshot protection, inefficientDaily limit on snapshot replayDaily snapshot replay, is efficient
23
See https://docs.google.com/document/d/1w8PFELVxt4p1aMk5oJv0RbDyd5J4OyvwguNSNZ1sJNw/edit?ts=5ed53663&pli=1#heading=h.5zk0sv9j8kvw
24
25
Registry Storage Space per image
26
Image only200,000,000200,000,000
27
Existing OCI metadata3,5830.00179%3,5830.00179%
28
Added metadata and signatures1990.00010%4370.00022%
29
30
In the previous calculations, we assume each targets file has a single image and delegation. What if a single targets file has a lot of delegations? A single targets file that delegated to all images in a registry could take 2.7 GB and would need to be downloaded by every client. Instead, you can use hashed bin delegations to automatically delegate to intermediate targets metadata based on the hash of the targets file so that clients only have to download a small portion of this targets file. This section lays out the metadata overhead when using hashed bin delegations to delegate to all public images on the registry. This will reduce the amount of metadata that a user will have to download in order to get a targets file. In this example, efficient hashed bin delegations that use the same key for all bins. The number of bins can be adjusted depending on the number of delegations. For more information about hashed bin delegations, see https://www.python.org/dev/peps/pep-0458/#metadata-scalability and https://github.com/theupdateframework/specification/blob/master/tuf-spec.md
31
number of targets10,000,000
Estimates for if a single party signs all images on a registry
estimates without succinct hash bins10,000,00010,000,000
32
number of bins (bins-a)1048576we control this, the number of bins that bins-a delegates tosizepercent of image size4096262144
33
single bin metadata downloaded4,4980.0022%
34
targets per bin10bins-a metadata downloaded1,0560.0005%244239
35
size of bin metadata3,858includes the targets size for each target, signaturetotal targets metadata overhead5,5540.0028%910,99414,675
36
size of bins-a metadata416includes a signature and the keyid + path for all bins1,179,776416
37
merkle tree height20
38
overhead for single bin file4,4982,090,77015,091
39
overhead for bin-a1,056snapshot155648155648
40
snapshot+targets overhead
2,246,418170,739
41
No snapshot proposal (Lasker)TUF Design Option 2 with succinct hash bins fresh clientTUF Design Option 2 with succinct hash bins all prior snapshot (downloading 15 shapshots)
42
Estimated per-client d/l
43
Image only200,000,000200,000,000200,000,000
44
Existing OCI metadata3,5830.00179%3,5830.00179%3,5830.00179%This last option allows the client to verify that the version number has not been decreased since the last time a snapshot was downloaded. This can be done by clients and auditors.
45
Added signatures / metadata1990.00010%5,5540.00278%83,3100.04166%
46
total200,003,7820.00189%200,009,1370.00457%200,086,8930.04345%
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100