Symbian OS Platform Security/Appendix B: Some Cryptography Basics - Revision history

Craig: Correct publication year for PKI book 2nd edition

2011-01-20T14:20:54Z

Correct publication year for PKI book 2nd edition

Craig: removed category, added copyright template

2011-01-17T11:56:55Z

removed category, added copyright template

Craig: added backup link

2010-12-20T21:54:45Z

added backup link

Craig: /* How Signing Works */ updated URL for RSA Labs

2010-12-20T21:51:47Z

‎How Signing Works: updated URL for RSA Labs

Craig: formatting

2010-12-20T21:49:24Z

formatting

Admin: 2 revisions: import from developer.symbian.org

2010-12-18T16:04:14Z

2 revisions: import from developer.symbian.org

Satudahl at 11:47, 23 March 2010

2010-03-23T11:47:10Z

Satudahl: Created page with 'For additional background reading, we recommend Applied Cryptography by Bruce Schneier [Schneier 1996] and Understanding PKI by Carlisle Adams and Steve Lloyd [Adams and Lloyd 19...'

2010-03-23T11:38:28Z

Created page with 'For additional background reading, we recommend Applied Cryptography by Bruce Schneier [Schneier 1996] and Understanding PKI by Carlisle Adams and Steve Lloyd [Adams and Lloyd 19...'

New page

For additional background reading, we recommend Applied Cryptography
by Bruce Schneier [Schneier 1996] and Understanding PKI by
Carlisle Adams and Steve Lloyd [Adams and Lloyd 1999].

=Asymmetric Key Pairs=
Unlike symmetric cryptography, where the same key is employed to
decrypt data as was used to encrypt it, asymmetric cryptography is based
on a related pair of keys. You can then use one key to encrypt the
data, and the other to decrypt it – and vice versa. The generally followed
scheme is for you to publish one key (referred to as a public key) and
keep the other key (the private key) secret. This means that the following
mechanisms can be used:

1. Using your public key, I can encrypt data, safe in the knowledge that
only you can decrypt it.
2. Using my private key, I can encrypt data that anyone can decrypt
using my public key.

Mechanism 2 doesn’t sound too useful at first. However, if the data does
decrypt correctly (and you’ll need to recognize this – perhaps by seeing
readable text) then you’ll know that I (and nobody else) encrypted it.
Hard-core cryptographers will argue over the rather general statements
made above, and quite rightly point out that everything depends on the
fact that private keys remain private and public keys are always correctly
associated with the correct owner. Also, as time goes on, technological
advances in cryptanalysis and mathematical wizardry mean that mechanisms
1 and 2 above become less reliable – which is why cryptography
continuously evolves as well (e.g. by employing increasingly larger key
sizes).

=The Cryptographic Hash=
A hash function takes some variable-length input data and produces a
fixed-length output, which is usually called the hash or message digest.
The idea here is that it’s extremely costly or time-consuming to find – or
concoct – another input that produces the same hash value. It should also
be effectively impossible to determine anything about the original input
from the hash output.

=How Signing Works=
Signing a piece of data is a two-step process. First I calculate the hash of
the data I wish to sign. Second, I encrypt the hash with the private key
from my own asymmetric key pair. I can then send, post, or publish this
data and signature. (Note that the data itself is not encrypted – only the
hash.)

You, the recipient, by using my public key, are able to decrypt the
hash and also run the same hash operation yourself to confirm that you
come up with the same hash value. If the hash values match, then you
can be reasonably sure (within cryptographic guarantees) that:
*The data hasn’t been tampered with.
*I constructed the data and I am the source.

