tss 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- 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>
|