-
-| A | |
-
-| @anchor AES AES |
- Advanced Encryption Standard -- The new conventional symmetric @ref block_cipher "block cipher" chosen by NIST as a
- replacement for @ref DES. It can process 128-bit data blocks using
- cipher keys with lengths of 128, 192, or 256 bits. |
-
-| @anchor ASN ASN.1 |
- Abstract Syntax Notation 1 (See: ASN.1,
- ISO/IEC 8824, and ISO/IEC 8825.) -- A data specification meta-language widely used in @ref public_key_cryptography "public key cryptography"
- standards. (Also of interest: A Layman's Guide to
- a Subset of ASN.1, BER, and DER.) |
-
-| @anchor asymmetric @anchor Asymmetric Asymmetric Cryptography |
- A form of cryptography in which the 'key' is generated as a key pair: if one key is used for @ref encryption only the
- other can be used to decrypt, and vice versa. \n\n
- Using asymmetric cryptography, the problem of key distribution becomes one of @ref authentication; i.e. how to make sure
- that a given key really does belong to the entity that claims to own it. See:
- @li @ref asymmetric_cryptography
- @li @ref SS_Cryptalg_asymmetric_ciphers. |
-
-| @anchor attribute_cert Attribute Certificate |
- A digitally signed data structure including at least an identifier for an individual entity and a set of
- attributes, whose function is to bind the entity with the attributes, usually for the purpose of authorisation.
- |
-
-| @anchor authentication @anchor Authentication Authentication |
- Usually used to refer to a property of a communication; that the receiver of a message is able to ascertain its
- origin, so an attacker cannot successfully impersonate the sender. |
-
-
-
-
\n @anchor B \n
-
-| C | |
-
-| @anchor CA CA |
- Certification Authority -- An organisation that performs the following functions in a hierachical @ref PKI:
- @li providing trusted @ref root_certificate "'root' certificates" to users (@ref EE "End Entities"), by supplying them with the CA's @ref public_key "public key" via
- out-of-band means.
- @li certifying End Entities (@ref EE "EE"s) by generating and distributing certificates for them. The certified @ref EE is the
- subject of the @ref certificate; the CA is the issuer. The CA validates the certificate holder's identity and 'signs'
- the @ref certificate so that it cannot be tampered with or forged. The @ref certificate issued by the CA binds a particular
- @ref public_key "public key" to the name of the @ref EE the @ref certificate identifies.
- @li supporting certificate revocation and revocation checking: if an @ref EE suspects that their key has been compromised,
- they can contact the CA that issued it, who will then revoke their @ref certificate.
-
- A CA will always have a root certificate-signing key pair that must be authenticated to End Entities via @ref out_of_band "out of band"
- channels. This key pair is not logically certified by anything, but it is usually distributed inside a self-signed
- @ref certificate to afford some degree of tamper evidency. \n\n
- However, CAs do not have to use their root key pair to issue certificates directly to End Entities. For organizational
- reasons and to reduce the exposure of keys, a CA may have a single root signing key pair, which it uses to certify a
- set of subordinate key pairs that in turn are used to certify End Entities. Also, CAs may certify the signing keys
- of other CAs by issuing cross certificates, which enable interoperation between two distinct @ref PKI "PKI"s. |
-
-| @anchor CA_certificate CA Certificate
- | A @ref certificate held by a @ref CA: the key pair associated with it is used for signing certificates issued by that
- @ref CA. May or may not be self-signed. |
-
-| @anchor CBC CBC |
- Cipher Block Chaining -- A cryptographic mode for @ref block_cipher "block ciphers". It is an @ref encryption method that protects
- against block replay attacks by making the encryption of a cipher block dependent on all blocks that precede it.
- Before it is encrypted, the @ref plaintext is XORed with the previous @ref ciphertext block (which has been stored in a
- feedback register). After the encryption, the resulting ciphertext is again stored in the feedback register, to
- be XORed with the next plaintext block, and so on until the end of the message. |
-
-| @anchor certificate @anchor certificates Certificate |
- For our purposes, this is the same thing as a @ref public_key_certificate "public key certificate". |
-
-| @anchor ciphermode Ciphermode |
- description |
-
-| @anchor ciphertext Ciphertext |
- The output of an @ref encryption operation, or the input to a @ref decryption operation. |
-
-| @anchor CLDC CLDC |
- J2ME Connected Limited Device Configuration -- Serves the market consisting of personal, mobile, and
- connected information devices. This configuration includes some new classes designed specifically to fit the
- needs of small-footprint devices. |
-
-| @anchor client_authentication Client Authentication |
- In a secure client-server protocol such as @ref TLS, the process in which the client authenticates itself to
- the server, so the server knows who it's talking to. \n See @ref WTLS_client_authentication "client authentication in WTLS". |
-
-| Client/User/End Entity Certificate |
- A @ref certificate issued by a @ref CA to an end entity, @ref EE, who may use it to demonstrate their
- ownership of the key pair associated with it. |
-
-| @anchor CRL CRL |
- Certificate Revocation List -- A list of (identifiers for) @ref certificates that have been revoked by a
- particular @ref CA. The use of CRLs is for maintaining access to servers in a network, in a @ref PKI; in some cases,
- @ref OCSP has superseded CRL. See:
- @li RFC2459
- -- Internet @ref X509 "X.509" @ref PKI Certificate and CRL Profile
- @li RFC3279
- -- Algorithms and Identifiers for the Internet @ref X509 "X.509" @ref PKI Certificate and Certificate Revocation List
- (@ref CRL) Profile
- @li RFC3280
- -- Internet @ref X509 "X.509" @ref PKI Certificate and Certificate Revocation List (@ref CRL) Profile.
- |
-
-| @anchor cross_certificate Cross Certificate |
- A @ref certificate issued by a @ref CA which certificates another @ref CA's @ref root_certificate "root certificate". This is way of uniting two distinct
- certification hierarchies. |
-
-
-
-
\n @anchor D \n
-
-| D | |
-
-| @anchor decryption Decryption |
- The process of turning encrypted data (called @ref ciphertext) into the original information (called
- @ref plaintext) using a cryptographic algorithm parameterised with a key. |
-
-| @anchor DER DER |
- Distinguished Encoding Rules -- A set of rules for encoding @ref ASN "ASN.1" data structures as a byte stream, which
- has the property that any given @ref ASN "ASN.1" data structure will always encode to the same byte stream. DER is a
- subset of @ref BER. (Also of interest:
- A Layman's Guide to a Subset of ASN.1, BER, and DER.)
- |
-
-| @anchor DES DES |
- Data Encryption Standard -- A symmetric @ref block_cipher "block cipher" (that is the U.S. and international standard) used for
- @ref encryption and @ref decryption. A 64-bit block cipher with a 56-bit key organized as 16 rounds of operations. |
-
-| @anchor digital_signature Digital Signature |
- A structure linking some data and a @ref private_key "private key". A digital signature may be generated by the application of a
- private key to some piece of data. The original data may be reconstructed by applying the corresponding @ref public_key "public key",
- demonstrating that the signature could only have been generated by someone with access to the private key.\n\n
- Digital signatures have two primary uses: to demonstrate someone's identity by signing some challenge, as in
- @ref client_authentication "client authentication" in @ref TLS, in which the client signs a @ref hash of the messages that have been exchanged;
- and more strongly, for someone to demonstrate their acceptance of some human-processable information (e.g.
- 'Please withdraw £10,000 from my bank account') as in the @ref WMLScript Crypto API SignText function.\n\n
- See: an introduction to @ref Security_signatures. |
-
-| @anchor DN DN |
- Distinguished Name -- An @ref ASN "ASN.1" structure containing various attributes (name-value pairs) that together
- uniquely identify the entity for certification purposes. \n\n
- The name used in @ref X509_certificate "X.509 certificates" is the X.500 Distinguished Name, which describes a path
- through an X.500 Directory Information Tree. Conventionally, a DN comprises at least three attributes: a user's
- name/ID (e.g., \c cn=Fred \c Bloggs), an organization name (e.g., \c o=Symbian \c UK \c Ltd), and a country designation
- (e.g., \c c=GB ).
- |
-
-| @anchor DSA DSA |
- Digital Signature Algorithm -- A NIST-approved @ref asymmetric algorithm. It can only be used for generating
- and verifying @ref digital_signature "digital signatures", not for @ref encryption.
- See: The Digital Signature Standard.
- |
-
-
-
-
\n @anchor E \n
-
-| E | |
-
-| @anchor ECB ECB |
- Electronic Codebook -- A cryptographic mode for @ref block_cipher "block ciphers". It is a mode that encrypts
- blocks of @ref plaintext to corresponding blocks of @ref ciphertext. Given use of the same key, a block of plaintext
- will always encrypt to the same block of ciphertext. |
-
-| @anchor ECC ECC |
- Elliptical Curve Cryptography -- An @ref asymmetric @ref encryption technique based on elliptic curve theory that
- can be used to create faster, smaller, and more efficient cryptographic keys. |
-
-| @anchor encryption Encryption |
- The process of turning meaningful data (called @ref plaintext) into meaningless gibberish (called @ref ciphertext)
- using a cryptographic algorithm parameterised with a key. |
-
-| @anchor EE EE |
- End Entity -- A leaf node in a certification hierarchy: any entity in a @ref PKI which has a @ref certificate, but is
- not allowed to issue its own certificates. |
-
-
-
-
\n @anchor F \n
-
-| O | |
-
-| @anchor OAEP OAEP |
- Optimal Asymmetric Encryption Padding -- OAEP is a method for encoding messages, and addresses a potential
- vulnerability in PKCS#1. Padding means extra
- bits concatenated with a key, password, or @ref plaintext. @ref Padding helps against dictionary attacks. |
-
-| @anchor OCSP OCSP |
- @ref X509 "X.509" Internet Public Key Infrastructure Online Certificate Status Protocol -- A simple request/response
- protocol. To establish whether a given @ref certificate or list of certificates has/have been revoked, a client forms an
- OCSP request and sends this to an OCSP server. The server maintains revocation information in the form of, say,
- Certificate Revocation Lists (@ref CRL "CRL"s). The server replies to the client with a signed OCSP response, stating for
- each certificate whether the status is Good, Revoked, or Unknown. This response in turn is checked to ensure that it
- is valid, and that it is from an entity trusted for performing revocation checking.
- See:
- @li RFC2560
- -- @ref X509 "X.509" Internet @ref PKI Online Certificate Status Protocol - OCSP
- @li @ref overview_OCSP overview. |
-
-| @anchor OID OID |
- Object Identifier -- A universal constant uniquely associated with an object type used in @ref ASN "ASN.1". |
-
-| @anchor OS OS Element |
- A discrete, identifiable entity within a ROM file that implements a set of interfaces. Examples of
- OS Elements include independently instantiable classes within DLLs, bitmaps within an MBM file, resource
- entries within a resource file. An OS Element identifies a part of a ROM file that could in principle be
- factored out or removed if it becomes architecturally advisable. |
-
-| @anchor out_of_band Out Of Band |
- A channel of communication that is distinct from the channel which we are using cryptography to try to secure,
- and which is secure on its own terms; that is, its security is not dependent on the cryptography we are using.
- A common example of an out of band channel is a motorcycle courier.
- |
-
-
-
\n @anchor P \n
-
-| P | |
-
-| @anchor Padding @anchor padding Padding |
- Extending the size of a block of @ref plaintext to, say, a 64-bit block by addition of a regular or random pattern.
- For example, for use with @ref ECB. See:
- @li @ref rsa_padding
- @li @ref symmetric_ciphers. |
-
-| @anchor PKCS PKCS |
- Public-Key Cryptography Standards. |
-
-| PKCS#10 |
- @ref PKI standard that describes how to construct @ref certificate requests. |
-
-| @anchor PKG PKG file |
- A text file that defines a @ref SIS file. The PKG file is passed to the MAKESIS tool to produce the
- @ref SIS file. |
-
-| @anchor PKI PKI |
- Public Key Infrastructure -- A way of modelling real-world trust relationships that enables users of
- @ref public_key_cryptography "public key cryptography" to have confidence in the ownership of the @ref public_key "public keys" they are using. A PKI consists of:
- @li a trusted third party (@ref TTP)
- @li an @ref out_of_band "out of band" means of distributing the @ref TTP's @ref public_key_certificate "public key certificate" to @ref relying_party "relying parties"
- @li a means of distributing other certificates to @ref relying_party "relying parties"
- @li arrangements for the @ref revocation and renewal of these certificates
- @li certificate management and validation software on the @ref relying_party "relying party's" computer
-
- The TTP uses its signing key pair to create certificates for other entities, which relying parties can use to
- authenticate these other entities.
-
- We can classify PKIs according to whether they are hierachical or flat. In hierachical PKIs, such as the one defined
- in the PKIX set of standards, there is a distinction between users of the PKI such as End Entities (@ref EE "EE"s) and
- @ref relying_party "relying parties", and entities responsible for issuing and distributing certificates such as @ref CA "CA"s and
- @ref RA "RA"s. In a flat PKI such as the @ref web_of_trust "web of trust" underpinning @ref PGP, there are no entities whose sole role is
- to issue certificates; instead users of the PKI certify each other. |
-
-| @anchor PKIX PKIX |
- Public-Key Infrastructure (X.509) -- A profile of @ref X509 "X.509" for the internet. See:
- @li @ref Certman_X509_Certificate_Validation
- @li RFC2459
- -- Internet X.509 Public Key Infrastructure Certificate and CRL Profile.) |
-
-| @anchor plaintext Plaintext |
- The output of an @ref decryption operation, or the input to a @ref encryption operation. |
-
-| @anchor PGP PGP |
- Pretty Good Privacy -- A very widely-used @ref encryption and digital signing program. |
-
-| @anchor private_key Private Key |
- In the context of @ref public_key_cryptography "public key cryptography", the private half of the key pair. |
-
-| @anchor public_key Public Key |
- In the context of @ref public_key_cryptography "public key cryptography", the public half of the key pair. |
-
-| @anchor public_key_certificate Public Key Certificate |
- A digitally signed structure including at least an identifier for an individual entity and a @ref public_key "public key", whose
- function is to bind the entity with the key. |
-
-| @anchor public_key_cryptography Public Key Cryptography |
- A common application of @ref asymmetric cryptography in which one half of the key pair is kept secrect
- (the @ref private_key "private key") and the other half is published (the @ref public_key "public key"). See:
- @li @ref asymmetric_cryptography
- @li @ref Security_intro_PKC. |
-
-
-
-
\n @anchor Q \n
-
-| R | |
-
-| @anchor RA Registration Authority |
- An organization responsible for registering new @ref certificate users in a @ref PKI, e.g. by gathering and verifying
- information which identifies the @ref certificate applicant. |
-
-| @anchor revocation Revocation |
- The term used for asserting that a @ref certificate is no longer valid: for example, because the @ref private_key "private key"
- associated with it has been compromised. |
-
-| @anchor relying_party Relying Party |
- An entity who relies on the authenticity of a @ref public_key "public key". |
-
-| @anchor root_certificate Root Certificate |
- The @ref certificate of a @ref TTP "trusted third party". A certificate directly trusted by a @ref relying_party "relying party"
- that is, trust in it is not established by cryptographic means, but trust in it is the prerequisite for establishing
- trust in the entity which the relying party is trying to authenticate. Trust in a root certificate must be established
- through @ref out_of_band "out of band" means. A root certificate may or may not be self signed.\n\n
- See: @ref certman_certstore_root_cert_management. |
-
-| @anchor RSA RSA |
- A @ref public_key "public key" algorithm used for both @ref encryption and @ref digital_signature "digital signatures", named after its creators:
- Rivest, Shamir, and Adleman. |
-
-
-
\n @anchor S \n
-
-| S | |
-
-| @anchor secrecy Secrecy |
- This means that access to information is controlled: for example, it means that two entities (e.g. people,
- machines, processes) are able to communicate with one another without any other entities being able to access the
- information communicated, or that an entity may store some information and be assured that only this entity will be
- able to access it. |
-
-| @anchor SHA SHA-1 |
- Secure Hash Algorithm 1 -- A widely used @ref hash algorithm, producing a 160-bit digest. |
-
-| @anchor server_authentication Server Authentication |
- In a secure client-server protocol such as @ref TLS, the process in which the server authenticates itself to the
- client, so the client knows to whom it's talking. \n See: @ref WTLS_server_authentication "Server authentication in WTLS". |
-
-| @anchor SignText SignText |
- A function defined in the @ref WMLScript Crypto API that provides application-level @ref authentication and
- @ref nonrepudiation "non-repudiation" for transactions. |
-
-
-| @anchor SIS SIS file |
- A binary package file containing all the files for an installation, as well as metadata describing which
- directory to install them into, dependencies, etc..\n
- See: @ref overview_SWI overview. |
-
-| @anchor Stub SIS Stub file |
- A @ref SIS file containing only the metadata, and not the files. After the installation, this file is archived
- on the device for uninstallation purposes, etc.. |
-
-| @anchor SMIME S/MIME |
- Secure/Multipurpose Internet Mail Extensions
- -- Provides a consistent way to send and receive secure MIME data. S/MIME provides the following cryptographic
- security services for electronic messaging applications: @ref authentication, message integrity and @ref nonrepudiation "non-repudiation" of
- origin (using @ref digital_signature "digital signatures") and privacy and data security (using @ref encryption); see
- RFC2633 -- S/MIME Version 3 Message Specification.
- |
-
-| @anchor SSL SSL |
- Secure Sockets Layer -- A protocol for securing network connections that provides @ref authentication, @ref encryption, and
- data integrity using @ref PKI "Public Key Infrastructure" (PKI). Precursor to @ref TLS. SSL has been through three versions:
- the first two are considered insecure, and the third is almost identical to @ref TLS. |
-
-| @anchor stream_cipher Stream Cipher |
- A class of symmetric algorithm that is initialised with a key, then outputs a stream of pseudorandom bits.
- This 'keystream' is typically XOR-ed with the @ref plaintext to generate the @ref ciphertext. So they encrypt a bit of
- plaintext at a time. |
-
-| @anchor symmetric_cryptography Symmetric Cryptography |
- A form of cryptography in which the same key is used for @ref encryption and @ref decryption.\n\n
- Symmetric cryptography is fast, but suffers from the problem of how to distribute the key privately. @ref Asymmetric
- cryptography is an attempt to alleviate the key distribution problem, by reducing the requirement for the distributed
- key from one of privacy to one of @ref authentication. See:
- @li @ref symmetric_ciphers
- @li @ref SS_Cryptalg_symmetric_ciphers. |
-
-
-
\n @anchor T \n
-
-| T | |
-
-| @anchor TLS TLS |
- Transport Layer Security -- A protocol that provides communications secrecy, and optionally @ref authentication,
- over the Internet TCP/IP. The protocol allows client/server applications to communicate in a way that is designed to
- prevent eavesdropping, tampering, or message forgery.
-
- In this protocol a client connects to a server; the two then perform a handshake in which they exchange a
- symmetric key by using @ref asymmetric cryptography, which is then used to encrypt their communications,
- providing the @ref secrecy element. Without the @ref authentication element, @ref secrecy is not very useful; although
- only client and server can understand the data exchanged, the client doesn't know who the server is or vice versa. TLS
- provides the capability for @ref WTLS_server_authentication "server authentication", in which the client establishes who the server is, and
- @ref client_authentication "client authentication" in which the server establishes who the client is. \n\n
- See: RFC2246 --
- The TLS Protocol). TLS is the successor to the @ref SSL "Secure Sockets Layer" (SSL). (Also, see: @ref WTLS.) |
-
-| @anchor TTP TTP |
- Trusted Third Party -- An entity whose @ref public_key "public key" is known to a @ref relying_party "relying party" due to its having been received
- via @ref out_of_band "out of band" means, and which is trusted to issue @ref public_key_certificate "public key certificates" for other entities not directly
- known to the relying party. A @ref CA is a type of TTP. |
-
-
-
\n @anchor U \n
-
-| W | |
-
-| @anchor WAP WAP |
- | Wireless Application Protocol -- A secure specification
- that enables users to access information instantly using devices such as mobile phones, pagers, two-way radios,
- smartphones and communicators. The WAP defines a set of protocols in transport, security, transaction, session, and
- application layers to enable the creation of advanced mobile services.
-
-| @anchor web_of_trust Web of Trust |
- The set of social relationships between users of @ref PGP that enables them to sign each others' keys, essentially
- providing a @ref PKI for this technology. |
-
-| @anchor WIM WIM |
- Wireless Identity Module
- -- Used in performing @ref WTLS and application level security functions, and especially, to store and process
- information needed for user identification and @ref authentication. Examples of WIM implementations are a Subscriber
- Identity Module (SIM) card or an external smart card. |
-
-| @anchor WMLScript WMLScript Crypto API |
- A @ref WAP Forum standard that defines cryptographic functions in WML, the scripting language used in @ref WAP.
- It defines a function for creating signed objects called @ref SignText. |
-
-| @anchor WTLS WTLS |
- Wireless Transport Layer Security
- -- The security layer of the @ref WAP, providing privacy, data integrity and @ref authentication for WAP services.
- It is a @ref WAP variant of @ref TLS and defines its own lightweight @ref certificate format. \n\n
- See: @ref overview_WTLS overview. |
-
-| @anchor WTLS_certificate WTLS certificate |
- @ref WAP variant of @ref X509_certificate "X.509 certificates".\n\n
- See: @ref overview_WTLS overview. |
-
-
-
\n @anchor X \n