There are things you are going to need to know to ‘verify’ the signature,
and I didn’t draw attention to them in the paragraph above. The first is the
ability to identify or obtain my public key (as opposed to anyone else’s).
As I said earlier, this can be a little tricky to resolve. The second is the
hash algorithm I used to calculate the hash (of which there are quite a
few), and the third is the encryption algorithm, which I used to encrypt
the hash. Standards exist which specify how these things go together to
form a signature (for example, see the PKCS#7 and other related standards
at http://www.rsasecurity.com/rsalabs).

=The Digital Certificate=
The digital certificate is an amalgamation of a number of useful things into
a signed data container. The two key pieces of information present are:
*a public key
*Some information which can help to identify the owner or subject. Inparticular, this information should help differentiate the owner from others, and give you some idea that the public key belongs to that person and that the data therein matches your knowledge of the real person (name, country, company, e-mail address, etc.). Other information is present too – in particular a date validity period and information about who issued (and signed) the certificate.

← Older revision		Revision as of 11:56, 17 January 2011
Line 72:		Line 72:
	Other information is present too – in particular a date validity period and information about who issued (and signed) the certificate.		Other information is present too – in particular a date validity period and information about who issued (and signed) the certificate.

−	~~[[Category: Book]]~~	+	{{SymbianOSPlatformSecurity_Copyright}}

← Older revision		Revision as of 21:54, 20 December 2010
Line 1:		Line 1:
−	Reproduced by kind permission of John Wiley & Sons.	+	{\| width="100%"
		+	\|-
		+	\|Reproduced by kind permission of John Wiley & Sons.\|\|align="right"\|[[Symbian OS Platform Security\|Table of Contents]]
		+	\|}

	For additional background reading, we recommend Applied Cryptography		For additional background reading, we recommend Applied Cryptography

@@ Line 6: / Line 6: @@
 For additional background reading, we recommend Applied Cryptography
 by Bruce Schneier [Schneier 1996] and Understanding PKI by
-Carlisle Adams and Steve Lloyd [Adams and Lloyd 1999].
+Carlisle Adams and Steve Lloyd [Adams and Lloyd 2003].
 =Asymmetric Key Pairs=

@@ Line 60: / Line 60: @@
 the hash. Standards exist which specify how these things go together to
 form a signature (for example, see the PKCS#7 and other related standards
-at http://www.rsasecurity.com/rsalabs).
+at http://www.rsa.com/rsalabs/).
 =The Digital Certificate=

@@ Line 14: / Line 14: @@
 mechanisms can be used:
-. Using your public key, I can encrypt data, safe in the knowledge that
+# Using ''your'' public key, I can encrypt data, safe in the knowledge that only you can decrypt it.
-only you can decrypt it.
+# Using ''my'' private key, I can encrypt data that anyone can decrypt using my public key.
-. Using my private key, I can encrypt data that anyone can decrypt
 using my public key.
 Mechanism 2 doesn’t sound too useful at first. However, if the data does
 decrypt correctly (and you’ll need to recognize this – perhaps by seeing
 readable text) then you’ll know that I (and nobody else) encrypted it.
 Hard-core cryptographers will argue over the rather general statements
 made above, and quite rightly point out that everything depends on the
@@ Line 33: / Line 32: @@
 =The Cryptographic Hash=
 A hash function takes some variable-length input data and produces a
-fixed-length output, which is usually called the hash or message digest.
+fixed-length output, which is usually called the ''hash'' or ''message digest''.
 The idea here is that it’s extremely costly or time-consuming to find – or
 concoct – another input that produces the same hash value. It should also
@@ Line 47: / Line 46: @@
 You, the recipient, by using my public key, are able to decrypt the
-hash and also run the same hash operation yourself to confirm that you
+hash and '''also''' run the same hash operation yourself to confirm that you
 come up with the same hash value. If the hash values match, then you
 can be reasonably sure (within cryptographic guarantees) that:
@@ Line 67: / Line 66: @@
 a signed data container. The two key pieces of information present are:
 *a public key
-*Some information which can help to identify the owner or subject. Inparticular, this information should help differentiate the owner from others, and give you some idea that the public key belongs to that person and that the data therein matches your knowledge of the real person (name, country, company, e-mail address, etc.). Other information is present too – in particular a date validity period and information about who issued (and signed) the certificate.
+*Some information which can help to identify the owner or subject. In particular, this information should help differentiate the owner from others, and give you some idea that the public key belongs to that person and that the data therein matches your knowledge of the real person (name, country, company, e-mail address, etc.).
-[[Category: book]]
+[[Category: Book]]

← Older revision	Revision as of 16:04, 18 December 2010
(No difference)