|
1 <HTML> |
|
2 <HEAD> |
|
3 <TITLE>Security Glossary</TITLE> |
|
4 </HEAD> |
|
5 <BODY> |
|
6 |
|
7 <H1><CENTER><b>Security Glossary</b></CENTER></H1> |
|
8 |
|
9 <P><center><TABLE WIDTH="90%" BORDER="1" CELLSPACING="1" CELLPADDING="2"><TR |
|
10 HEIGHT=0> |
|
11 <TD WIDTH="25%"></TD><TD WIDTH="75%"></TD></TD> |
|
12 </TR> |
|
13 |
|
14 <TR> |
|
15 <TD> |
|
16 Security Classification |
|
17 </td> |
|
18 <td> |
|
19 Internal |
|
20 </td> |
|
21 </tr> |
|
22 |
|
23 <TR> |
|
24 <TD> |
|
25 Document Reference |
|
26 </td> |
|
27 <td> |
|
28 SGL.GT0128.56 |
|
29 </td> |
|
30 </tr> |
|
31 |
|
32 <TR> |
|
33 <TD> |
|
34 Status |
|
35 </td> |
|
36 <td> |
|
37 Draftversion |
|
38 </td> |
|
39 </tr> |
|
40 |
|
41 <TR> |
|
42 <TD> |
|
43 Version |
|
44 </td> |
|
45 <td> |
|
46 0.1 |
|
47 </td> |
|
48 </tr> |
|
49 |
|
50 <TR> |
|
51 <TD> |
|
52 Team/Department |
|
53 </td> |
|
54 <td> |
|
55 Security Team |
|
56 </td> |
|
57 </tr> |
|
58 |
|
59 <TR> |
|
60 <TD> |
|
61 Author |
|
62 </td> |
|
63 <td> |
|
64 William Bamberg |
|
65 </td> |
|
66 </tr> |
|
67 |
|
68 <TR> |
|
69 <TD> |
|
70 Owner |
|
71 </td> |
|
72 <td> |
|
73 Security Team |
|
74 </td> |
|
75 </tr> |
|
76 |
|
77 <TR HEIGHT=0><TD WIDTH="35%"></TD><TD |
|
78 WIDTH="65%"></TD></TR></TABLE></P></center> |
|
79 |
|
80 <P><center><TABLE WIDTH="90%" BORDER="1" CELLSPACING="1" CELLPADDING="2"><TR |
|
81 HEIGHT=0> |
|
82 <TD WIDTH="25%"></TD><TD WIDTH="75%"></TD></TD> |
|
83 </TR> |
|
84 |
|
85 <TR> |
|
86 <TD> |
|
87 <A name="Asymmetric Cryptography"></A>Asymmetric Cryptography |
|
88 </td> |
|
89 <td> |
|
90 A form of cryptography in which the 'key' is generated as a key pair: if one key is used for encryption |
|
91 only the other can be used to decrypt, and vice versa. |
|
92 <p> |
|
93 Using asymmetric cryptography, the problem of key distribution becomes one of authentication; i.e. how to make sure |
|
94 that a given key really does belong to the entity that claims to own it. |
|
95 </td> |
|
96 </tr> |
|
97 |
|
98 <TR> |
|
99 <TD> |
|
100 Attribute Certificate |
|
101 </td> |
|
102 <td> |
|
103 A digitally signed data structure including at least an identifier for an individual entity |
|
104 and a set of attributes, whose function is to bind the entity with the attributes, usually for the |
|
105 purpose of authorisation. |
|
106 </td> |
|
107 </tr> |
|
108 |
|
109 <TR> |
|
110 <TD> |
|
111 <A name="Authentication"></A>Authentication |
|
112 </td> |
|
113 <td> |
|
114 Usually used to refer to a property of a communication; that the receiver of a message is able to ascertain its origin, |
|
115 so an attacker cannot successfully impersonate the sender. |
|
116 </td> |
|
117 </tr> |
|
118 |
|
119 <TR> |
|
120 <TD> |
|
121 <A name="Block Cipher"></A>Block Cipher |
|
122 </td> |
|
123 <td> |
|
124 A class of <A HREF="#Symmetric Cryptography">symmetric algorithm</A> in which several bits of the input data |
|
125 are encrypted at once in a fixed-size block. |
|
126 The cipher and its mode of operation define the block size: |
|
127 the plaintext is split up into appropriately-sized blocks and each block is fed into the cipher. |
|
128 </td> |
|
129 </tr> |
|
130 |
|
131 <TR> |
|
132 <TD> |
|
133 CA Certificate |
|
134 </td> |
|
135 <td> |
|
136 A certificate held by a <A HREF="#Certification Authority">CA</A>: the key pair associated with it is used for |
|
137 signing certificates issued by that CA. May or may not be self-signed. |
|
138 </td> |
|
139 </tr> |
|
140 |
|
141 <TR> |
|
142 <TD> |
|
143 <A name="Certificate"></A>Certificate |
|
144 </td> |
|
145 <td> |
|
146 For our purposes, this is the same thing as a <A HREF="#Public Key Certificate"> |
|
147 public key certificate</A> |
|
148 </td> |
|
149 </tr> |
|
150 |
|
151 <TR> |
|
152 <TD><A name="Certification Authority"></A>Certification Authority (CA) |
|
153 </td> |
|
154 <td> |
|
155 An organization which perform the following functions in a hierachical <A HREF="#Public Key Infrastructure">PKI</A>: |
|
156 <ul> |
|
157 <li> |
|
158 providing trusted ‘root’ certificates to users (<A HREF="#End Entities">End Entities</A>), by |
|
159 supplying them with the CA’s public key via out-of-band means. |
|
160 </li> |
|
161 <li> |
|
162 certifying End Entities by generating and distributing certificates for them. |
|
163 The certified EE is the subject of the certificate: the CA is the issuer. |
|
164 </li> |
|
165 <li> |
|
166 supporting certificate <A HREF="#Revocation">revocation</A> and revocation checking: if an EE suspects that their key has |
|
167 been compromised, they contact the CA which issued it, who should revoke their certificate. |
|
168 </li> |
|
169 </ul> |
|
170 <p>A CA will always have a root certificate-signing key pair, which must be authenticated to End Entities via |
|
171 out of band channels. This key pair is not logically certified by anything, but it is usually distributed inside |
|
172 a <A HREF="#Self-signed Certificate">self-signed certificate</A> to afford some degree of <A HREF="#Tamper Evidency">tamper evidency</A>. |
|
173 <p>However, CAs do not have to use their root key pair to issue certificates directly to End Entities. For organizational |
|
174 reasons and to reduce the exposure of keys, a CA may have a single root signing key pair, which it uses to certify a |
|
175 set of subordinate key pairs, which in turn are used to certify End Entities. Also, CAs may certify the |
|
176 signing keys of other CAs by issuing <A HREF="#Cross Certificate">cross certificates</A>, which enable interoperation |
|
177 between two distinct PKIs. |
|
178 </td> |
|
179 </tr> |
|
180 |
|
181 <TR> |
|
182 <TD> |
|
183 <A name="Ciphertext"></A>Ciphertext |
|
184 </td> |
|
185 <td> |
|
186 The output of an <A HREF="#Encryption">encryption</A> operation, or |
|
187 the input to a <A HREF="#Decryption">decryption</A> operation. |
|
188 </td> |
|
189 </tr> |
|
190 |
|
191 <TR> |
|
192 <TD> |
|
193 <A name="Client Authentication"></A>Client Authentication |
|
194 </td> |
|
195 <td> |
|
196 In a secure client-server protocol such as <A HREF="#Transport Layer Security">TLS</A>, the process in which the client |
|
197 <A HREF="#Authentication">authenticates</A> itself to the server, so the server knows who it's talking to. |
|
198 </td> |
|
199 </tr> |
|
200 |
|
201 <TR> |
|
202 <TD> |
|
203 Client/User/End Entity Certificate |
|
204 </td> |
|
205 <td> |
|
206 A <A HREF="#Certificate">certificate</A> issued by a <A HREF="#Certification Authority">CA</A> to an |
|
207 <A HREF="#End Entity">end entity</A> (for example the user of a WID) who may use it |
|
208 to demonstrate their ownership of the key pair associated with it |
|
209 </td> |
|
210 </tr> |
|
211 |
|
212 |
|
213 <TR> |
|
214 <TD> |
|
215 <A name="Cross Certificate"></A>Cross Certificate |
|
216 </td> |
|
217 <td> |
|
218 A <A HREF="#Certificate">certificate</A> issued by a <A HREF="#Certification Authority">CA</A> which certificates another |
|
219 CA's <A HREF="#Root Certificate">root certificate</A>. This is way of uniting two distinct certification hierarchies. |
|
220 </td> |
|
221 </tr> |
|
222 |
|
223 <TR> |
|
224 <TD> |
|
225 <A name="Decryption"></A>Decryption |
|
226 </td> |
|
227 <td> |
|
228 The process of turning encrypted data (called ciphertext) into the original information (called plaintext) |
|
229 using a cryptographic algorithm parameterised with a key. |
|
230 </td> |
|
231 </tr> |
|
232 |
|
233 <TR> |
|
234 <TD> |
|
235 <A name="Digital Signature"></A>Digital Signature |
|
236 </td> |
|
237 <td> |
|
238 A structure linking some data and a private key. A digital signature may be generated by the application of a |
|
239 <A HREF="#Private Key">private key</A> to some piece of data. The original data |
|
240 may be reconstructed by applying the corresponding public key, demonstrating that the signature could only have been generated by |
|
241 someone with access to the private key. |
|
242 <p>Digital signatures have two primary uses: to demonstrate someone's identity by signing some challenge, as in |
|
243 <A HREF="#Client Authentication">client authentication</A> in <A HREF="#Transport Layer Security">TLS</A>, in which the client |
|
244 signs a <A HREF="#Hash">hash</A> of the messages that have been exchanged, and more strongly, for someone to demonstrate their |
|
245 acceptance of some human-processable information (e.g. 'Please withdraw £10 000 from my bank account') as in the |
|
246 <A HREF="#WMLScript Crypto API">WMLScript Crypto API</A> <A HREF="#SignText">SignText</A> function. |
|
247 </td> |
|
248 </tr> |
|
249 |
|
250 <TR> |
|
251 <TD> |
|
252 <A name="DSA"></A>Digital Signature Algorithm (DSA) |
|
253 </td> |
|
254 <td> |
|
255 NIST-approved <A HREF="#Asymmetric Cryptography">asymmetric algorithm</A>. It can only be used for generating and |
|
256 verifying <A HREF="#Digital Signature">digital signatures</A>, not for encryption. |
|
257 </td> |
|
258 </tr> |
|
259 |
|
260 <TR> |
|
261 <TD> |
|
262 <A name="ECC"></A>Elliptic Curve Cryptography (ECC) |
|
263 </td> |
|
264 <td> |
|
265 Elliptical curve cryptography (ECC) is an <A HREF="#Asymmetric Cryptography">asymmetric algorithm</A> |
|
266 based on elliptic curve theory that can be used to create faster, smaller, and more efficient cryptographic keys. |
|
267 Because ECC helps to establish equivalent security with lower computing power and battery resource usage, |
|
268 it is becoming widely used for mobile applications. |
|
269 </td> |
|
270 </tr> |
|
271 |
|
272 <TR> |
|
273 <TD> |
|
274 <A name="Encryption"></A>Encryption |
|
275 </td> |
|
276 <td> |
|
277 The process of turning meaningful data (called plaintext) into meaningless gibberish (called ciphertext) |
|
278 using a cryptographic algorithm parameterised with a key. |
|
279 </td> |
|
280 </tr> |
|
281 |
|
282 <TR> |
|
283 <TD> |
|
284 <A name="End Entity"></A>End Entity |
|
285 </td> |
|
286 <td> |
|
287 A leaf node in a certification hierarchy: any entity in a <A HREF="#Public Key Infrastructure">PKI</A> |
|
288 which has a certificate, but is not allowed to issue its own certificates. |
|
289 </td> |
|
290 </tr> |
|
291 |
|
292 |
|
293 <TR> |
|
294 <TD> |
|
295 <A name="Hash"></A>Hash |
|
296 </td> |
|
297 <td> |
|
298 Hash algorithms take a variable-length input and produce a fixed length output known as a digest, or hash, of the input. |
|
299 For cryptographic purposes they need to be one-way functions: |
|
300 it should not be possible to deduce the input from the digest, or even any part of the input. |
|
301 Also, it should be hard to find collisions: that is, two different inputs which produce the same output. |
|
302 </td> |
|
303 </tr> |
|
304 |
|
305 <TR> |
|
306 <TD> |
|
307 <A name="HMAC"></A>HMAC |
|
308 </td> |
|
309 <td> |
|
310 Keyed-Hashing for Message Authentication. A mechanism for message authentication using cryptographic |
|
311 <A HREF="#Hash">hashes</A>. It can be used with any iterative cryptographic |
|
312 hash function, e.g., <A HREF="#MD5">MD5</A>, <A HREF="#SHA-1">SHA-1</A>, in combination with a secret shared key. |
|
313 The cryptographic strength of HMAC depends on the properties of the underlying hash function. |
|
314 </td> |
|
315 </tr> |
|
316 |
|
317 <TR> |
|
318 <TD> |
|
319 ICC |
|
320 </td> |
|
321 <td> |
|
322 Integrated Circuit Card: removable card with at least data storage and sometimes processing |
|
323 </td> |
|
324 </tr> |
|
325 |
|
326 <TR> |
|
327 <TD> |
|
328 <A name="IPSec"></A>IPSec |
|
329 </td> |
|
330 <td> |
|
331 A standard providing <A HREF="#Secrecy">secrecy</A> and <A HREF="#Authentication">authentication</A> at the network or |
|
332 packet-processing layer of network communication. Earlier security approaches have inserted security at the |
|
333 application layer of the communications model. IPsec will be especially useful for implementing virtual |
|
334 private networks and for remote user access through dial-up connection to private networks. IPSec is mandatory in IPv6. |
|
335 </td> |
|
336 </tr> |
|
337 |
|
338 <TR> |
|
339 <TD> |
|
340 <A name="MD2"></A>MD2 |
|
341 </td> |
|
342 <td> |
|
343 Legacy <A HREF="#Hash">hash algorithm</A>. Considered insecure. |
|
344 </td> |
|
345 </tr> |
|
346 |
|
347 <TR> |
|
348 <TD> |
|
349 <A name="MD5"></A>MD5 |
|
350 </td> |
|
351 <td> |
|
352 Legacy <A HREF="#Hash">hash algorithm</A>. Considered vulnerable. |
|
353 </td> |
|
354 </tr> |
|
355 |
|
356 <TR> |
|
357 <TD> |
|
358 <A name="Message Digest Algorithm"></A>Message Digest Algorithm |
|
359 </td> |
|
360 <td> |
|
361 Same thing as a <A HREF="#Hash">hash algorithm</A>. |
|
362 </td> |
|
363 </tr> |
|
364 |
|
365 <TR> |
|
366 <TD> |
|
367 <A name="Nonrepudiation"></A>Nonrepudiation |
|
368 </td> |
|
369 <td> |
|
370 The process by which it is assured that an entity making a declaration cannot subsequently deny having made it: |
|
371 so I can't claim that I never wrote that cheque. |
|
372 </td> |
|
373 </tr> |
|
374 |
|
375 <TR> |
|
376 <TD> |
|
377 <A name="OCSP"></A>Online Certificate Status Protocol (OCSP) |
|
378 </td> |
|
379 <td> |
|
380 A protocol enabling a <A HREF="#Relying Party">relying party</A> to check that a |
|
381 <A HREF="#Certificate">certificate</A> has not been <A HREF="#Revocation">revoked</A>. In this protocol the OCSP client |
|
382 asks the OCSP server about the status of one or more certificates, and receives a |
|
383 <A HREF="#Digital Signature">digitally signed</A> response. |
|
384 </td> |
|
385 </tr> |
|
386 |
|
387 <TR> |
|
388 <TD> |
|
389 <A name="Out Of Band"></A>Out Of Band |
|
390 </td> |
|
391 <td> |
|
392 A channel of communication which is distinct from the channel which we are using cryptography to try to secure, |
|
393 and which is secure on its own terms; that is, its security is not dependent on the cryptography we are using. |
|
394 <p>A common example of an out of band channel is a motorcycle courier. |
|
395 </td> |
|
396 </tr> |
|
397 |
|
398 <TR> |
|
399 <TD> |
|
400 <A name="Padding"></A>Padding |
|
401 </td> |
|
402 <td> |
|
403 The process of adding bytes to the input to a <A HREF="#Block Cipher">block cipher</A> so that the input matches the |
|
404 block size. |
|
405 </td> |
|
406 </tr> |
|
407 |
|
408 <TR> |
|
409 <TD> |
|
410 <A name="Plaintext"></A>Plaintext |
|
411 </td> |
|
412 <td> |
|
413 The output of an <A HREF="#Decryption">decryption</A> operation, or |
|
414 the input to a <A HREF="#Encryption">encryption</A> operation. |
|
415 </td> |
|
416 </tr> |
|
417 |
|
418 <TR> |
|
419 <TD> |
|
420 <A name="PGP"></A>Pretty Good Privacy (PGP) |
|
421 </td> |
|
422 <td> |
|
423 A very widely-used <A HREF="#Encryption">encryption</A> and <A HREF="#Digital Signature">digital signing</A> |
|
424 program. |
|
425 </td> |
|
426 </tr> |
|
427 |
|
428 <TR> |
|
429 <TD> |
|
430 <A name="Private Key"></A>Private Key |
|
431 </td> |
|
432 <td> |
|
433 In the context of <A HREF="#Public Key Cryptography">public key cryptography</A>, the private half of the key pair. |
|
434 </td> |
|
435 </tr> |
|
436 |
|
437 <TR> |
|
438 <TD> |
|
439 <A name="Public Key"></A>Public Key |
|
440 </td> |
|
441 <td> |
|
442 In the context of <A HREF="#Public Key Cryptography">public key cryptography</A>, the public half of the key pair. |
|
443 </td> |
|
444 </tr> |
|
445 |
|
446 <TR> |
|
447 <TD> |
|
448 <A name="Public Key Certificate"></A>Public Key Certificate |
|
449 </td> |
|
450 <td> |
|
451 A digitally signed structure including at least an identifier for an |
|
452 individual entity and a public key, whose function is to bind the entity with the key. |
|
453 </td> |
|
454 </tr> |
|
455 |
|
456 <TR> |
|
457 <TD> |
|
458 <A name="Public Key Cryptography"></A>Public Key Cryptography |
|
459 </td> |
|
460 <td> |
|
461 A common application of <A HREF="#Asymmetric Cryptography">asymmetric cryptography</A> in which one half of the key pair is |
|
462 kept secrect (the <A HREF="#Private Key">private key</A>) and the other half is published |
|
463 (the <A HREF="#Public Key">public key</A>. |
|
464 </td> |
|
465 </tr> |
|
466 |
|
467 <TR> |
|
468 <TD> |
|
469 <A name="Public Key Infrastructure"></A>Public Key Infrastructure |
|
470 </td> |
|
471 <td> |
|
472 |
|
473 <p>A way of modelling real-world trust relationships which enables users of <A HREF="#Public Key Cryptography">public key cryptography</A> |
|
474 to have confidence in the ownership of |
|
475 the public keys they are using. |
|
476 |
|
477 A PKI consists of: |
|
478 <ul> |
|
479 <li> |
|
480 a <A HREF="#Trusted Third Party">trusted third party</a> |
|
481 </li> |
|
482 <li> |
|
483 an <A HREF="#Out Of Band">out of band</A> means of distributing the TTP's <A HREF="#Public Key Certificate">public key certificate</A> |
|
484 to <A HREF="#Relying Party">relying parties</a> |
|
485 </li> |
|
486 <li> |
|
487 a means of distributing other certificates to relying parties |
|
488 </li> |
|
489 <li> |
|
490 arrangements for the <A HREF="#Revocation">revocation</A> and renewal of these certificates |
|
491 </li> |
|
492 <li> |
|
493 certificate management and validation software on the relying party's computer |
|
494 </li> |
|
495 </ul> |
|
496 <p>The TTP uses its signing key pair to create certificates for other entities, which relying parties can use to authenticate these |
|
497 other entities. |
|
498 <p>We can classify PKIs according to whether they are hierachical or flat. In hierachical PKIs, such as the one defined in the <A HREF="#PKIX">PKIX</A> |
|
499 set of standards, there is a distinction between users of the PKI such as <A HREF="#End Entity">End Entities</A> and |
|
500 <A HREF="#Relying Party">Relying Parties</A>, and entities responsible for issuing and distributing certificates such as |
|
501 <A HREF="#Certification Authority">CAs</A> and <A HREF="#Registration Authority">RAs</A>. In a flat PKI such as the |
|
502 <A HREF="#Web of Trust">web of trust</A> underpinning <A HREF="#Pretty Good Privacy">PGP</A>, there are no entities whose |
|
503 sole role is to issue certificates; instead users of the PKI certify each other. |
|
504 </td> |
|
505 </tr> |
|
506 |
|
507 <TR> |
|
508 <TD> |
|
509 <A name="Registration Authority"></A>Registration Authority |
|
510 </td> |
|
511 <td> |
|
512 An organization responsible for registering new certificate users in a |
|
513 <A HREF="#Public Key Infrastructure">PKI</A>, e.g. by gathering and verifying information which identifies the |
|
514 certificate applicant. |
|
515 </td> |
|
516 </tr> |
|
517 |
|
518 <TR> |
|
519 <TD> |
|
520 <A name="Revocation"></A>Revocation |
|
521 </td> |
|
522 <td> |
|
523 The term used for asserting that a certificate is no longer valid: for example, because the private key |
|
524 associated with it has been compromised. |
|
525 </td> |
|
526 </tr> |
|
527 |
|
528 <TR> |
|
529 <TD> |
|
530 <A name="Relying Party"></A>Relying Party |
|
531 </td> |
|
532 <td> |
|
533 An entity who relies on the authenticity of a <A HREF="#Public Key">public key</a>. |
|
534 </td> |
|
535 </tr> |
|
536 |
|
537 <TR> |
|
538 <TD> |
|
539 <A name="Root Certificate"></A>Root Certificate |
|
540 </td> |
|
541 <td> |
|
542 The certificate of a <A HREF="#Trusted Third Party">trusted third party</a>. |
|
543 A certificate directly trusted by a <A HREF="#Relying Party">relying party</A>: that is, trust in it is not |
|
544 established by cryptographic means, but trust in it is the prerequisite for establishing trust in the entity |
|
545 which the relying party is trying to authenticate. |
|
546 Trust in a root certificate must be established through <A HREF="#Out Of Band">out of band</A> means. A root certificate may or may not be self signed. |
|
547 </td> |
|
548 </tr> |
|
549 |
|
550 <TR> |
|
551 <TD> |
|
552 <A name="Secrecy"></A>Secrecy |
|
553 </td> |
|
554 <td> |
|
555 This means that access to information is controlled: for example, it means that two entities |
|
556 (e.g. people, machines, processes) are able to communicate with one another without any other entities |
|
557 being able to access the information communicated, or that an entity may store some information and be |
|
558 assured that only this entity will be able to access it. |
|
559 </td> |
|
560 </tr> |
|
561 |
|
562 <TR> |
|
563 <TD> |
|
564 <A name="SHA-1"></A>Secure Hash Algorithm 1(SHA-1) |
|
565 </td> |
|
566 <td> |
|
567 A widely used <A HREF="#Hash">hash algorithm</a>, producing a 160-bit digest. |
|
568 </td> |
|
569 </tr> |
|
570 |
|
571 <TR> |
|
572 <TD> |
|
573 <A name="SSL"></A>Secure Sockets Layer (SSL) |
|
574 </td> |
|
575 <td> |
|
576 Precursor to <A HREF="#Transport Layer Security">TLS</a>. SSL has been through three versions: |
|
577 the first two are considered insecure, and the third is almost identical to TLS. |
|
578 </td> |
|
579 </tr> |
|
580 |
|
581 <TR> |
|
582 <TD> |
|
583 <A name="Server Authentication"></A>Server Authentication |
|
584 </td> |
|
585 <td> |
|
586 In a secure client-server protocol such as <A HREF="#Transport Layer Security">TLS</A>, the process in which the server |
|
587 <A HREF="#Authentication">authenticates</A> itself to the client, so the client knows who it's talking to. |
|
588 </td> |
|
589 </tr> |
|
590 |
|
591 <TR> |
|
592 <TD> |
|
593 <A name="SignText"></A>SignText |
|
594 </td> |
|
595 <td> |
|
596 A function defined in the <A HREF="#WMLScript Crypto API">WMLScript Crypto API</A> which provides application-level |
|
597 <A HREF="#Authentication">Authentication</A> and <A HREF="#Nonrepudiation">Nonrepudiation</A> for transactions. |
|
598 </td> |
|
599 </tr> |
|
600 |
|
601 <TR> |
|
602 <TD> |
|
603 <A name="Stream Cipher"></A>Stream Cipher |
|
604 </td> |
|
605 <td> |
|
606 A class of <A HREF="#Symmetric Cryptography">symmetric algorithm</A> which is initialised with a key, |
|
607 then outputs a stream of pseudorandom bits. |
|
608 This 'keystream' is typically XOR-ed with the plaintext to generate the ciphertext. |
|
609 So they encrypt a bit of plaintext at a time. |
|
610 </td> |
|
611 </tr> |
|
612 |
|
613 <TR> |
|
614 <TD> |
|
615 <A name="Symmetric Cryptography"></A>Symmetric Cryptography |
|
616 </td> |
|
617 <td> |
|
618 A form of cryptography in which the same key is used for encryption and decryption |
|
619 <p> |
|
620 Symmetric cryptography is fast, but suffers from the problem of how to distribute the key privately. |
|
621 <A HREF="#Asymmetric Cryptography">Asymmetric cryptography</a> is an attempt to alleviate the key |
|
622 distribution problem, by reducing the requirement for the distributed key from one of privacy to one of |
|
623 authentication. |
|
624 </td> |
|
625 </tr> |
|
626 |
|
627 <TR> |
|
628 <TD> |
|
629 <A name="Transport Layer Security"></A>Transport Layer Security (TLS) |
|
630 </td> |
|
631 <td> |
|
632 A client-server security protocol providing <A HREF="#Secrecy">secrecy</a> and optionally <A HREF="#Authentication">authentication</a>, and |
|
633 running over TCP/IP. |
|
634 <p>In this protocol a client connects to a server; the two then perform a handshake in which they exchange a |
|
635 <A HREF="#Symmetric Cryptography">symmetric</a> key by using <A HREF="#Asymmetric Cryptography">asymmetric cryptography</a>, |
|
636 which is then used to encrypt their communications, providing the secrecy element. |
|
637 <p>Without the authentication element secrecy is not very useful; although only client and server can understand the data |
|
638 exchanged, the client doesn't know who the server is or vice versa. TLS provides the capability for |
|
639 <A HREF="#Server Authentication">server authentication</a>, in which the client establishes who the server is, and |
|
640 <A HREF="#Client Authentication">client authentication</a> in which the server establishes who the client is. |
|
641 </td> |
|
642 </tr> |
|
643 |
|
644 <TR> |
|
645 <TD> |
|
646 <A name="Trusted Third Party"></A>Trusted Third Party (TTP) |
|
647 </td> |
|
648 <td> |
|
649 An entity whose public key is known to a <A HREF="#Relying Party">relying party</a> due to its having been |
|
650 received via <A HREF="#Out Of Band">out of band</A> means, and which is trusted to issue <A HREF="#Public Key Certificate"> |
|
651 public key certificates</A> for other entities not directly known to the relying party. |
|
652 <p>A <A HREF="#Certification Authority">CA</a> is a type of TTP. |
|
653 </td> |
|
654 </tr> |
|
655 |
|
656 <TR> |
|
657 <TD> |
|
658 <A name="Web of Trust"></A>Web of Trust |
|
659 </td> |
|
660 <td> |
|
661 The set of social relationships between users of <A HREF="#PGP">PGP</a> that enables them to sign each others' keys, |
|
662 essentially providing a <A HREF="#PKI">PKI</a> for this technology. |
|
663 </td> |
|
664 </tr> |
|
665 |
|
666 <TR> |
|
667 <TD> |
|
668 <A name="WMLScript Crypto API"></A>WMLScript Crypto API |
|
669 </td> |
|
670 <td> |
|
671 A WAP Forum standard which defines cryptographic functions in WML, the scripting language used in WAP. |
|
672 It defines a function for creating signed objects called <A HREF="#SignText">SignText</a> |
|
673 </td> |
|
674 </tr> |
|
675 |
|
676 |
|
677 <TR> |
|
678 <TD> |
|
679 <A name="WTLS"></A>WTLS |
|
680 </td> |
|
681 <td> |
|
682 A client-server security protocol providing <A HREF="#Secrecy">secrecy</a> and optionally <A HREF="#Authentication">authentication</a>, |
|
683 running at the transport layer of the WAP stack. WTLS is closely modelled on <A HREF="#Transport Layer Security">TLS</a>, |
|
684 and defines its own lightweight <A HREF="#Public Key Certificate">certificate</a> format. |
|
685 </td> |
|
686 </tr> |
|
687 |
|
688 <TR> |
|
689 <TD> |
|
690 <A name="X.509 Certificate"></A>X.509 Certificate |
|
691 </td> |
|
692 <td> |
|
693 A widely used type of <A HREF="#Public Key Certificate">public key certificates</A>, part of the |
|
694 now largely moribund X.500 series of standards. |
|
695 </td> |
|
696 </tr> |
|
697 |
|
698 <!-- |
|
699 <TR><TD><A HREF="/rfc2459">RFC 2459</a></td> |
|
700 <td>PKIX Certificate and CRL Profile<br> |
|
701 <b>This RFC is being updated by two new Internet draftversions, |
|
702 <a href="/draftversion-ietf-pkix-new-part1">draftversion-ietf-pkix-new-part1</a> |
|
703 and <a href="/draftversion-ietf-pkix-ipki-pkalgs">draftversion-ietf-pkix-ipki-pkalgs</a>.</b> |
|
704 </td> |
|
705 </tr> |
|
706 --> |
|
707 |
|
708 <!-- |
|
709 <TR><TD><A |
|
710 HREF="/draftversion-ramsdell-role-names">draftversion-ramsdell-role-names</A></TD><TD>Role |
|
711 Names in X.509 Certificates</TD> |
|
712 <TD>Expired</TD></TR> |
|
713 --> |
|
714 |
|
715 <TR HEIGHT=0><TD WIDTH="35%"></TD><TD |
|
716 WIDTH="65%"></TD></TR></TABLE></P></center> |
|
717 |
|
718 </BODY></HTML> |