tss 0.1.0
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +7 -0
- checksums.yaml.gz.sig +0 -0
- data.tar.gz.sig +4 -0
- data/.codeclimate.yml +30 -0
- data/.gitignore +9 -0
- data/.rubocop.yml +1156 -0
- data/.ruby-version +1 -0
- data/.travis.yml +6 -0
- data/CODE_OF_CONDUCT.md +49 -0
- data/Gemfile +4 -0
- data/LICENSE.txt +21 -0
- data/README.md +590 -0
- data/Rakefile +23 -0
- data/bin/console +14 -0
- data/bin/setup +8 -0
- data/bin/tss +7 -0
- data/certs/gem-public_cert_grempe.pem +21 -0
- data/docs/tss-ietf-draft/draft-mcgrew-tss-03.html +1417 -0
- data/docs/tss-ietf-draft/draft-mcgrew-tss-03.txt +1456 -0
- data/lib/tss.rb +14 -0
- data/lib/tss/blank.rb +142 -0
- data/lib/tss/cli.rb +107 -0
- data/lib/tss/combiner.rb +296 -0
- data/lib/tss/errors.rb +4 -0
- data/lib/tss/hasher.rb +55 -0
- data/lib/tss/splitter.rb +190 -0
- data/lib/tss/tss.rb +15 -0
- data/lib/tss/types.rb +4 -0
- data/lib/tss/util.rb +266 -0
- data/lib/tss/version.rb +3 -0
- data/tss.gemspec +58 -0
- metadata +223 -0
- metadata.gz.sig +0 -0
data/Rakefile
ADDED
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
require 'bundler/gem_tasks'
|
|
2
|
+
require 'rake/testtask'
|
|
3
|
+
|
|
4
|
+
Rake::TestTask.new(:test) do |t|
|
|
5
|
+
t.libs << 'test'
|
|
6
|
+
t.libs << 'lib'
|
|
7
|
+
t.test_files = FileList['test/**/*_test.rb']
|
|
8
|
+
end
|
|
9
|
+
|
|
10
|
+
Rake::TestTask.new(:bench) do |t|
|
|
11
|
+
t.libs << 'test'
|
|
12
|
+
t.libs << 'lib'
|
|
13
|
+
t.test_files = FileList['test/**/*_benchmark.rb']
|
|
14
|
+
end
|
|
15
|
+
|
|
16
|
+
# a long running brute force burn-in test
|
|
17
|
+
Rake::TestTask.new(:burn) do |t|
|
|
18
|
+
t.libs << 'test'
|
|
19
|
+
t.libs << 'lib'
|
|
20
|
+
t.test_files = FileList['test/**/*_brute.rb']
|
|
21
|
+
end
|
|
22
|
+
|
|
23
|
+
task default: :test
|
data/bin/console
ADDED
|
@@ -0,0 +1,14 @@
|
|
|
1
|
+
#!/usr/bin/env ruby
|
|
2
|
+
|
|
3
|
+
require 'bundler/setup'
|
|
4
|
+
require 'tss'
|
|
5
|
+
|
|
6
|
+
# You can add fixtures and/or initialization code here to make experimenting
|
|
7
|
+
# with your gem easier. You can also use a different console, if you like.
|
|
8
|
+
|
|
9
|
+
# (If you use this, don't forget to add pry to your Gemfile!)
|
|
10
|
+
require 'pry'
|
|
11
|
+
Pry.start
|
|
12
|
+
|
|
13
|
+
require 'irb'
|
|
14
|
+
IRB.start
|
data/bin/setup
ADDED
data/bin/tss
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
-----BEGIN CERTIFICATE-----
|
|
2
|
+
MIIDYDCCAkigAwIBAgIBATANBgkqhkiG9w0BAQUFADA7MQ4wDAYDVQQDDAVnbGVu
|
|
3
|
+
bjEVMBMGCgmSJomT8ixkARkWBXJlbXBlMRIwEAYKCZImiZPyLGQBGRYCdXMwHhcN
|
|
4
|
+
MTYwNDExMDI0NTU0WhcNMTcwNDExMDI0NTU0WjA7MQ4wDAYDVQQDDAVnbGVubjEV
|
|
5
|
+
MBMGCgmSJomT8ixkARkWBXJlbXBlMRIwEAYKCZImiZPyLGQBGRYCdXMwggEiMA0G
|
|
6
|
+
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZqTH5Jf+D/W2B4BIiL49CpHa86rK/
|
|
7
|
+
oT+v3xZwuEE92lJea+ygn3IAsidVTW47AKE6Lt3UqUkGQGKxsqH/Dhir08BqjLlD
|
|
8
|
+
gBUozGZpM3B6uWZnD6QXLbOmZeGVDnwB/QDfzaawN1i3smlYxYT+KNLjl80aN3we
|
|
9
|
+
/cHAWG7JG47AF/S91mYcg1WgZnDgZt9+RyVR1AsfYbM+SidOSoXEOHPCbuUxLKJb
|
|
10
|
+
gj5ieCFhm5GNWEugvgiX/ruas+VHV0fF3fzjYlU2fZPTuQyB4UD5FWX4UqdsBf3w
|
|
11
|
+
jB94TDBsJ3FVGPbggEhLGKd8pbQmBIOqXolGaqhs7dnuf5imu5mAXHC1AgMBAAGj
|
|
12
|
+
bzBtMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdDgQWBBRfxEyosUbKjfFa
|
|
13
|
+
j+gae2CcT3aFCTAZBgNVHREEEjAQgQ5nbGVubkByZW1wZS51czAZBgNVHRIEEjAQ
|
|
14
|
+
gQ5nbGVubkByZW1wZS51czANBgkqhkiG9w0BAQUFAAOCAQEAzgK20+MNOknR9Kx6
|
|
15
|
+
RisI3DsioCADjGldxY+INrwoTfPDVmNm4GdTYC+V+/BvxJw1RqHjEbuXSg0iibQC
|
|
16
|
+
4vN+th0Km7dnas/td1i+EKfGencfyQyecIaG9l3kbCkCWnldRtZ+BS5EfP2ML2u8
|
|
17
|
+
fyCtze/Piovu8IwXL1W5kGZMnvzLmWxdqI3VPUou40n8F+EiMMLgd53kpzjtNOau
|
|
18
|
+
4W+mqVGOwlEGVSgI5+0SIsD8pvc62PlPWTv0kn1bcufKKCZmoVmpfbe3j4JpBInq
|
|
19
|
+
zieXiXZSAojfFx9g91fKdIrlPbInHU/BaCxXSLBwvOM0drE+c2ue9X8gB55XAhzX
|
|
20
|
+
37oBiw==
|
|
21
|
+
-----END CERTIFICATE-----
|
|
@@ -0,0 +1,1417 @@
|
|
|
1
|
+
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
|
2
|
+
<html lang="en"><head><title>Threshold Secret Sharing</title>
|
|
3
|
+
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
|
|
4
|
+
<meta name="description" content="Threshold Secret Sharing">
|
|
5
|
+
<meta name="keywords" content="Cryptography">
|
|
6
|
+
<meta name="generator" content="xml2rfc v1.35 (http://xml.resource.org/)">
|
|
7
|
+
<meta name="viewport" content="width=600;" />
|
|
8
|
+
<style type='text/css'><!--
|
|
9
|
+
body {
|
|
10
|
+
font-family: verdana, charcoal, helvetica, arial, sans-serif;
|
|
11
|
+
font-size: 85%;
|
|
12
|
+
max-width: 40em;
|
|
13
|
+
color: #000; background-color: #FFF;
|
|
14
|
+
margin: 2em;
|
|
15
|
+
}
|
|
16
|
+
h1, h2, h3, h4, h5, h6 {
|
|
17
|
+
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
|
|
18
|
+
font-weight: bold; font-style: normal;
|
|
19
|
+
}
|
|
20
|
+
h1 { color: #900; background-color: transparent; text-align: right; }
|
|
21
|
+
h3 { color: #333; background-color: transparent; }
|
|
22
|
+
|
|
23
|
+
td.RFCbug {
|
|
24
|
+
font-size: x-small; text-decoration: none;
|
|
25
|
+
width: 30px; height: 30px; padding-top: 2px;
|
|
26
|
+
text-align: justify; vertical-align: middle;
|
|
27
|
+
background-color: #000;
|
|
28
|
+
}
|
|
29
|
+
td.RFCbug span.RFC {
|
|
30
|
+
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
|
|
31
|
+
font-weight: bold; color: #666;
|
|
32
|
+
}
|
|
33
|
+
td.RFCbug span.hotText {
|
|
34
|
+
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
|
|
35
|
+
font-weight: normal; text-align: center; color: #FFF;
|
|
36
|
+
}
|
|
37
|
+
|
|
38
|
+
table.TOCbug { width: 30px; height: 15px; }
|
|
39
|
+
td.TOCbug {
|
|
40
|
+
text-align: center; width: 30px; height: 15px;
|
|
41
|
+
color: #FFF; background-color: #900;
|
|
42
|
+
}
|
|
43
|
+
td.TOCbug a {
|
|
44
|
+
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
|
|
45
|
+
font-weight: bold; font-size: x-small; text-decoration: none;
|
|
46
|
+
color: #FFF; background-color: transparent;
|
|
47
|
+
}
|
|
48
|
+
|
|
49
|
+
td.header {
|
|
50
|
+
font-family: arial, helvetica, sans-serif; font-size: x-small;
|
|
51
|
+
vertical-align: top; width: 33%;
|
|
52
|
+
color: #FFF; background-color: #666;
|
|
53
|
+
}
|
|
54
|
+
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
|
|
55
|
+
td.author-text { font-size: x-small; }
|
|
56
|
+
|
|
57
|
+
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
|
|
58
|
+
a.info {
|
|
59
|
+
/* This is the key. */
|
|
60
|
+
position: relative;
|
|
61
|
+
z-index: 24;
|
|
62
|
+
text-decoration: none;
|
|
63
|
+
}
|
|
64
|
+
a.info:hover {
|
|
65
|
+
z-index: 25;
|
|
66
|
+
color: #FFF; background-color: #900;
|
|
67
|
+
}
|
|
68
|
+
a.info span { display: none; }
|
|
69
|
+
a.info:hover span.info {
|
|
70
|
+
/* The span will display just on :hover state. */
|
|
71
|
+
display: block;
|
|
72
|
+
position: absolute;
|
|
73
|
+
font-size: smaller;
|
|
74
|
+
top: 2em; left: -5em; width: 15em;
|
|
75
|
+
padding: 2px; border: 1px solid #333;
|
|
76
|
+
color: #900; background-color: #EEE;
|
|
77
|
+
text-align: left;
|
|
78
|
+
}
|
|
79
|
+
|
|
80
|
+
a { font-weight: bold; }
|
|
81
|
+
a:link { color: #900; background-color: transparent; }
|
|
82
|
+
a:visited { color: #633; background-color: transparent; }
|
|
83
|
+
a:active { color: #633; background-color: transparent; }
|
|
84
|
+
|
|
85
|
+
p { margin-left: 2em; margin-right: 2em; }
|
|
86
|
+
p.copyright { font-size: x-small; }
|
|
87
|
+
p.toc { font-size: 85%;
|
|
88
|
+
max-width: 40em;
|
|
89
|
+
font-weight: bold; margin-left: 3em; }
|
|
90
|
+
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
|
|
91
|
+
td.toc { font-size: 85%;
|
|
92
|
+
max-width: 40em;
|
|
93
|
+
font-weight: bold; vertical-align: text-top; }
|
|
94
|
+
|
|
95
|
+
ol.text { margin-left: 2em; margin-right: 2em; }
|
|
96
|
+
ul.text { margin-left: 2em; margin-right: 2em; }
|
|
97
|
+
li { margin-left: 3em; }
|
|
98
|
+
|
|
99
|
+
/* RFC-2629 <spanx>s and <artwork>s. */
|
|
100
|
+
em { font-style: italic; }
|
|
101
|
+
strong { font-weight: bold; }
|
|
102
|
+
dfn { font-weight: bold; font-style: normal; }
|
|
103
|
+
cite { font-weight: normal; font-style: normal; }
|
|
104
|
+
tt { color: #036; }
|
|
105
|
+
tt, pre, pre dfn, pre em, pre cite, pre span {
|
|
106
|
+
font-family: "Courier New", Courier, monospace; font-size: small;
|
|
107
|
+
}
|
|
108
|
+
pre {
|
|
109
|
+
text-align: left; padding: 4px;
|
|
110
|
+
color: #000; background-color: #CCC;
|
|
111
|
+
}
|
|
112
|
+
pre dfn { color: #900; }
|
|
113
|
+
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
|
|
114
|
+
pre .key { color: #33C; font-weight: bold; }
|
|
115
|
+
pre .id { color: #900; }
|
|
116
|
+
pre .str { color: #000; background-color: #CFF; }
|
|
117
|
+
pre .val { color: #066; }
|
|
118
|
+
pre .rep { color: #909; }
|
|
119
|
+
pre .oth { color: #000; background-color: #FCF; }
|
|
120
|
+
pre .err { background-color: #FCC; }
|
|
121
|
+
|
|
122
|
+
/* RFC-2629 <texttable>s. */
|
|
123
|
+
table.all, table.full, table.headers, table.none {
|
|
124
|
+
font-size: 85%;
|
|
125
|
+
max-width: 40em;
|
|
126
|
+
text-align: center; border-width: 2px;
|
|
127
|
+
vertical-align: top; border-collapse: collapse;
|
|
128
|
+
}
|
|
129
|
+
table.all, table.full { border-style: solid; border-color: black; }
|
|
130
|
+
table.headers, table.none { border-style: none; }
|
|
131
|
+
th {
|
|
132
|
+
font-weight: bold; border-color: black;
|
|
133
|
+
border-width: 2px 2px 3px 2px;
|
|
134
|
+
}
|
|
135
|
+
table.all th, table.full th { border-style: solid; }
|
|
136
|
+
table.headers th { border-style: none none solid none; }
|
|
137
|
+
table.none th { border-style: none; }
|
|
138
|
+
table.all td {
|
|
139
|
+
border-style: solid; border-color: #333;
|
|
140
|
+
border-width: 1px 2px;
|
|
141
|
+
}
|
|
142
|
+
table.full td, table.headers td, table.none td { border-style: none; }
|
|
143
|
+
|
|
144
|
+
hr { height: 1px; }
|
|
145
|
+
hr.insert {
|
|
146
|
+
width: 80%; border-style: none; border-width: 0;
|
|
147
|
+
color: #CCC; background-color: #CCC;
|
|
148
|
+
}
|
|
149
|
+
--></style>
|
|
150
|
+
</head>
|
|
151
|
+
<body>
|
|
152
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
153
|
+
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
|
|
154
|
+
<tr><td class="header">Network Working Group</td><td class="header">D. McGrew</td></tr>
|
|
155
|
+
<tr><td class="header">Internet-Draft</td><td class="header">Cisco Systems, Inc.</td></tr>
|
|
156
|
+
<tr><td class="header">Intended status: Informational</td><td class="header">P. Patnala</td></tr>
|
|
157
|
+
<tr><td class="header">Expires: September 4, 2010</td><td class="header">Consultant</td></tr>
|
|
158
|
+
<tr><td class="header"> </td><td class="header">A. Hoenes</td></tr>
|
|
159
|
+
<tr><td class="header"> </td><td class="header">TR-Sys</td></tr>
|
|
160
|
+
<tr><td class="header"> </td><td class="header">March 03, 2010</td></tr>
|
|
161
|
+
</table></td></tr></table>
|
|
162
|
+
<h1><br />Threshold Secret Sharing<br />draft-mcgrew-tss-03.txt</h1>
|
|
163
|
+
|
|
164
|
+
<h3>Abstract</h3>
|
|
165
|
+
|
|
166
|
+
<p>
|
|
167
|
+
Threshold Secret Sharing (TSS) provides a way to generate N
|
|
168
|
+
shares from a value, so that any M of those shares can be used
|
|
169
|
+
to reconstruct the original value, but any M-1 shares provide
|
|
170
|
+
no information about that value. This method can provide
|
|
171
|
+
shared access control on key material and other secrets that
|
|
172
|
+
must be strongly protected.
|
|
173
|
+
|
|
174
|
+
</p>
|
|
175
|
+
<p> This note defines a threshold secret sharing method based on
|
|
176
|
+
polynomial interpolation in GF(256) and a format for the
|
|
177
|
+
storage and transmission of shares. It also provides usage
|
|
178
|
+
guidance, describes how to test an implementation, and
|
|
179
|
+
supplies test cases.
|
|
180
|
+
|
|
181
|
+
</p>
|
|
182
|
+
<h3>Status of this Memo</h3>
|
|
183
|
+
<p>
|
|
184
|
+
This Internet-Draft is submitted to IETF in full
|
|
185
|
+
conformance with the provisions of BCP 78 and BCP 79.</p>
|
|
186
|
+
<p>
|
|
187
|
+
Internet-Drafts are working documents of the Internet Engineering
|
|
188
|
+
Task Force (IETF), its areas, and its working groups.
|
|
189
|
+
Note that other groups may also distribute working documents as
|
|
190
|
+
Internet-Drafts.</p>
|
|
191
|
+
<p>
|
|
192
|
+
Internet-Drafts are draft documents valid for a maximum of six months
|
|
193
|
+
and may be updated, replaced, or obsoleted by other documents at any time.
|
|
194
|
+
It is inappropriate to use Internet-Drafts as reference material or to cite
|
|
195
|
+
them other than as “work in progress.”</p>
|
|
196
|
+
<p>
|
|
197
|
+
The list of current Internet-Drafts can be accessed at
|
|
198
|
+
<a href='http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/ietf/1id-abstracts.txt</a>.</p>
|
|
199
|
+
<p>
|
|
200
|
+
The list of Internet-Draft Shadow Directories can be accessed at
|
|
201
|
+
<a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p>
|
|
202
|
+
<p>
|
|
203
|
+
This Internet-Draft will expire on September 4, 2010.</p>
|
|
204
|
+
|
|
205
|
+
<h3>Copyright Notice</h3>
|
|
206
|
+
<p>
|
|
207
|
+
Copyright (c) 2010 IETF Trust and the persons identified as the
|
|
208
|
+
document authors. All rights reserved.</p>
|
|
209
|
+
<p>
|
|
210
|
+
This document is subject to BCP 78 and the IETF Trust's Legal
|
|
211
|
+
Provisions Relating to IETF Documents
|
|
212
|
+
(http://trustee.ietf.org/license-info) in effect on the date of
|
|
213
|
+
publication of this document. Please review these documents
|
|
214
|
+
carefully, as they describe your rights and restrictions with respect
|
|
215
|
+
to this document. Code Components extracted from this document must
|
|
216
|
+
include Simplified BSD License text as described in Section 4.e of
|
|
217
|
+
the Trust Legal Provisions and are provided without warranty as
|
|
218
|
+
described in the BSD License.</p>
|
|
219
|
+
<a name="toc"></a><br /><hr />
|
|
220
|
+
<h3>Table of Contents</h3>
|
|
221
|
+
<p class="toc">
|
|
222
|
+
<a href="#anchor1">1.</a>
|
|
223
|
+
Introduction<br />
|
|
224
|
+
<a href="#anchor2">1.1.</a>
|
|
225
|
+
Conventions Used In This Document<br />
|
|
226
|
+
<a href="#anchor3">2.</a>
|
|
227
|
+
Operations<br />
|
|
228
|
+
<a href="#anchor4">2.1.</a>
|
|
229
|
+
Create Shares<br />
|
|
230
|
+
<a href="#anchor5">2.2.</a>
|
|
231
|
+
Reconstruct Secret<br />
|
|
232
|
+
<a href="#anchor6">3.</a>
|
|
233
|
+
Polynomial Interpolation over GF(256)<br />
|
|
234
|
+
<a href="#anchor7">3.1.</a>
|
|
235
|
+
Field Representation<br />
|
|
236
|
+
<a href="#anchor8">3.2.</a>
|
|
237
|
+
Share Generation<br />
|
|
238
|
+
<a href="#anchor9">3.3.</a>
|
|
239
|
+
Secret Reconstruction<br />
|
|
240
|
+
<a href="#anchor10">4.</a>
|
|
241
|
+
Robust Threshold Secret Sharing<br />
|
|
242
|
+
<a href="#anchor11">4.1.</a>
|
|
243
|
+
RTSS Data Format<br />
|
|
244
|
+
<a href="#anchor12">5.</a>
|
|
245
|
+
Error Correction and Data Recovery<br />
|
|
246
|
+
<a href="#anchor13">5.1.</a>
|
|
247
|
+
Data Recovery<br />
|
|
248
|
+
<a href="#anchor14">5.2.</a>
|
|
249
|
+
Error Correction<br />
|
|
250
|
+
<a href="#anchor15">5.3.</a>
|
|
251
|
+
A Repetition Code<br />
|
|
252
|
+
<a href="#anchor16">6.</a>
|
|
253
|
+
Format<br />
|
|
254
|
+
<a href="#anchor17">7.</a>
|
|
255
|
+
Design and Rationale<br />
|
|
256
|
+
<a href="#testing">8.</a>
|
|
257
|
+
Testing<br />
|
|
258
|
+
<a href="#CASES">9.</a>
|
|
259
|
+
Test Cases<br />
|
|
260
|
+
<a href="#anchor18">10.</a>
|
|
261
|
+
Security Considerations<br />
|
|
262
|
+
<a href="#anchor19">11.</a>
|
|
263
|
+
IANA Considerations<br />
|
|
264
|
+
<a href="#anchor20">12.</a>
|
|
265
|
+
Acknowledgements<br />
|
|
266
|
+
<a href="#rfc.references1">13.</a>
|
|
267
|
+
References<br />
|
|
268
|
+
<a href="#rfc.references1">13.1.</a>
|
|
269
|
+
Normative References<br />
|
|
270
|
+
<a href="#rfc.references2">13.2.</a>
|
|
271
|
+
Informative References<br />
|
|
272
|
+
<a href="#anchor23">Appendix A.</a>
|
|
273
|
+
Mathematical Background<br />
|
|
274
|
+
<a href="#rfc.authors">§</a>
|
|
275
|
+
Authors' Addresses<br />
|
|
276
|
+
</p>
|
|
277
|
+
<br clear="all" />
|
|
278
|
+
|
|
279
|
+
<a name="anchor1"></a><br /><hr />
|
|
280
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
281
|
+
<a name="rfc.section.1"></a><h3>1.
|
|
282
|
+
Introduction</h3>
|
|
283
|
+
|
|
284
|
+
<p>
|
|
285
|
+
Threshold secret sharing (TSS) provides a way to generate N shares
|
|
286
|
+
from a value, so that any M of those shares can be used to
|
|
287
|
+
reconstruct the original value, but any M-1 shares provide no
|
|
288
|
+
information about that value. This method does not rely on any
|
|
289
|
+
assumptions about the complexity of solving a particular
|
|
290
|
+
computational problem (such as factoring); it is
|
|
291
|
+
information-theoretically secure. Each share is slightly longer than
|
|
292
|
+
the original secret.
|
|
293
|
+
|
|
294
|
+
</p>
|
|
295
|
+
<p>
|
|
296
|
+
In the context of secret sharing, the word "share" means a part of
|
|
297
|
+
something, and "sharing" means the act of breaking up into parts.
|
|
298
|
+
Readers may be confused if they think of "sharing" as meaning "giving
|
|
299
|
+
to or possessing with others".
|
|
300
|
+
|
|
301
|
+
</p>
|
|
302
|
+
<p>
|
|
303
|
+
TSS is especially useful whenever there is a need to ensure the
|
|
304
|
+
availability of a secret, yet there is a simultaneous need to reduce
|
|
305
|
+
the risk of compromise of the secret. By dividing the secret into
|
|
306
|
+
multiple shares, and distributing each share to a different trusted
|
|
307
|
+
entity, TSS reduces that risk while providing for the availability of
|
|
308
|
+
the secret. At the time that the secret is divided into shares, the
|
|
309
|
+
threshold defining a number of shares that are needed to reconstruct
|
|
310
|
+
the secret is set.
|
|
311
|
+
|
|
312
|
+
</p>
|
|
313
|
+
<p>
|
|
314
|
+
TSS can be applied to any secret key, such as one used
|
|
315
|
+
to encrypt data at rest, or to any private key, such as the signing
|
|
316
|
+
key used by a certificate authority. It can be used to create
|
|
317
|
+
a "backup" copy of a key, to protect against the loss or corruption
|
|
318
|
+
of an "active" copy of the key. Alternatively, TSS can be applied
|
|
319
|
+
to a key, and then the original key can be deleted, as a means
|
|
320
|
+
of enforcing shared access control on that key.
|
|
321
|
+
|
|
322
|
+
</p>
|
|
323
|
+
<a name="anchor2"></a><br /><hr />
|
|
324
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
325
|
+
<a name="rfc.section.1.1"></a><h3>1.1.
|
|
326
|
+
Conventions Used In This Document</h3>
|
|
327
|
+
|
|
328
|
+
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|
329
|
+
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|
330
|
+
document are to be interpreted as described in <a class='info' href='#RFC2119'>[RFC2119]<span> (</span><span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a>.
|
|
331
|
+
</p>
|
|
332
|
+
<a name="anchor3"></a><br /><hr />
|
|
333
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
334
|
+
<a name="rfc.section.2"></a><h3>2.
|
|
335
|
+
Operations</h3>
|
|
336
|
+
|
|
337
|
+
<p>
|
|
338
|
+
A threshold secret sharing system provides two operations: one that
|
|
339
|
+
creates a set of shares given a secret, and one that reconstructs the
|
|
340
|
+
secret, given a set of shares. This section defines the inputs and
|
|
341
|
+
outputs of these operations. The following sections describe the
|
|
342
|
+
details of TSS based on a polynomial interpolation in GF(256).
|
|
343
|
+
|
|
344
|
+
</p>
|
|
345
|
+
<a name="anchor4"></a><br /><hr />
|
|
346
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
347
|
+
<a name="rfc.section.2.1"></a><h3>2.1.
|
|
348
|
+
Create Shares</h3>
|
|
349
|
+
|
|
350
|
+
<p>
|
|
351
|
+
This operation takes an octet string S, whose length is L octets,
|
|
352
|
+
and a threshold parameter M, and generates a set of N shares, any M
|
|
353
|
+
of which can be used to reconstruct the secret.
|
|
354
|
+
|
|
355
|
+
</p>
|
|
356
|
+
<p>
|
|
357
|
+
The secret S is treated as an unstructured sequence of octets. It
|
|
358
|
+
is not expected to be null-terminated. The number of octets in the
|
|
359
|
+
secret may be anywhere from zero up to 65,534 (that is, two less than 2^16).
|
|
360
|
+
|
|
361
|
+
</p>
|
|
362
|
+
<p>
|
|
363
|
+
The threshold parameter M is the number of shares that will be needed to
|
|
364
|
+
reconstruct the secret. This value may be any number between one
|
|
365
|
+
and 255, inclusive.
|
|
366
|
+
|
|
367
|
+
</p>
|
|
368
|
+
<p>
|
|
369
|
+
The number of shares N that will be generated MUST be
|
|
370
|
+
between the threshold value M and 255, inclusive. The upper limit
|
|
371
|
+
is particular to the TSS algorithm specified in this document.
|
|
372
|
+
|
|
373
|
+
</p>
|
|
374
|
+
<p>
|
|
375
|
+
If the operation can not be completed successfully, then an error
|
|
376
|
+
code should be returned.
|
|
377
|
+
|
|
378
|
+
</p>
|
|
379
|
+
<a name="anchor5"></a><br /><hr />
|
|
380
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
381
|
+
<a name="rfc.section.2.2"></a><h3>2.2.
|
|
382
|
+
Reconstruct Secret</h3>
|
|
383
|
+
|
|
384
|
+
<p>
|
|
385
|
+
The reconstruct operation reconstructs the secret from a set of shares.
|
|
386
|
+
|
|
387
|
+
</p>
|
|
388
|
+
<p>
|
|
389
|
+
The number of shares N must be provided as a parameter.
|
|
390
|
+
|
|
391
|
+
</p>
|
|
392
|
+
<p>
|
|
393
|
+
The only other parameter is the list of shares themselves.
|
|
394
|
+
The shares should be treated as unstructured octet strings.
|
|
395
|
+
|
|
396
|
+
</p>
|
|
397
|
+
<p>
|
|
398
|
+
If the operation could be completed successfully, then the secret
|
|
399
|
+
value will be returned.
|
|
400
|
+
|
|
401
|
+
</p>
|
|
402
|
+
<p>
|
|
403
|
+
If the operation can not be completed successfully, then an error
|
|
404
|
+
code should be returned.
|
|
405
|
+
|
|
406
|
+
</p>
|
|
407
|
+
<a name="anchor6"></a><br /><hr />
|
|
408
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
409
|
+
<a name="rfc.section.3"></a><h3>3.
|
|
410
|
+
Polynomial Interpolation over GF(256)</h3>
|
|
411
|
+
|
|
412
|
+
<p>
|
|
413
|
+
A finite field is a set of elements with associated addition,
|
|
414
|
+
multiplication, subtraction, and division operations. Each of those
|
|
415
|
+
operations acts on elements in the field, and returns an element in
|
|
416
|
+
the field. This specification uses the field GF(256), and each
|
|
417
|
+
element is represented as a single octet. There are many possible
|
|
418
|
+
ways to represent a finite field; below we define the field arithmetic
|
|
419
|
+
operations as having inputs and outputs that are octets. This fixes a
|
|
420
|
+
particular representation, without explicitly defining it, and it
|
|
421
|
+
avoids the issue of the bit-representation of octets. In this
|
|
422
|
+
representation, the zero field element is the zero octet, and
|
|
423
|
+
the unity field element is 0x01 (hexadecimal).
|
|
424
|
+
|
|
425
|
+
</p>
|
|
426
|
+
<a name="anchor7"></a><br /><hr />
|
|
427
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
428
|
+
<a name="rfc.section.3.1"></a><h3>3.1.
|
|
429
|
+
Field Representation</h3>
|
|
430
|
+
|
|
431
|
+
<p>
|
|
432
|
+
Each element of the field GF(256) is represented as an octet. In the
|
|
433
|
+
following, each octet is represented as a hexadecimal number with a
|
|
434
|
+
leading "0x", as in ANSI/ISO C. The representation of the finite
|
|
435
|
+
field that we use is defined in terms of the addition, subtraction,
|
|
436
|
+
multiplication, and division operations. We define these operations
|
|
437
|
+
as taking two octets as input and returning a single octet as output.
|
|
438
|
+
In order to distinguish GF(256) arithmetic from integer arithmetic,
|
|
439
|
+
we denote addition and multiplication in GF(256) as
|
|
440
|
+
(+) and (*), respectively. We also refer to the summation and
|
|
441
|
+
product operations in GF(256) as GF_SUM and GF_PRODUCT, respectively.
|
|
442
|
+
|
|
443
|
+
</p>
|
|
444
|
+
<p>
|
|
445
|
+
The multiplication in GF(256) and its inverse operation (division)
|
|
446
|
+
are defined in terms of two tables, the EXP table
|
|
447
|
+
(<a class='info' href='#exp'>Figure 1<span> (</span><span class='info'>The EXP table. The elements are to be read from top to bottom and left to right. For example, EXP[0] is 0x01, EXP[8] is 0x1a, and so on. Note that the EXP[255] entry is present only as a placeholder, and is not actually used in any computation.</span><span>)</span></a>) and the LOG table (<a class='info' href='#log'>Figure 2<span> (</span><span class='info'>The LOG table. The elements are to be read from top to bottom and left to right. For example, LOG[1] is 0, LOG[8] is 75, and so on. Note that the LOG[0] entry is present only as a placeholder, and is not actually used in any computation.</span><span>)</span></a>), which
|
|
448
|
+
define the exponential function and the logarithmic function,
|
|
449
|
+
respectively. The ith elements of these tables are denoted as EXP[i]
|
|
450
|
+
and LOG[i]. LOG takes a non-zero field element as
|
|
451
|
+
input, and returns an integer, and EXP takes an integer and returns a
|
|
452
|
+
field element.
|
|
453
|
+
|
|
454
|
+
</p>
|
|
455
|
+
<p>
|
|
456
|
+
The addition operation returns the bitwise exclusive-or of its
|
|
457
|
+
operands. The subtraction operation is identical, because the field
|
|
458
|
+
has characteristic two.
|
|
459
|
+
|
|
460
|
+
</p>
|
|
461
|
+
<p>
|
|
462
|
+
The multiplication operation takes two elements X and Y as input and
|
|
463
|
+
proceeds as follows. If either X or Y is equal to 0x00, then the
|
|
464
|
+
operation returns 0x00. Otherwise, the value EXP[ (LOG[X] + LOG[Y]) modulo
|
|
465
|
+
255] is returned.
|
|
466
|
+
|
|
467
|
+
</p>
|
|
468
|
+
<p>
|
|
469
|
+
The division operation takes a dividend X and a divisor Y as input and
|
|
470
|
+
computes X divided by Y as follows. If X is equal to 0x00, then the
|
|
471
|
+
operation returns 0x00. If Y is equal to 0x00, then the input is invalid, and
|
|
472
|
+
an error condition occurs. Otherwise, the value EXP[ (LOG[X] - LOG[Y]) modulo
|
|
473
|
+
255] is returned.
|
|
474
|
+
|
|
475
|
+
</p>
|
|
476
|
+
<p>
|
|
477
|
+
The operation of raising a field element X to a power i, where i is a
|
|
478
|
+
positive integer, is denoted as X^i, and it consists of multiplying X
|
|
479
|
+
by itself i times.
|
|
480
|
+
|
|
481
|
+
</p><br /><hr class="insert" />
|
|
482
|
+
<a name="exp"></a>
|
|
483
|
+
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
|
|
484
|
+
0x01, 0x03, 0x05, 0x0f, 0x11, 0x33, 0x55, 0xff,
|
|
485
|
+
0x1a, 0x2e, 0x72, 0x96, 0xa1, 0xf8, 0x13, 0x35,
|
|
486
|
+
0x5f, 0xe1, 0x38, 0x48, 0xd8, 0x73, 0x95, 0xa4,
|
|
487
|
+
0xf7, 0x02, 0x06, 0x0a, 0x1e, 0x22, 0x66, 0xaa,
|
|
488
|
+
0xe5, 0x34, 0x5c, 0xe4, 0x37, 0x59, 0xeb, 0x26,
|
|
489
|
+
0x6a, 0xbe, 0xd9, 0x70, 0x90, 0xab, 0xe6, 0x31,
|
|
490
|
+
0x53, 0xf5, 0x04, 0x0c, 0x14, 0x3c, 0x44, 0xcc,
|
|
491
|
+
0x4f, 0xd1, 0x68, 0xb8, 0xd3, 0x6e, 0xb2, 0xcd,
|
|
492
|
+
0x4c, 0xd4, 0x67, 0xa9, 0xe0, 0x3b, 0x4d, 0xd7,
|
|
493
|
+
0x62, 0xa6, 0xf1, 0x08, 0x18, 0x28, 0x78, 0x88,
|
|
494
|
+
0x83, 0x9e, 0xb9, 0xd0, 0x6b, 0xbd, 0xdc, 0x7f,
|
|
495
|
+
0x81, 0x98, 0xb3, 0xce, 0x49, 0xdb, 0x76, 0x9a,
|
|
496
|
+
0xb5, 0xc4, 0x57, 0xf9, 0x10, 0x30, 0x50, 0xf0,
|
|
497
|
+
0x0b, 0x1d, 0x27, 0x69, 0xbb, 0xd6, 0x61, 0xa3,
|
|
498
|
+
0xfe, 0x19, 0x2b, 0x7d, 0x87, 0x92, 0xad, 0xec,
|
|
499
|
+
0x2f, 0x71, 0x93, 0xae, 0xe9, 0x20, 0x60, 0xa0,
|
|
500
|
+
0xfb, 0x16, 0x3a, 0x4e, 0xd2, 0x6d, 0xb7, 0xc2,
|
|
501
|
+
0x5d, 0xe7, 0x32, 0x56, 0xfa, 0x15, 0x3f, 0x41,
|
|
502
|
+
0xc3, 0x5e, 0xe2, 0x3d, 0x47, 0xc9, 0x40, 0xc0,
|
|
503
|
+
0x5b, 0xed, 0x2c, 0x74, 0x9c, 0xbf, 0xda, 0x75,
|
|
504
|
+
0x9f, 0xba, 0xd5, 0x64, 0xac, 0xef, 0x2a, 0x7e,
|
|
505
|
+
0x82, 0x9d, 0xbc, 0xdf, 0x7a, 0x8e, 0x89, 0x80,
|
|
506
|
+
0x9b, 0xb6, 0xc1, 0x58, 0xe8, 0x23, 0x65, 0xaf,
|
|
507
|
+
0xea, 0x25, 0x6f, 0xb1, 0xc8, 0x43, 0xc5, 0x54,
|
|
508
|
+
0xfc, 0x1f, 0x21, 0x63, 0xa5, 0xf4, 0x07, 0x09,
|
|
509
|
+
0x1b, 0x2d, 0x77, 0x99, 0xb0, 0xcb, 0x46, 0xca,
|
|
510
|
+
0x45, 0xcf, 0x4a, 0xde, 0x79, 0x8b, 0x86, 0x91,
|
|
511
|
+
0xa8, 0xe3, 0x3e, 0x42, 0xc6, 0x51, 0xf3, 0x0e,
|
|
512
|
+
0x12, 0x36, 0x5a, 0xee, 0x29, 0x7b, 0x8d, 0x8c,
|
|
513
|
+
0x8f, 0x8a, 0x85, 0x94, 0xa7, 0xf2, 0x0d, 0x17,
|
|
514
|
+
0x39, 0x4b, 0xdd, 0x7c, 0x84, 0x97, 0xa2, 0xfd,
|
|
515
|
+
0x1c, 0x24, 0x6c, 0xb4, 0xc7, 0x52, 0xf6, 0x00
|
|
516
|
+
</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 1: The EXP table. The elements are to be read from top to bottom and left to right. For example, EXP[0] is 0x01, EXP[8] is 0x1a, and so on. Note that the EXP[255] entry is present only as a placeholder, and is not actually used in any computation. </b></font><br /></td></tr></table><hr class="insert" />
|
|
517
|
+
<br /><hr class="insert" />
|
|
518
|
+
<a name="log"></a>
|
|
519
|
+
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
|
|
520
|
+
0, 0, 25, 1, 50, 2, 26, 198,
|
|
521
|
+
75, 199, 27, 104, 51, 238, 223, 3,
|
|
522
|
+
100, 4, 224, 14, 52, 141, 129, 239,
|
|
523
|
+
76, 113, 8, 200, 248, 105, 28, 193,
|
|
524
|
+
125, 194, 29, 181, 249, 185, 39, 106,
|
|
525
|
+
77, 228, 166, 114, 154, 201, 9, 120,
|
|
526
|
+
101, 47, 138, 5, 33, 15, 225, 36,
|
|
527
|
+
18, 240, 130, 69, 53, 147, 218, 142,
|
|
528
|
+
150, 143, 219, 189, 54, 208, 206, 148,
|
|
529
|
+
19, 92, 210, 241, 64, 70, 131, 56,
|
|
530
|
+
102, 221, 253, 48, 191, 6, 139, 98,
|
|
531
|
+
179, 37, 226, 152, 34, 136, 145, 16,
|
|
532
|
+
126, 110, 72, 195, 163, 182, 30, 66,
|
|
533
|
+
58, 107, 40, 84, 250, 133, 61, 186,
|
|
534
|
+
43, 121, 10, 21, 155, 159, 94, 202,
|
|
535
|
+
78, 212, 172, 229, 243, 115, 167, 87,
|
|
536
|
+
175, 88, 168, 80, 244, 234, 214, 116,
|
|
537
|
+
79, 174, 233, 213, 231, 230, 173, 232,
|
|
538
|
+
44, 215, 117, 122, 235, 22, 11, 245,
|
|
539
|
+
89, 203, 95, 176, 156, 169, 81, 160,
|
|
540
|
+
127, 12, 246, 111, 23, 196, 73, 236,
|
|
541
|
+
216, 67, 31, 45, 164, 118, 123, 183,
|
|
542
|
+
204, 187, 62, 90, 251, 96, 177, 134,
|
|
543
|
+
59, 82, 161, 108, 170, 85, 41, 157,
|
|
544
|
+
151, 178, 135, 144, 97, 190, 220, 252,
|
|
545
|
+
188, 149, 207, 205, 55, 63, 91, 209,
|
|
546
|
+
83, 57, 132, 60, 65, 162, 109, 71,
|
|
547
|
+
20, 42, 158, 93, 86, 242, 211, 171,
|
|
548
|
+
68, 17, 146, 217, 35, 32, 46, 137,
|
|
549
|
+
180, 124, 184, 38, 119, 153, 227, 165,
|
|
550
|
+
103, 74, 237, 222, 197, 49, 254, 24,
|
|
551
|
+
13, 99, 140, 128, 192, 247, 112, 7
|
|
552
|
+
</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 2: The LOG table.
|
|
553
|
+
The elements are to be read from top to bottom and left to right. For
|
|
554
|
+
example, LOG[1] is 0, LOG[8] is 75, and so on. Note that the LOG[0]
|
|
555
|
+
entry is present only as a placeholder, and is not actually used in
|
|
556
|
+
any computation. </b></font><br /></td></tr></table><hr class="insert" />
|
|
557
|
+
|
|
558
|
+
<a name="anchor8"></a><br /><hr />
|
|
559
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
560
|
+
<a name="rfc.section.3.2"></a><h3>3.2.
|
|
561
|
+
Share Generation</h3>
|
|
562
|
+
|
|
563
|
+
<p>
|
|
564
|
+
We first define how to share a single octet.
|
|
565
|
+
|
|
566
|
+
</p>
|
|
567
|
+
<p>
|
|
568
|
+
The function f takes as input a single octet X that is not equal to
|
|
569
|
+
0x00, and an array A of M octets, and returns a single octet. It is
|
|
570
|
+
defined as
|
|
571
|
+
</p>
|
|
572
|
+
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
|
|
573
|
+
f(X, A) = GF_SUM A[i] (*) X^i
|
|
574
|
+
i=0,M-1
|
|
575
|
+
</pre></div><p>
|
|
576
|
+
|
|
577
|
+
Because the GF_SUM summation takes place over GF(256), each addition uses the
|
|
578
|
+
exclusive-or operation, and not integer addition. Note that the
|
|
579
|
+
successive values of X^i used in the computation of the function f can
|
|
580
|
+
be computed by multiplying a value by X once for each term in the
|
|
581
|
+
summation.
|
|
582
|
+
|
|
583
|
+
</p>
|
|
584
|
+
<p>
|
|
585
|
+
To create N shares from a secret, with a threshold of M, the following
|
|
586
|
+
procedure, or any equivalent method, is used:
|
|
587
|
+
</p>
|
|
588
|
+
<blockquote class="text">
|
|
589
|
+
<p>
|
|
590
|
+
For each share, a distinct Share Index is generated. Each Share Index is an octet
|
|
591
|
+
other than the all-zero octet. All of the Share Indexes used during a share
|
|
592
|
+
generation process MUST be distinct.
|
|
593
|
+
|
|
594
|
+
</p>
|
|
595
|
+
<p>
|
|
596
|
+
Each share is initialized to the Share Index associated with that
|
|
597
|
+
share.
|
|
598
|
+
|
|
599
|
+
</p>
|
|
600
|
+
<p>
|
|
601
|
+
For each octet of the secret, the following steps are performed.
|
|
602
|
+
An array A of M octets is created, in which the array element
|
|
603
|
+
A[0] contains the octet of the secret, and the array elements A[1],
|
|
604
|
+
..., A[M-1] contain octets that are selected independently and
|
|
605
|
+
uniformly at random. For each share, the value of f(X,A) is
|
|
606
|
+
computed, where X is the Share Index of the share, and the resulting
|
|
607
|
+
octet is appended to the share.
|
|
608
|
+
|
|
609
|
+
</p>
|
|
610
|
+
</blockquote><p>
|
|
611
|
+
After the procedure is done, each share contains one more octet
|
|
612
|
+
than does the secret. The share format can be illustrated as
|
|
613
|
+
</p>
|
|
614
|
+
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
|
|
615
|
+
+---------+---------+---------+---------+---------+
|
|
616
|
+
| X | f(X,A) | f(X,B) | f(X,C) | ... |
|
|
617
|
+
+---------+---------+---------+---------+---------+
|
|
618
|
+
</pre></div><p>
|
|
619
|
+
|
|
620
|
+
where X is the Share Index of the share, and A, B, and C are arrays of M
|
|
621
|
+
octets; A[0] is equal to the first octet of the secret, B[0] is equal
|
|
622
|
+
to the second octet of the secret, and so on.
|
|
623
|
+
|
|
624
|
+
</p>
|
|
625
|
+
<a name="anchor9"></a><br /><hr />
|
|
626
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
627
|
+
<a name="rfc.section.3.3"></a><h3>3.3.
|
|
628
|
+
Secret Reconstruction</h3>
|
|
629
|
+
|
|
630
|
+
<p>
|
|
631
|
+
We define the function L_i (for i from 0 to M-1, inclusive) that takes
|
|
632
|
+
as input an array U of M pairwise distinct octets, and is defined as
|
|
633
|
+
</p>
|
|
634
|
+
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
|
|
635
|
+
U[j]
|
|
636
|
+
L_i(U) = GF_PRODUCT -------------
|
|
637
|
+
j=0,M-1, j!=i U[j] (+) U[i]
|
|
638
|
+
</pre></div><p>
|
|
639
|
+
|
|
640
|
+
Here the product runs over all of the values of j from 0 to M-1,
|
|
641
|
+
excluding the value i. (This function is equal to ith Lagrange
|
|
642
|
+
function, evaluated at zero.) Note that the denominator in the above
|
|
643
|
+
expression is never equal to zero because U[i] is not equal to U[j]
|
|
644
|
+
whenever i is not equal to j.
|
|
645
|
+
|
|
646
|
+
</p>
|
|
647
|
+
<p>
|
|
648
|
+
We denote the interpolation function as I. This function takes as
|
|
649
|
+
input two arrays U and V, each consisting of M
|
|
650
|
+
octets, and returns a single octet; it is defined as
|
|
651
|
+
</p>
|
|
652
|
+
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
|
|
653
|
+
I(U, V) = GF_SUM L_i(U) (*) V[i].
|
|
654
|
+
i=0,M-1
|
|
655
|
+
</pre></div><p>
|
|
656
|
+
|
|
657
|
+
To reconstruct a secret from a set of shares, the following
|
|
658
|
+
procedure, or any equivalent method, is used:
|
|
659
|
+
</p>
|
|
660
|
+
<blockquote class="text">
|
|
661
|
+
<p>
|
|
662
|
+
If the number of shares provided as input to the secret
|
|
663
|
+
reconstruction operation is greater than the threshold M, then M
|
|
664
|
+
of those shares are selected for use in the operation. The method
|
|
665
|
+
used to select the shares can be arbitrary.
|
|
666
|
+
|
|
667
|
+
</p>
|
|
668
|
+
<p>
|
|
669
|
+
If the shares are not equal length, then the input
|
|
670
|
+
is inconsistent. An error should be reported,
|
|
671
|
+
and processing must halt.
|
|
672
|
+
|
|
673
|
+
</p>
|
|
674
|
+
<p>
|
|
675
|
+
The output string is initialized to the empty (zero-length)
|
|
676
|
+
octet string.
|
|
677
|
+
|
|
678
|
+
</p>
|
|
679
|
+
<p>
|
|
680
|
+
The octet array U is formed by setting U[i] equal to
|
|
681
|
+
the first octet of the ith share. (Note that the
|
|
682
|
+
ordering of the shares is arbitrary, but must
|
|
683
|
+
be consistent throughout this algorithm.)
|
|
684
|
+
|
|
685
|
+
</p>
|
|
686
|
+
<p>
|
|
687
|
+
The initial octet is stripped from each share.
|
|
688
|
+
|
|
689
|
+
</p>
|
|
690
|
+
<p>
|
|
691
|
+
If any two elements of the array U have the same value,
|
|
692
|
+
then an error condition has occurred; this fact should
|
|
693
|
+
be reported, then the procedure must halt.
|
|
694
|
+
|
|
695
|
+
</p>
|
|
696
|
+
<p>
|
|
697
|
+
For each octet of the shares, the following steps are performed.
|
|
698
|
+
An array V of M octets is created, in which the array element
|
|
699
|
+
V[i] contains the octet from the ith share.
|
|
700
|
+
The value of I(U, V) is computed, then appended
|
|
701
|
+
to the output string.
|
|
702
|
+
|
|
703
|
+
</p>
|
|
704
|
+
<p>
|
|
705
|
+
The output string is returned.
|
|
706
|
+
|
|
707
|
+
</p>
|
|
708
|
+
</blockquote><p>
|
|
709
|
+
After the procedure is done, the string that is returned contains one
|
|
710
|
+
fewer octet than do the shares.
|
|
711
|
+
|
|
712
|
+
</p>
|
|
713
|
+
<a name="anchor10"></a><br /><hr />
|
|
714
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
715
|
+
<a name="rfc.section.4"></a><h3>4.
|
|
716
|
+
Robust Threshold Secret Sharing</h3>
|
|
717
|
+
|
|
718
|
+
<p>
|
|
719
|
+
A robust TSS system, or RTSS, is one that provides security even when
|
|
720
|
+
one or more of the shares that are provided to the reconstruction
|
|
721
|
+
algorithm may be crafted by a malicious adversary. In addition, an
|
|
722
|
+
RTSS system will detect unintentional corruption of the shares.
|
|
723
|
+
|
|
724
|
+
</p>
|
|
725
|
+
<p>
|
|
726
|
+
We provide robustness by adding a pre-processing step to the TSS share
|
|
727
|
+
generation step, and a post-processing step to the TSS secret
|
|
728
|
+
reconstruction step. The pre-processing consists of taking the secret
|
|
729
|
+
S, then appending a hash H(S) to it. The post-processing step
|
|
730
|
+
consists of verifying that the reconstructed secret has the form S ||
|
|
731
|
+
H(S), where the symbol || denotes the concatenation operation. The
|
|
732
|
+
hash function must be collision-resistant; all RTSS implementations
|
|
733
|
+
MUST support the SHA-256 hash algorithm <a class='info' href='#SHS'>[SHS]<span> (</span><span class='info'>, “FIPS 180-3: Secure Hash Standard,,” 2008.</span><span>)</span></a>.
|
|
734
|
+
|
|
735
|
+
</p>
|
|
736
|
+
<p>
|
|
737
|
+
If the robust reconstruction operation fails, and the number of shares
|
|
738
|
+
that are available is greater than the threshold, then the operation
|
|
739
|
+
MAY be tried on a different set of shares.
|
|
740
|
+
|
|
741
|
+
</p>
|
|
742
|
+
<p>
|
|
743
|
+
An RTSS system can perform an additional operation that verifies
|
|
744
|
+
the validity of a set of shares. This operation has
|
|
745
|
+
the same inputs as the Reconstruct operation. Its output
|
|
746
|
+
consists of an indication whether or not the secret could
|
|
747
|
+
be reconstructed, but the secret itself is not returned.
|
|
748
|
+
This operation may be useful in a situation in where the availability
|
|
749
|
+
of a secret must be verified, for example, as part of an audit.
|
|
750
|
+
|
|
751
|
+
</p>
|
|
752
|
+
<a name="anchor11"></a><br /><hr />
|
|
753
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
754
|
+
<a name="rfc.section.4.1"></a><h3>4.1.
|
|
755
|
+
RTSS Data Format</h3>
|
|
756
|
+
|
|
757
|
+
<p>
|
|
758
|
+
We use a data format with the following fields, in order:
|
|
759
|
+
</p>
|
|
760
|
+
<blockquote class="text"><dl>
|
|
761
|
+
<dt>Identifier.</dt>
|
|
762
|
+
<dd>
|
|
763
|
+
This field contains 16 octets. It identifies the secret with
|
|
764
|
+
which a share is associated. All of the shares associated with a
|
|
765
|
+
particular secret MUST use the same value Identifier. When a
|
|
766
|
+
secret is reconstructed, the Identifier fields of each of the
|
|
767
|
+
shares used as input MUST have the same value. The value
|
|
768
|
+
of the Identifier should be chosen so that it is unique, but
|
|
769
|
+
the details on how it is chosen are out of scope of this document.
|
|
770
|
+
|
|
771
|
+
</dd>
|
|
772
|
+
<dt>Hash Algorithm Identifier.</dt>
|
|
773
|
+
<dd>
|
|
774
|
+
This field contains a single octet that indicates the hash
|
|
775
|
+
function used in the RTSS processing, if any. A value of zero
|
|
776
|
+
indicates that no hash algorithm was used, no hash was
|
|
777
|
+
appended to the secret, and no RTSS check should be performed
|
|
778
|
+
after the reconstruction of the secret. Other
|
|
779
|
+
values are defined in the table below.
|
|
780
|
+
|
|
781
|
+
</dd>
|
|
782
|
+
<dt>Threshold.</dt>
|
|
783
|
+
<dd>
|
|
784
|
+
This field contains a single octet that indicates the number of
|
|
785
|
+
shares required to reconstruct the secret. This field MUST be
|
|
786
|
+
checked during the reconstruction process, and that process MUST
|
|
787
|
+
halt and return an error if the number of shares available is
|
|
788
|
+
fewer than the value indicated in this field.
|
|
789
|
+
|
|
790
|
+
</dd>
|
|
791
|
+
<dt>Share Length.</dt>
|
|
792
|
+
<dd>
|
|
793
|
+
This field is two octets long. It contains the
|
|
794
|
+
number of octets in the Share Data field, represented
|
|
795
|
+
as an unsigned integer in network byte order.
|
|
796
|
+
|
|
797
|
+
</dd>
|
|
798
|
+
<dt>Share Data.</dt>
|
|
799
|
+
<dd>
|
|
800
|
+
This field has a length that is a variable number
|
|
801
|
+
of octets. It contains the actual share data.
|
|
802
|
+
|
|
803
|
+
</dd>
|
|
804
|
+
</dl></blockquote><p>
|
|
805
|
+
This format is illustrated in <a class='info' href='#ShareFormat'>Figure 3<span> (</span><span class='info'>Share Format. </span><span>)</span></a>.
|
|
806
|
+
<br /><hr class="insert" />
|
|
807
|
+
<a name="ShareFormat"></a>
|
|
808
|
+
</p>
|
|
809
|
+
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
|
|
810
|
+
0 1 2 3
|
|
811
|
+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
812
|
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
813
|
+
| |
|
|
814
|
+
| Identifier |
|
|
815
|
+
| |
|
|
816
|
+
| |
|
|
817
|
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
818
|
+
| Hash Alg. Id. | Threshold | Share Length |
|
|
819
|
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
820
|
+
: :
|
|
821
|
+
: Share Data :
|
|
822
|
+
: :
|
|
823
|
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
824
|
+
</pre></div><p>
|
|
825
|
+
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 3: Share Format. </b></font><br /></td></tr></table><hr class="insert" />
|
|
826
|
+
|
|
827
|
+
|
|
828
|
+
|
|
829
|
+
</p>
|
|
830
|
+
<p>
|
|
831
|
+
The correspondence between the Hash Algorithm Identifier field and
|
|
832
|
+
the hash algorithm used in RTSS is defined by the table below.
|
|
833
|
+
Each hash function outputs a fixed number of octets; the length
|
|
834
|
+
of the output of each hash is indicated in the table.
|
|
835
|
+
|
|
836
|
+
</p><table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
|
|
837
|
+
<col align="left"><col align="right"><col align="right">
|
|
838
|
+
<tr><th align="left">Hash Algorithm</th><th align="right">Hash Algorithm Identifier</th><th align="right">Length (octets)</th></tr>
|
|
839
|
+
<tr>
|
|
840
|
+
<td align="left">NULL_HASH </td>
|
|
841
|
+
<td align="right"> 0 </td>
|
|
842
|
+
<td align="right"> 0 </td>
|
|
843
|
+
</tr>
|
|
844
|
+
<tr>
|
|
845
|
+
<td align="left">SHA-1 <a class='info' href='#SHS'>[SHS]<span> (</span><span class='info'>, “FIPS 180-3: Secure Hash Standard,,” 2008.</span><span>)</span></a> </td>
|
|
846
|
+
<td align="right">1 </td>
|
|
847
|
+
<td align="right">20 </td>
|
|
848
|
+
</tr>
|
|
849
|
+
<tr>
|
|
850
|
+
<td align="left">SHA-256 <a class='info' href='#SHS'>[SHS]<span> (</span><span class='info'>, “FIPS 180-3: Secure Hash Standard,,” 2008.</span><span>)</span></a> </td>
|
|
851
|
+
<td align="right">2 </td>
|
|
852
|
+
<td align="right">32 </td>
|
|
853
|
+
</tr>
|
|
854
|
+
<tr>
|
|
855
|
+
<td align="left">RESERVED </td>
|
|
856
|
+
<td align="right">3-127 </td>
|
|
857
|
+
<td align="right"> not applicable </td>
|
|
858
|
+
</tr>
|
|
859
|
+
<tr>
|
|
860
|
+
<td align="left">Vendor specific </td>
|
|
861
|
+
<td align="right">128-255 </td>
|
|
862
|
+
<td align="right"> not applicable </td>
|
|
863
|
+
</tr>
|
|
864
|
+
</table>
|
|
865
|
+
<br clear="all" />
|
|
866
|
+
|
|
867
|
+
<a name="anchor12"></a><br /><hr />
|
|
868
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
869
|
+
<a name="rfc.section.5"></a><h3>5.
|
|
870
|
+
Error Correction and Data Recovery</h3>
|
|
871
|
+
|
|
872
|
+
<p>
|
|
873
|
+
TSS and RTSS are suitable for the protection of long-term key
|
|
874
|
+
material. In such applications, it is highly desirable to provide
|
|
875
|
+
protection against the accidental corruption of the shares.
|
|
876
|
+
This section defines data formats that can be used
|
|
877
|
+
to protect shares. These formats are optional extensions
|
|
878
|
+
to the basic TSS and RTSS systems.
|
|
879
|
+
|
|
880
|
+
</p>
|
|
881
|
+
<a name="anchor13"></a><br /><hr />
|
|
882
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
883
|
+
<a name="rfc.section.5.1"></a><h3>5.1.
|
|
884
|
+
Data Recovery</h3>
|
|
885
|
+
|
|
886
|
+
<p>
|
|
887
|
+
To protect against the corruption of the filesystem that is holding
|
|
888
|
+
the shares, a "magic number" can be used as the initial part of the
|
|
889
|
+
share data format <a class='info' href='#FILESIG'>[FILESIG]<span> (</span><span class='info'>Kessler, G., “File Signatures Table,” 2007.</span><span>)</span></a>. A magic number is a
|
|
890
|
+
constant data string that is chosen arbitrarily, but which is unlikely
|
|
891
|
+
to appear in other contexts, and thus can be used to recognize a data
|
|
892
|
+
format when it appears in an arbitrary data stream. The use of a
|
|
893
|
+
magic number in the data format for a share greatly simplifies the
|
|
894
|
+
task of finding a share after a filesystem has been corrupted.
|
|
895
|
+
|
|
896
|
+
</p>
|
|
897
|
+
<p>
|
|
898
|
+
The 8-octet magic number f628f91b52023d11 (hexadecimal) SHOULD be
|
|
899
|
+
used. The number was selected randomly from a uniform distribution.
|
|
900
|
+
|
|
901
|
+
</p>
|
|
902
|
+
<a name="anchor14"></a><br /><hr />
|
|
903
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
904
|
+
<a name="rfc.section.5.2"></a><h3>5.2.
|
|
905
|
+
Error Correction</h3>
|
|
906
|
+
|
|
907
|
+
<p>
|
|
908
|
+
To protect against data corruption in the underlying media, an
|
|
909
|
+
error-correcting code (ECC) can be used. An ECC system consists of an
|
|
910
|
+
encoding function, which maps the data to a codeword, and a decoding
|
|
911
|
+
function, which maps a (possibly corrupted) codeword to the data. The
|
|
912
|
+
simplest such code is a repetition code, in which multiple copies of
|
|
913
|
+
the data are stored. In this specification, all ECCs must be
|
|
914
|
+
systematic, that is, the data must appear as the initial bytes of the
|
|
915
|
+
codeword. This property allows an implementation of the ECC to avoid
|
|
916
|
+
the implementation of the full decoding algorithm.
|
|
917
|
+
|
|
918
|
+
</p>
|
|
919
|
+
<p>
|
|
920
|
+
We use a data format that incorporates the following fields, in order:
|
|
921
|
+
</p>
|
|
922
|
+
<blockquote class="text"><dl>
|
|
923
|
+
<dt>Encoding Type.</dt>
|
|
924
|
+
<dd>
|
|
925
|
+
This field is four octets long. It contains an unsigned integer
|
|
926
|
+
in network byte order that denotes the type of the encoding, i.e.
|
|
927
|
+
the algorithm that was used during the encoding process.
|
|
928
|
+
|
|
929
|
+
</dd>
|
|
930
|
+
<dt>Data Length.</dt>
|
|
931
|
+
<dd>
|
|
932
|
+
This field is four octets long. It contains an unsigned integer
|
|
933
|
+
in network byte order that denotes the number of octets
|
|
934
|
+
in the Data field.
|
|
935
|
+
|
|
936
|
+
</dd>
|
|
937
|
+
<dt>Redundancy Length.</dt>
|
|
938
|
+
<dd>
|
|
939
|
+
This field is four octets long. It contains an unsigned integer
|
|
940
|
+
in network byte order that denotes the number of octets
|
|
941
|
+
in the Redundancy field.
|
|
942
|
+
|
|
943
|
+
</dd>
|
|
944
|
+
<dt>Data.</dt>
|
|
945
|
+
<dd>
|
|
946
|
+
This field has a length that is a variable number of octets, which
|
|
947
|
+
is indicated by the Data Length field. It
|
|
948
|
+
contains the data that is intended to be conveyed by the code. If
|
|
949
|
+
no data corruption has occurred, then this field will contain the
|
|
950
|
+
data that was originally encoded.
|
|
951
|
+
|
|
952
|
+
</dd>
|
|
953
|
+
<dt>Redundancy.</dt>
|
|
954
|
+
<dd>
|
|
955
|
+
This field has a length that is a variable number of octets, which
|
|
956
|
+
is indicated by the Redundancy Length field. It
|
|
957
|
+
contains information that can be used to check whether or not
|
|
958
|
+
there are any errors in the Data field, and to correct some
|
|
959
|
+
errors that may have occurred.
|
|
960
|
+
|
|
961
|
+
</dd>
|
|
962
|
+
</dl></blockquote><p>
|
|
963
|
+
This format is illustrated in <a class='info' href='#ECF'>Figure 4<span> (</span><span class='info'>Error Correction Format. </span><span>)</span></a>.
|
|
964
|
+
<br /><hr class="insert" />
|
|
965
|
+
<a name="ECF"></a>
|
|
966
|
+
</p>
|
|
967
|
+
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
|
|
968
|
+
+--------------------------------+
|
|
969
|
+
| Encoding Type |
|
|
970
|
+
| (4 octets) |
|
|
971
|
+
+--------------------------------+
|
|
972
|
+
| Data Length |
|
|
973
|
+
| (4 octets) |
|
|
974
|
+
+--------------------------------+
|
|
975
|
+
| Redundancy Length |
|
|
976
|
+
| (4 octets) |
|
|
977
|
+
+--------------------------------+
|
|
978
|
+
| |
|
|
979
|
+
~ Data ~
|
|
980
|
+
| (variable number of octets) |
|
|
981
|
+
| |
|
|
982
|
+
+--------------------------------+
|
|
983
|
+
| |
|
|
984
|
+
~ Redundancy ~
|
|
985
|
+
| (variable number of octets) |
|
|
986
|
+
| |
|
|
987
|
+
+--------------------------------+
|
|
988
|
+
</pre></div><p>
|
|
989
|
+
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 4: Error Correction Format. </b></font><br /></td></tr></table><hr class="insert" />
|
|
990
|
+
|
|
991
|
+
|
|
992
|
+
</p>
|
|
993
|
+
<p>
|
|
994
|
+
If a code has a free parameter, the value of that parameter
|
|
995
|
+
MUST be inferable from the values of the Data Length
|
|
996
|
+
and Redundancy Length fields.
|
|
997
|
+
|
|
998
|
+
</p>
|
|
999
|
+
<a name="anchor15"></a><br /><hr />
|
|
1000
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
1001
|
+
<a name="rfc.section.5.3"></a><h3>5.3.
|
|
1002
|
+
A Repetition Code</h3>
|
|
1003
|
+
|
|
1004
|
+
<p>
|
|
1005
|
+
This section defines a format for a repetition code, which is a
|
|
1006
|
+
particular error correcting code that is conceptually simple and easy
|
|
1007
|
+
to implement.
|
|
1008
|
+
|
|
1009
|
+
</p>
|
|
1010
|
+
<p>
|
|
1011
|
+
The value of the Encoding Type field is equal to 0000001 (hexadecimal).
|
|
1012
|
+
|
|
1013
|
+
</p>
|
|
1014
|
+
<p>
|
|
1015
|
+
The Redundancy field contains R copies of the Data field, where R is
|
|
1016
|
+
an even number.
|
|
1017
|
+
The Redundancy Length is equal to the Data Length times R. The
|
|
1018
|
+
value of R MAY be equal to zero, in which case no error
|
|
1019
|
+
detection or correction is possible (but implementation is
|
|
1020
|
+
simple). The value of R SHOULD be at least two.
|
|
1021
|
+
|
|
1022
|
+
</p>
|
|
1023
|
+
<p>
|
|
1024
|
+
For example, if the data that is encoded is equal to 68656c6c6f (hexadecimal),
|
|
1025
|
+
then the ECF data with R=2 would be
|
|
1026
|
+
</p>
|
|
1027
|
+
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
|
|
1028
|
+
<- ET -><- DL -><- RL -><- Data -><--- Redundancy --->
|
|
1029
|
+
00000001000000050000000a68656c6c6f68656c6c6f68656c6c6f
|
|
1030
|
+
</pre></div><p>
|
|
1031
|
+
|
|
1032
|
+
|
|
1033
|
+
</p>
|
|
1034
|
+
<p>
|
|
1035
|
+
To check the Data field for errors, that field should be compared
|
|
1036
|
+
with each of its copies in the redundancy field.
|
|
1037
|
+
|
|
1038
|
+
</p>
|
|
1039
|
+
<p>
|
|
1040
|
+
The Repetition Code can be decoded by using majority-logic decoding.
|
|
1041
|
+
Considering both the Data and Redundancy fields, there are R+1
|
|
1042
|
+
(possibly corrupted) copies of the original data, where R+1 is an odd
|
|
1043
|
+
number. The decoding process independently considers each octet of
|
|
1044
|
+
the Data field, and the corresponding octets of the copies that appear in
|
|
1045
|
+
the Redundancy field. That is, the ith octet of the Data, plus octets
|
|
1046
|
+
i, L+i, 2L+i, ... , RL+i, are analyzed independent from all other
|
|
1047
|
+
octets, where L is the value of the Data Length field. The
|
|
1048
|
+
following algorithm is applied to these octets.
|
|
1049
|
+
The binary representation of each octet is
|
|
1050
|
+
considered. For each bit in that representation, if more
|
|
1051
|
+
of the copies have a "1" in that position than have a "0"
|
|
1052
|
+
in that position, then that position is decoded to the value "1";
|
|
1053
|
+
otherwise, it is decoded to "0". This process is repeated
|
|
1054
|
+
for all of the bit position. After all of the bits in the
|
|
1055
|
+
octet have been decoded, the value of the ith octet
|
|
1056
|
+
in the output of the decoding algorithm is computed, using
|
|
1057
|
+
the same binary representation as before.
|
|
1058
|
+
|
|
1059
|
+
</p>
|
|
1060
|
+
<p>
|
|
1061
|
+
For example, if the data that was encoded in the previous
|
|
1062
|
+
example was corrupted to the value
|
|
1063
|
+
</p>
|
|
1064
|
+
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
|
|
1065
|
+
<- ET -><- DL -><- RL -><- Data -><--- Redundancy --->
|
|
1066
|
+
00000001000000050000000a68656c6c2f68656c6cef68656c6c6f
|
|
1067
|
+
** ** **
|
|
1068
|
+
</pre></div><p>
|
|
1069
|
+
|
|
1070
|
+
then decoding would proceed as follows. The fifth octet of the Data
|
|
1071
|
+
field is equal to 2f, while the fifth and tenth octets of the
|
|
1072
|
+
Redundancy field are equal to ef and 6f, respectively. Using a bit
|
|
1073
|
+
representation with the most significant bit on the left, the octets
|
|
1074
|
+
and the "majority" octet are as follows:
|
|
1075
|
+
</p>
|
|
1076
|
+
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
|
|
1077
|
+
hex binary
|
|
1078
|
+
octet from Data 2f 00101111
|
|
1079
|
+
octet from first copy ef 11101111
|
|
1080
|
+
octet from second copy 6f 01101111
|
|
1081
|
+
----------------------------------------
|
|
1082
|
+
majority 6f 01101111
|
|
1083
|
+
</pre></div><p>
|
|
1084
|
+
|
|
1085
|
+
Thus the fifth octet in the output of the decoding algorithm
|
|
1086
|
+
will be 6f.
|
|
1087
|
+
|
|
1088
|
+
</p>
|
|
1089
|
+
<a name="anchor16"></a><br /><hr />
|
|
1090
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
1091
|
+
<a name="rfc.section.6"></a><h3>6.
|
|
1092
|
+
Format</h3>
|
|
1093
|
+
|
|
1094
|
+
<p>
|
|
1095
|
+
This section summarizes the order of processing for when secret
|
|
1096
|
+
sharing is performed using the facilities for robustness (RTSS), error
|
|
1097
|
+
correction (ECC), and data recovery (Magic Number), and clarifies the
|
|
1098
|
+
relationships between data formats. This processing can be viewed as
|
|
1099
|
+
a layered model, as illustrated in <a class='info' href='#model'>Figure 5<span> (</span><span class='info'>The combined processing model.</span><span>)</span></a>. (Note that
|
|
1100
|
+
we have not adhered to a strictly layered model, for the sake of
|
|
1101
|
+
simplicity, since the format defined by RTSS is used after the shares
|
|
1102
|
+
are generated.)
|
|
1103
|
+
|
|
1104
|
+
</p>
|
|
1105
|
+
<p>
|
|
1106
|
+
When RTSS is used, it is applied to the secret before the
|
|
1107
|
+
sharing operation (and is removed from the secret after
|
|
1108
|
+
the reconstruction operation). The RTSS data format
|
|
1109
|
+
MUST be used.
|
|
1110
|
+
|
|
1111
|
+
</p>
|
|
1112
|
+
<p>
|
|
1113
|
+
When ECC is used, it is applied to the RTSS data after the sharing
|
|
1114
|
+
operation, so that the ECC Data field contains the entire RTSS Data
|
|
1115
|
+
Format.
|
|
1116
|
+
|
|
1117
|
+
</p>
|
|
1118
|
+
<p>
|
|
1119
|
+
When a Magic Number is used, it is added after the ECC
|
|
1120
|
+
formatting is done, and it is prepended to the Error
|
|
1121
|
+
Correction Format.
|
|
1122
|
+
|
|
1123
|
+
</p><br /><hr class="insert" />
|
|
1124
|
+
<a name="model"></a>
|
|
1125
|
+
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
|
|
1126
|
+
Secret Secret
|
|
1127
|
+
| ^
|
|
1128
|
+
v |
|
|
1129
|
+
+------------------+ +------------------+
|
|
1130
|
+
| Append Hash | | Verify Hash |
|
|
1131
|
+
+------------------+ +------------------+
|
|
1132
|
+
| |
|
|
1133
|
+
+------------------+ +------------------+
|
|
1134
|
+
| Generate Shares | |Reconstruct Secret|
|
|
1135
|
+
+------------------+ +------------------+
|
|
1136
|
+
| |
|
|
1137
|
+
+------------------+ +------------------+
|
|
1138
|
+
| ECC Encoding | | ECC Decoding |
|
|
1139
|
+
+------------------+ +------------------+
|
|
1140
|
+
| |
|
|
1141
|
+
+------------------+ +------------------+
|
|
1142
|
+
| Add Magic Number | |Strip Magic Number|
|
|
1143
|
+
+------------------+ +------------------+
|
|
1144
|
+
| ^
|
|
1145
|
+
v |
|
|
1146
|
+
Shares ----------------> Shares
|
|
1147
|
+
</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 5: The combined processing model. </b></font><br /></td></tr></table><hr class="insert" />
|
|
1148
|
+
|
|
1149
|
+
<a name="anchor17"></a><br /><hr />
|
|
1150
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
1151
|
+
<a name="rfc.section.7"></a><h3>7.
|
|
1152
|
+
Design and Rationale</h3>
|
|
1153
|
+
|
|
1154
|
+
<p>
|
|
1155
|
+
In this implementation, the secret and the shares are octet
|
|
1156
|
+
strings. Each octet is treated as an element of the finite field
|
|
1157
|
+
GF(256). The share-generation algorithm is applied to each octet
|
|
1158
|
+
of the secret independently. Similarly, the octets are treated
|
|
1159
|
+
independently during the reconstruction of the secrets from the
|
|
1160
|
+
shares.
|
|
1161
|
+
|
|
1162
|
+
</p>
|
|
1163
|
+
<p>
|
|
1164
|
+
Shamir's original description treats the secret as a large integer
|
|
1165
|
+
modulo a large prime number <a class='info' href='#shamir'>[shamir]<span> (</span><span class='info'>Shamir, A., “How to share a secret,” 1979.</span><span>)</span></a>. The advantages
|
|
1166
|
+
of using a vector over GF(256) are that the computations are more
|
|
1167
|
+
efficient and the encoding is simpler. Multiplication and inversion
|
|
1168
|
+
over GF(256) can be done with two table lookups and two exors, using
|
|
1169
|
+
two fixed tables of 256 bytes each. One limitation of the GF(256)
|
|
1170
|
+
approach is that the number of shares that can be generated cannot
|
|
1171
|
+
be greater than 255; this limitation is unlikely to be important in
|
|
1172
|
+
practice, since fewer than ten shares are typically used.
|
|
1173
|
+
|
|
1174
|
+
</p>
|
|
1175
|
+
<p>
|
|
1176
|
+
The reconstruction of the secret is done using Lagrange
|
|
1177
|
+
interpolation polynomials. This method is simple and easily
|
|
1178
|
+
tested. For large thresholds, this method is less efficient than
|
|
1179
|
+
an optimal method would be. However, performance is still good,
|
|
1180
|
+
and it is expected that the reconstruction of the secret will not
|
|
1181
|
+
be a performance-critical operation.
|
|
1182
|
+
|
|
1183
|
+
</p>
|
|
1184
|
+
<a name="testing"></a><br /><hr />
|
|
1185
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
1186
|
+
<a name="rfc.section.8"></a><h3>8.
|
|
1187
|
+
Testing</h3>
|
|
1188
|
+
|
|
1189
|
+
<p>
|
|
1190
|
+
As with every crypto algorithm, it is essential to test an
|
|
1191
|
+
implementation of TSS or RTSS for correctness. This section provides
|
|
1192
|
+
guidance for such testing.
|
|
1193
|
+
|
|
1194
|
+
</p>
|
|
1195
|
+
<p>
|
|
1196
|
+
The Secret Reconstruction algorithm can be tested using Known Answer
|
|
1197
|
+
Tests (KATs). Test cases are provided in <a class='info' href='#CASES'>Section 9<span> (</span><span class='info'>Test Cases</span><span>)</span></a>.
|
|
1198
|
+
|
|
1199
|
+
</p>
|
|
1200
|
+
<p>
|
|
1201
|
+
The Share Generation algorithm cannot be directly tested using a KAT.
|
|
1202
|
+
It can be indirectly tested by generating secret values uniformly at
|
|
1203
|
+
random, then applying the Share Generation process to them to generate
|
|
1204
|
+
a set of shares, then applying the Share Reconstruction algorithm to
|
|
1205
|
+
the shares, then finally comparing the reconstructed secret to the
|
|
1206
|
+
original secret. Implementations SHOULD perform this test, using a
|
|
1207
|
+
variety of thresholds and secret lengths.
|
|
1208
|
+
|
|
1209
|
+
</p>
|
|
1210
|
+
<p>
|
|
1211
|
+
The Share Index (the initial octet of each share) can never be equal
|
|
1212
|
+
to zero. This property SHOULD be tested.
|
|
1213
|
+
|
|
1214
|
+
</p>
|
|
1215
|
+
<p>
|
|
1216
|
+
The random source must be tested to ensure that it has
|
|
1217
|
+
high min-entropy.
|
|
1218
|
+
|
|
1219
|
+
</p>
|
|
1220
|
+
<a name="CASES"></a><br /><hr />
|
|
1221
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
1222
|
+
<a name="rfc.section.9"></a><h3>9.
|
|
1223
|
+
Test Cases</h3>
|
|
1224
|
+
|
|
1225
|
+
<p>
|
|
1226
|
+
This section provides test cases that can be used to validate an
|
|
1227
|
+
implementation of the Secret Reconstruction algorithm. All values are
|
|
1228
|
+
in hexadecimal.
|
|
1229
|
+
|
|
1230
|
+
</p>
|
|
1231
|
+
<p>
|
|
1232
|
+
</p>
|
|
1233
|
+
<blockquote class="text"><dl>
|
|
1234
|
+
<dt>algorithm -</dt>
|
|
1235
|
+
<dd>
|
|
1236
|
+
The algorithm used in the test case.
|
|
1237
|
+
|
|
1238
|
+
</dd>
|
|
1239
|
+
<dt>secret -</dt>
|
|
1240
|
+
<dd>
|
|
1241
|
+
The secret value to be split into shares.
|
|
1242
|
+
|
|
1243
|
+
</dd>
|
|
1244
|
+
<dt>threshold -</dt>
|
|
1245
|
+
<dd>
|
|
1246
|
+
The number of shares required to reconstruct a secret; above,
|
|
1247
|
+
this value is associated with the variable M.
|
|
1248
|
+
|
|
1249
|
+
</dd>
|
|
1250
|
+
<dt>num. shares -</dt>
|
|
1251
|
+
<dd>
|
|
1252
|
+
The number of shares included in the example; above,
|
|
1253
|
+
this value is associated with the variable N.
|
|
1254
|
+
|
|
1255
|
+
</dd>
|
|
1256
|
+
<dt>share index -</dt>
|
|
1257
|
+
<dd>
|
|
1258
|
+
A share index. Each test case has multiple distinct share values, and
|
|
1259
|
+
each share is associated with a distinct share index.
|
|
1260
|
+
|
|
1261
|
+
</dd>
|
|
1262
|
+
<dt>share -</dt>
|
|
1263
|
+
<dd>
|
|
1264
|
+
A share value, which corresponds to the share index value immediately above it.
|
|
1265
|
+
|
|
1266
|
+
</dd>
|
|
1267
|
+
</dl></blockquote><p>
|
|
1268
|
+
|
|
1269
|
+
|
|
1270
|
+
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
|
|
1271
|
+
algorithm = TSS
|
|
1272
|
+
secret = 7465737400
|
|
1273
|
+
threshold (M) = 2
|
|
1274
|
+
num. shares (N) = 2
|
|
1275
|
+
share index = 1
|
|
1276
|
+
share = B9FA07E185
|
|
1277
|
+
share index = 2
|
|
1278
|
+
share = F5409B4511
|
|
1279
|
+
</pre></div>
|
|
1280
|
+
<a name="anchor18"></a><br /><hr />
|
|
1281
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
1282
|
+
<a name="rfc.section.10"></a><h3>10.
|
|
1283
|
+
Security Considerations</h3>
|
|
1284
|
+
|
|
1285
|
+
<p>
|
|
1286
|
+
It is crucial for security that the source of randomness
|
|
1287
|
+
used in the share generation process by cryptographically
|
|
1288
|
+
strong; it MUST be suitable for generating cryptographic
|
|
1289
|
+
keys. <a class='info' href='#RFC4086'>[RFC4086]<span> (</span><span class='info'>Eastlake, D., Schiller, J., and S. Crocker, “Randomness Requirements for Security,” June 2005.</span><span>)</span></a> provides guidance on
|
|
1290
|
+
the selection and implementation of random sources.
|
|
1291
|
+
|
|
1292
|
+
</p>
|
|
1293
|
+
<p>
|
|
1294
|
+
A TSS implementation SHOULD be tested as described in
|
|
1295
|
+
<a class='info' href='#testing'>Section 8<span> (</span><span class='info'>Testing</span><span>)</span></a>.
|
|
1296
|
+
|
|
1297
|
+
</p>
|
|
1298
|
+
<p>
|
|
1299
|
+
The confidentiality of the shares generated by TSS should be
|
|
1300
|
+
protected, since the exposure of too many shares will
|
|
1301
|
+
undermine the security of the system. Note that, in this
|
|
1302
|
+
regard, share values are more comparable to secret keys than
|
|
1303
|
+
to ciphertext.
|
|
1304
|
+
|
|
1305
|
+
</p>
|
|
1306
|
+
<a name="anchor19"></a><br /><hr />
|
|
1307
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
1308
|
+
<a name="rfc.section.11"></a><h3>11.
|
|
1309
|
+
IANA Considerations</h3>
|
|
1310
|
+
|
|
1311
|
+
<p>
|
|
1312
|
+
This document has no actions for IANA.
|
|
1313
|
+
|
|
1314
|
+
</p>
|
|
1315
|
+
<a name="anchor20"></a><br /><hr />
|
|
1316
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
1317
|
+
<a name="rfc.section.12"></a><h3>12.
|
|
1318
|
+
Acknowledgements</h3>
|
|
1319
|
+
|
|
1320
|
+
<p>
|
|
1321
|
+
Thanks to Brian Weis and Jack Lloyd for constructive feedback.
|
|
1322
|
+
|
|
1323
|
+
</p>
|
|
1324
|
+
<a name="rfc.references"></a><br /><hr />
|
|
1325
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
1326
|
+
<a name="rfc.section.13"></a><h3>13.
|
|
1327
|
+
References</h3>
|
|
1328
|
+
|
|
1329
|
+
<a name="rfc.references1"></a><br /><hr />
|
|
1330
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
1331
|
+
<h3>13.1. Normative References</h3>
|
|
1332
|
+
<table width="99%" border="0">
|
|
1333
|
+
<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
|
|
1334
|
+
<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,” BCP 14, RFC 2119, March 1997 (<a href="http://www.rfc-editor.org/rfc/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr>
|
|
1335
|
+
<tr><td class="author-text" valign="top"><a name="RFC4086">[RFC4086]</a></td>
|
|
1336
|
+
<td class="author-text">Eastlake, D., Schiller, J., and S. Crocker, “<a href="http://tools.ietf.org/html/rfc4086">Randomness Requirements for Security</a>,” BCP 106, RFC 4086, June 2005 (<a href="http://www.rfc-editor.org/rfc/rfc4086.txt">TXT</a>).</td></tr>
|
|
1337
|
+
<tr><td class="author-text" valign="top"><a name="SHS">[SHS]</a></td>
|
|
1338
|
+
<td class="author-text">“FIPS 180-3: Secure Hash Standard,,” Federal Information Processing Standard (FIPS) http://csrc.nist.gov/publications/fips/fips180-2/fips180-3.pdf, 2008.</td></tr>
|
|
1339
|
+
</table>
|
|
1340
|
+
|
|
1341
|
+
<a name="rfc.references2"></a><br /><hr />
|
|
1342
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
1343
|
+
<h3>13.2. Informative References</h3>
|
|
1344
|
+
<table width="99%" border="0">
|
|
1345
|
+
<tr><td class="author-text" valign="top"><a name="FILESIG">[FILESIG]</a></td>
|
|
1346
|
+
<td class="author-text">Kessler, G., “File Signatures Table,” Web page http://www.garykessler.net/library/file_sigs.html, 2007.</td></tr>
|
|
1347
|
+
<tr><td class="author-text" valign="top"><a name="POLY">[POLY]</a></td>
|
|
1348
|
+
<td class="author-text">Seroussi, G., “Table of Low-Weight Binary Irreducible Polynomials,” Hewlett-Packard Computer Systems Laboratory Technical Report HPL-98-135, 1998.</td></tr>
|
|
1349
|
+
<tr><td class="author-text" valign="top"><a name="shamir">[shamir]</a></td>
|
|
1350
|
+
<td class="author-text">Shamir, A., “How to share a secret,” Communications of the ACM (22): 612-613, 1979.</td></tr>
|
|
1351
|
+
</table>
|
|
1352
|
+
|
|
1353
|
+
<a name="anchor23"></a><br /><hr />
|
|
1354
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
1355
|
+
<a name="rfc.section.A"></a><h3>Appendix A.
|
|
1356
|
+
Mathematical Background</h3>
|
|
1357
|
+
|
|
1358
|
+
<p>
|
|
1359
|
+
In abstract algebra, a finite field is an algebraic structure
|
|
1360
|
+
for which the operations of addition, subtraction,
|
|
1361
|
+
multiplication and division are defined and satisfy certain
|
|
1362
|
+
axioms.
|
|
1363
|
+
</p>
|
|
1364
|
+
<p>
|
|
1365
|
+
The field GF(256) has exactly 256 elements in it. There is
|
|
1366
|
+
only one field with that number of elements, but there are
|
|
1367
|
+
many different ways in which the elements of the field can be
|
|
1368
|
+
represented. This document uses a polynomial representation
|
|
1369
|
+
in which the field polynomial is the unique irreducible
|
|
1370
|
+
polynomial with minimum weight of degree 8 over GF(2)
|
|
1371
|
+
<a class='info' href='#POLY'>[POLY]<span> (</span><span class='info'>Seroussi, G., “Table of Low-Weight Binary Irreducible Polynomials,” 1998.</span><span>)</span></a>, hence it is the 'canonical' choice for a
|
|
1372
|
+
polynomial base representation of GF(256). This field
|
|
1373
|
+
representation is also used by the Advanced Encryption
|
|
1374
|
+
Standard (AES).
|
|
1375
|
+
|
|
1376
|
+
|
|
1377
|
+
</p>
|
|
1378
|
+
<a name="rfc.authors"></a><br /><hr />
|
|
1379
|
+
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
|
|
1380
|
+
<h3>Authors' Addresses</h3>
|
|
1381
|
+
<table width="99%" border="0" cellpadding="0" cellspacing="0">
|
|
1382
|
+
<tr><td class="author-text"> </td>
|
|
1383
|
+
<td class="author-text">David A. McGrew</td></tr>
|
|
1384
|
+
<tr><td class="author-text"> </td>
|
|
1385
|
+
<td class="author-text">Cisco Systems, Inc.</td></tr>
|
|
1386
|
+
<tr><td class="author-text"> </td>
|
|
1387
|
+
<td class="author-text">510 McCarthy Blvd.</td></tr>
|
|
1388
|
+
<tr><td class="author-text"> </td>
|
|
1389
|
+
<td class="author-text">Milpitas, CA 95035</td></tr>
|
|
1390
|
+
<tr><td class="author-text"> </td>
|
|
1391
|
+
<td class="author-text">US</td></tr>
|
|
1392
|
+
<tr><td class="author" align="right">Email: </td>
|
|
1393
|
+
<td class="author-text"><a href="mailto:mcgrew@cisco.com">mcgrew@cisco.com</a></td></tr>
|
|
1394
|
+
<tr><td class="author" align="right">URI: </td>
|
|
1395
|
+
<td class="author-text"><a href="http://www.mindspring.com/~dmcgrew/dam.htm">http://www.mindspring.com/~dmcgrew/dam.htm</a></td></tr>
|
|
1396
|
+
<tr cellpadding="3"><td> </td><td> </td></tr>
|
|
1397
|
+
<tr><td class="author-text"> </td>
|
|
1398
|
+
<td class="author-text">Praveen Patnala</td></tr>
|
|
1399
|
+
<tr><td class="author-text"> </td>
|
|
1400
|
+
<td class="author-text">Consultant</td></tr>
|
|
1401
|
+
<tr><td class="author" align="right">Email: </td>
|
|
1402
|
+
<td class="author-text"><a href="mailto:praveenpatnala@yahoo.com">praveenpatnala@yahoo.com</a></td></tr>
|
|
1403
|
+
<tr cellpadding="3"><td> </td><td> </td></tr>
|
|
1404
|
+
<tr><td class="author-text"> </td>
|
|
1405
|
+
<td class="author-text">Alfred Hoenes</td></tr>
|
|
1406
|
+
<tr><td class="author-text"> </td>
|
|
1407
|
+
<td class="author-text">TR-Sys</td></tr>
|
|
1408
|
+
<tr><td class="author-text"> </td>
|
|
1409
|
+
<td class="author-text">Gerlinger Str. 12</td></tr>
|
|
1410
|
+
<tr><td class="author-text"> </td>
|
|
1411
|
+
<td class="author-text">Ditzingen D-71254</td></tr>
|
|
1412
|
+
<tr><td class="author-text"> </td>
|
|
1413
|
+
<td class="author-text">Germany</td></tr>
|
|
1414
|
+
<tr><td class="author" align="right">Email: </td>
|
|
1415
|
+
<td class="author-text"><a href="mailto:ah@TR-Sys.de">ah@TR-Sys.de</a></td></tr>
|
|
1416
|
+
</table>
|
|
1417
|
+
</body></html>
|