Roger Clarke's Web-Site

 

© Xamax Consultancy Pty Ltd,  1995-2014


Roger Clarke's 'Cryptography in Plain Text'

Message Transmission Security
(or 'Cryptography in Plain Text')

Version of 11 May 1998

Roger Clarke

Principal, Xamax Consultancy Pty Ltd, Canberra

Earlier version published in Privacy Law & Policy Reporter 3, 2 (May 1996), pp. 24-27

© Xamax Consultancy Pty Ltd, 1996, 1997, 1998

Available under an AEShareNet Free for Education licence

This document is at http://www.rogerclarke.com/II/CryptoSecy.html


This document provides non-technical explanations of:

It was originally prepared as a breakout box to support a paper on 'Crypto-Confusion'.


The Risks Involved in Message Transmission

The term message transmission is used here to refer to the sending of a message from one person or organisation to another, over a communications link.

The risks involved in message transmission are identified in a supporting document. This document describes the ways in which those risks can be addressed, through the application of cryptography.


Requirements for Message Transmission Security

The requirements of a security regime which addresses these risks are conventionally summarised under four broad headings. For the sender and receiver to be confident in the outcome of their communications, all of these requirements need to be satisfied.

(1) 'Confidentiality', or Message Content Security

This comprises two separate requirements, that, during a message's transit from sender to receiver:

The term 'confidentiality' is used by computer scientists who specialise in security matters. This is most unfortunate, because the term has an entirely different meaning within commerce generally, which derives from the law of confidence. For this reason, the alternative term 'message content security' is used in this Module.

(2) Integrity of Message Content

This requires that the recipient can be sure that, whether accidentally, or because of an action by any party:

(3) Authentication of the Sender and Recipient

This requires that:

(4) Non-Repudiation by the Sender and Recipient

This requires that:


Cryptography

Introduction

Cryptography is an important element of any strategy to address message transmission security requirements. It is the practical art of converting messages or data into a different form, such that no-one can read them without having access to the 'key'. The message may be converted using a 'code' (in which case each character or group of characters is substituted by an alternative one), or a 'cypher' or 'cipher' (in which case the message as a whole is converted, rather than individual characters).

Cryptology is the science underlying cryptography. Cryptanalysis is the science of 'breaking' or 'cracking' encryption schemes, i.e. discovering the decryption key.

A 'strong encryption scheme' is one that cannot be cracked in a sufficiently short time that the security of the message is threatened, even using the most powerful computers available for the task.

With a 'weak encryption scheme', on the other hand, there is a significant risk that the key can be discovered by an organisation that has access to sufficient computing power. Discussions in this area generally relate to the computing power owned by the U.S. National Security Agency (NSA).

There are several aspects of a scheme that determine its strength. One of particular importance is the key-length needed to make it highly unlikely that a cracking attempt will be successful.

Cryptography comprises two distinct classes: symmetric and asymmetric.


Symmetric ('Secret Key') Cryptography

Symmetric cryptography involves a single, secret key, which both the message-sender and the message-recipient must have. It is used by the sender to encrypt the message, and by the recipient to decrypt it.

The NSA stated in the mid-1990s that a 40-bit length was acceptable to them (i.e. they can crack it sufficiently quickly). Increasing processor speeds, combined with loosely-coupled multi-processor configurations, are bringing the ability to crack such short keys within the reach of much less well-funded organisations. To be 'strong', the key-length therefore needs to be at least 56 bits in 1998, and it was argued by an expert group as early as 1996 that 90 bits is a more appropriate length.

Symmetric cryptography provides a means of satisfying the requirement of message content security, because the content cannot be read without the secret key. There remains a risk exposure, however, because neither party can be sure that the other party has not exposed the secret key to a third party (whether accidentally or intentionally).

Symmetric cryptography can also be used to address the integrity and authentication requirements. The sender creates a summary of the message, or 'message authentication code' (MAC), encrypts it with the secret key, and sends that with the message. The recipient then re-creates the MAC, decrypts the MAC that was sent, and compares the two. If they are identical, then the message that was received must have been identical with that which was sent.

A major difficulty with symmetric schemes is that the secret key has to be possessed by both parties, and hence has to be transmitted from whomever creates it to the other party. Moreover, if the key is compromised, all of the message transmission security measures are undermined. The steps taken to provide a secure mechanism for creating and passing on the secret key are referred to as 'key management'.

The technique does not adequately address the non-repudiation requirement, because both parties have the same secret key. Hence each is exposed to the risk of fraudulent falsification of a message by the other, and a claim by either party not to have sent a message is credible, because the other may have compromised the key.


Asymmetric ('Public Key') Cryptography

Whereas symmetric cryptography has existed, at least in primitive forms, for 2,000 years, asymmetric approaches were only invented in the mid-1970s.

Asymmetric cryptography involves two related keys, referred to as a 'key-pair', one of which only the owner knows (the 'private key') and the other which anyone can know (the 'public key').

The advantages of asymmetric cryptography are that:

To crack a mere 40- or 56-bit asymmetric key would be trivially simple, because there are far fewer sets of keys available (or, expressed more technically, the 'key-space' is relatively 'sparse'). It is currently conventional to regard a 1024-bit asymmetric key-length as being necessary to provide security.

Because of the much greater key-length, encryption and decryption require much more processing power, or, for a given processor, significantly more processing time. Messages are sent in large volumes; so the resulting delays are of considerable consequence.


Applied Public Key Cryptography

Public key cryptography can be applied as a means of addressing each of the requirements for message transmission security.

* Message Content Security ('Confidentiality')

The sender encrypts the message, not with their own key, but using the intended recipient's public key. The receiver decrypts using their private key.

This is a more secure approach than symmetric cryptography, because the decryption key need never be in the possession of anyone other than the owner. It is much slower, however, and hence symmetric cryptography is, at least at present, a more practicable means of protecting the contents of the message from prying 'eyes'.

* The Management of Secret Keys

Another way in which asymmetric cryptography can be used, is to underwrite the security of a symmetric encryption scheme.

This can be done by using it to support the secure transmission of a new secret key from the originator to the other party. Under this approach, the new secret key is encrypted using the recipient's public key, and then sent. Only the recipient has the recipient's private key, and hence only the recipient can decrypt the message and recover the new secret key.

* Integrity, Authentication and Non-Repudiation

The technique can be used to address all of the integrity, authentication and non-repudiation requirements. Because the technique is somewhat complex, it is explained below in a succession of steps.

Note that this process uses a different key-pair from that used for message transmission security. The key-pair used for message-security is owned by the recipient, whereas the key-pair used in this process is owned by the sender.

The sender appends to a message a special, agreed segment within the message. They encrypt this segment with their private key. The recipient decrypts this segment using the sender's public key. If the decrypted segment is identical to what the two parties had previously agreed, then the recipient can be sure that the message has been sent by the purported sender, and that the sender cannot credibly deny having sent it. Hence the authentication and non-repudiation requirements are satisfied.

This technique can be taken a step further, to address the integrity requirement as well. The additional segment is not pre-agreed. Instead, a 'message digest' is created, by processing the actual message using a special, pre-agreed algorithm (in a similar way to the MAC'ing process used in symmetric cryptography). The sender encrypts this message digest with their private key, to produce what is called a 'digital signature' (because it performs much the same function as a written signature, although it is much harder to forge).

The recipient re-creates the message digest from the message that they receive, uses the sender's public key to decrypt the digital signature that they received appended to the message itself, and compares the two results. If they are identical, then:

* Would You Like That Run Past You Again?

Rest assured that most people do not grasp those ideas the first time that they read them.

Here is a second description of the process whereby all message transmission security risks can be addressed through the application of public key cryptography.

It involves:

The process is as follows:

Sender Actions Before Sending:

Message-in-Clear-Text * Hash-Function => Hash-Value

Hash-Value * Sender's-DigSig-Private-Key => Signature

Message-in-Clear-Text || Signature => Signed-Text

Signed-Text * Receiver's-Encryption-Public-Key => Encrypted-Signed-Text

Receiver Actions After Receiving:

Encrypted-Signed-Text / Receiver's-Encryption-Private-Key => Message-in-Clear-Text || Signature

Message-in-Clear-Text * Hash-Function => Hash-Value

Signature / Sender's-DigSig-Public-Key => Hash-Value

Receiver Actions in Order to Test the Security of the Message Transmission:

IFF The Two Hash-Values Match

THEN Message Content Security is assured

AND Message Integrity is assured

AND Message Authentication is assured

AND Message Non-Repudiability is assured

ELSE

Something's Rotten in the State of Denmark


Contemporary Message Transmission Security

In the late 1990s, the conventional approach to protecting the security of messages during transmission applies a hybrid of symmetric and asymmetric cryptography. Message content security is achieved using a secret key, with key management performed using an asymmetric key-pair. Integrity, authentication and non-repudiation are achieved using a separate asymmetric key-pair.


An Example Application - SET

This section provides a brief overview of a particular application of encryption technology.

* Introduction

The purpose of the Secure Electronic Transactions (SET) specification is to provide a means whereby credit-card details can be used over an open network such as the Internet, with a far higher level of fraud-prevention than is available with manual (flick-flack) machines, and even data-capture at point-of-sale.

SET is an "open, vendor-neutral, non-proprietary, license-free specification for securing on-line transactions". It leverages off the existing payment-card infrastructure and card-base. It is a collaborative initiative, spear-headed by Visa and MasterCard, but including other important players such as Microsoft and Netscape.

The scheme involves the use of digital signatures based on public key encryption, as a means of authenticating all participants in a card-based payment transaction.

The operation of SET depends on software that implements a series of protocols being installed in the workstations or servers of four kinds of people and organisations.

These are:

The simplified representation that follows describes the two key elements:

* The Establishment of the Framework

Each of the participants has to create a key-pair, store the private key in a secure manner, and make the public key available to organisations that seek it.

SET envisages a hierarchy of certification authorities (CAs), independent from other CA hierarchies. These are:

A cardholder will (quite probably unconsciously) acquire a certificate from the CA of their card-issuer, a copy of which they can provide whenever they make a purchase. Each card-issuer will acquire a certificate from the CA of each payment-processing organisation that they use. Each payment-processing organisation will acquire a certificate from the root CA.

* The Conduct of a Payment Transaction

To effect a transaction, a card-holder invokes software on their workstation that initiates the following sequence:

* Progress

Since it was announced with much fanfare in 1996, progress in implementing SET has been slow. This is because the scheme is complex, and depends on many participants conforming with the specification.

A particular concern is that the scheme contains nothing that manages participants' private keys. It appears that these will need to be stored on participants' workstations and servers, or on additional peripherals installed on workstations and servers to handle a secure token (probably a chip-card).


Infrastructure for Digital Signatures

Two conditions need to be satisfied, in order that public-key digital signatures can satisfy message transmission security needs:

(a) Security Measures for the Private Key

For a digital signature to be of high quality (i.e. not readily subject to spoofing and repudiation), it needs to be generated using a 'private key' which is held under highly secure conditions by the person concerned.

A private key is long. For example, here is one person's public encryption key, stored at http://sof.mit.edu/rdl/pgp.txt.

Key for user ID: Ryan Lackey (rdl@mit.edu)

2048-bit key, Key ID 44518EBD, created 1996/11/01

-----BEGIN PGP PUBLIC KEY BLOCK-----

Version: 2.6.2

mQENAzJ5cP4AAAEIAMXQAjSvH2FYCEHd3qtO7Bo7X5BoqEtqCOmQZrOooUvfR

0s9A1p7VJQVqLbF/RkB1V6+t8q/n9ZmJT8zaopHPV2JsChN3ayRCj5C/T4Lbi

qIVxvVTnQL5TXvKwPfbZsJfbnSYi9RaROCOeAn9Mv+AS1zS1NU/NKtMhJDizK

QvWRwh/MdyJMY1ZmFjFSggwenQ/WiKH94Xw62GYIDSfxRxCib0zVdB8hRikNx

llwNaCjGgaeLX26ZNwTjxn6ZKs1ljrsA/JUntPeaxiOKfWT6zgYfItT6SR4CQ

Xh9nOp1K7VNawC8R+Yrapj+ORumDLU32oL3UjXKi1s0rB5/G0RRjr0ABRG0GV

J5YW4gTGFja2V5IDxyZGxAbWl0LmVkdT6JARUDBRAymNumX4Igt7GJo1EBAb/

KB/42bs+cQAmplbSzFyEPMvpTTHDxdBVvxBwejzotPjflQoroXKeIel8q9nB2

b/XcmU50GCMM8OC+SZ5tbB++IvHi0lfa8ciAD1tcktJdsRNsIYc42cg6lqAks

hvD+jduPppdB0gyEuvqhZ2Q0Ck2m7intPLn5vLN+dks0PkTK07Q3ToOSTydin

wsImmLJ5ILffUExGVfiUAjJH0rdaLyAmZvAtgh6lKCJ9Q90aWic5bljP0+4Dk

0AHBfDXS/RoZopoWQxCwx4GTu8vjZCqy4hjTizqab6uc4/PRoZARw1pFWbJ5G

eUMdOn35sOj6G2l8RAaO9KogawHe26TxWKNPSADXiQEVAwUQMnlx56wefxtEU

Y69AQE0JQf/c3gDthbvXAY5IpPnqhU7Sgi9rCivD7a8E0In8ZRnZ/qkvkCkJF

hnkC1zHapW3XQrNAC20M5pmatIB3+67eERDFsyNo7gXbg7v0GhWX/4XBa47Ei

hKMlxAsvFkV2MrlRrYX1A9iMna+SmYp3QuUlNdZhEuBngIb8InkC9hkLR5YJk

RaalQ3dKW/NqHeNt5GElO9oVfxFELC9a9YL7uwa8EbAXsAEpEtUGuujS/xeZQ

OAt+7+F9SXIGE4dCbI7c7wwEKRNX8If7hedbNLTyvNs4gw2pt249tTZ/9243H

v0dCYoakZjrOUcD+9ImNbrsAfD22aiBHqOfZutzAlC29iPUQ===VoV0

-----END PGP PUBLIC KEY BLOCK-----

Quite clearly, it is impractical for a private key to be memorised in the way that passwords and PINs are meant to be memorised. An appropriate device to support secure storage of a private key is a chip, and the most practical carrier for such a chip at present is a smart-card.

Access to the private key stored on a chip needs to be protected in some manner, such that only the owner can use it. One approach is to protect it with a PIN or password; but this provides only a moderate level of security.

An emergent approach is for the card itself to refuse access to the private key, except when the card measures some aspect of the holder's physical person, and is satisfied that it corresponds sufficiently closely (using 'fuzzy matching') to the measure pre-stored in the card. Examples of such 'biometrics' include the patterns formed by rods and cones on the retina, and the geometry of the thumb.

A significant difficulty that has to be addressed, however, is that, because a business entity cannot itself act, it is dependent on the actions of one or more humans acting on its behalf. In addition to the security measures needed in respect of a person's own digital signature, further measures are needed, in order to reduce the likelihood of error or fraud by one or more persons, involving misapplication of the business entity's private key.

(b) (National) Public Key Infrastructure ((N)PKI)

During the mid-to-late 1990s, the emergent PKI has been the subject of feverish efforts in the United States, with initiatives in the technical, organisational and legal arenas (e.g. Utah 1995).

In Australia, efforts by a Standards Australia committee (PKAF 1996) and subsequently by a committee convened by the Commonwealth Minister for Communications and the Arts (NPKI 1998) have resulted in measures being proposed to ensure that an appropriate public key infrastructure is put into place. The matter has also been addressed from the perspective of the interests of Commonwealth Government agencies ( OGIT 1998). At least one organisation is ready to offer public certification authority (CA) services, as soon as that infrastructure is in place (Australia Post, with its KeyPost service).

The work of developing technical standards for the Australian PKAF is being undertaken by the Standards Australia IT/12/4/1 Committee.

Further concerns are that the law as it presently stands may not recognise digital signatures as being the equivalent of (or better than) a written signature. A United Nations Model Law on Electronic Commerce ( UNCITRAL 1996) recommends an approach for addressing such problems. In March 1998, an Electronic Commerce Expert Group working in conjunction with the Commonwealth Attorney-General's Department, produced a report which recommended modifications to the law to ensure that digital signatures are accepted in law as evidence that a person originated a message ( ECEG 1998).

Another problem that may undermine the intended PKI is a lack of clarity about the liabilities of CAs, or a degree of risk exposure that makes the business of being a CA too unattractive. Various proposals have been made as to how to ensure that the business of a CA is tenable, including the American Bar Association (ABA 1995) and the United Nations ( UNCITRAL 1998) at Articles 11 and 12. Laws defining the extent of liability have been passed in some jurisdictions, e.g. the State of Utah as long ago as 1995.


Issues in Public Key Cryptography

Public key cryptography is relatively new and technically complex. It raises many public policy issues.

(a) The Generation of Pairs of Private and Public Keys

Because of the nature of the mathematics underlying asymmetric cryptography, the pairs of keys are created as part of a single process. Three main choices exist as to who performs key-generation:

This choice of who generates key-pairs is one of the issues at the heart of the cryptography debates of the last few years ( Clarke 1996).

(b) Secure Deposit of Private Keys

If a person or organisation loses their private key, they are unable to:

If the private key is stored only on a person's workstation or chip, it is vulnerable to theft, loss, damage and malfunction of that device. In order to address those risks, it is strongly advisable that every private key be placed into deposit in some location separate from that person's normal workstation. Because of the risks involved if the private key comes to be known by some other person, the deposit needs to be subject to an appropriately high set of security standards.

(c) Escrow of Private Keys

'Escrow' is an arrangement whereby something is placed on deposit with a trusted party, but may be accessed by third parties under certain conditions. It was originally used for title deeds for real property, and is used for source-code for software packages.

Escrow can also be used for private keys, in which case it is referred to as 'private key escrow', which is commonly shortened to 'key escrow'.

There are a number of conditions under which individuals or organisations may have a legitimate interest in gaining access to the private keys of other parties. These include:

If, however, security is to be sustained (and, indeed, if privacy is to be protected), any access to escrowed keys would need to be subject to very careful designed and implemented controls, e.g. a prior requirement of legal authority (such as a search warrant), granted by a senior member of the judiciary.

If key escrow is implemented, it might be:

and the function might be performed by:

The question as to whether private key escrow should be implemented, and if so how, lie at the heart of the cryptography debates of the last few years ( Clarke 1996). It is important that the distinction be appreciated between secure deposit (for the benefit of the key-owner) and key escrow (for the benefit of a third party). This has become confused during the public debates.

(d) Access to, and Certification of, Public Keys

Asymmetric schemes depend on the public keys of people and organisations being publicly available. The most practicable methods of achieving this are:

Either of these approaches is subject to 'spoofing', i.e. an imposter can send a message which includes a public key, or store a public key in a directory, and thereby fool the other party into thinking the message came from a particular person or organisation.

To address this risk, the concepts have been created of:

If a party to a message-exchange wishes to acquire the public key of the other party, or to check that the public key they already have for the other party is valid and up-to-date, they can use that party's identity to look up a certificate in a directory, and receive back a message containing that person's or organisation's public key. The message is signed and encrypted by the certification authority using its own private key, and the recipient decrypts it using the certification authority's public key.

In order to reduce the amount of network traffic involved, and hence the elapsed time of a transaction, it is feasible for certificates to be provided by the sender (in a manner analogous to a letter applying for a job being accompanied by a set of letters from referees attesting to the applicant's identity and good character).

An international standard for certificates of this kind has existed for several years, documented within the CCITT standard X.509. Services of this nature are being offered in the United States. In Australia, Telstra operates such a scheme for its own use and that of one or two major clients, and Australia Post has launched a scheme called KeyPost, which it intends to make generally available.

(e) Multi-Function Certification Authorities

The preceding paragraphs have endeavoured to present the complete set of concepts in a logical sequence of development. Unfortunately, the separation of ideas and functions has been considerably muddied in practice.

In particular, many of the proposals for public-key certification / authentication frameworks and certification authorities, including the Australian Standards document MP75 (PKAF 1996), envisage the authorities performing multiple functions, including:

Whether an organisation that performs the third and fourth functions should also perform the first and/or second functions is central to the current arguments between crypto-anarchists and crypto-authoritarians ( Clarke 1996).

(f) Digital Signatures and Privacy

A PKI could have potentially grave impacts on privacy, depending on how it is implemented. Greenleaf and Clarke ( 1997) identify and examine the following impacts of digital signature technology on privacy:

A position statement on PKI at Clarke ( 1998):

A further issue is that some government agencies and some corporations are running a 'technological imperative' agenda in an effort to convert anonymous transactions into identified transactions. The privacy interest runs emphatically counter to attempts to convert anonymous into identified transactions.

The cluster of tensions that has arisen between those who believe in the need for strong control of society by nation-states and those who value individual freedoms much more highly has reached serious proportions, and could get much worse. Cryptography in general, and the strategies adopted in relation to public key infrastructure in particular, are at the centre of these debates. A depiction of the contrary positions of 'crypto-anarchists' and 'crypto-authoritarians' is at Clarke (1996).

(g) Other Issues

Cryptography has broader implications, which may extend to consumers, corporations, the workplace, the courts, crime prevention, regulatory agencies, and the effectiveness of taxation.

The following analyses are relevant:


The Need For a Comprehensive Security Regime

This document deals with only one particular aspect of security, that which relates to message transmission. Message transmission security needs to be established within the context of a complete protection regime comprising a comprehensive set of measures, dealing with:

Protections cost money and time; and in many circumstances people and organisations accept relatively low levels of confidence in return for lower cost or higher speed. In particular, different levels of security regime quality are likely to be applied to defence communications, funds transfers, normal business communications, and social communications.


A Short Bibliography

Biddle B. (1996) 'Digital Signature Legislation: Some Reasons for Concern' Privacy Right Clearinghouse, April 1996

Burns E. & Christofis I. (1995) 'Certification of Public Keys: Your Electronic Credentials' EDICAST 26 (October/November 1995), pp.6-8, and at http://www.pa.gov.au/eco/edicast/edic26/ec26.htm#11

Chaum D. (1995) 'Digital Signatures and Smart Cards', Digicash bv, Amsterdam, October 1995, at http://www.digicash.com/publish/digsig/digbig.html

Clarke R. (1997) 'The Monster from the Crypt: Impacts and Effects of Digital Money' Proc. Computers, Freedom & Privacy Conference (CFP'97), San Francisco, 12-14 March 1997, at http://www.rogerclarke.com/EC/Monster.html

Clarke R. (1998) 'Public Key Infrastructure: Position Statement', at http://www.rogerclarke.com/DV/PKIPosn.html

Clarke R., Dempsey G., Ooi C.N. & O'Connor R.F. (1998a) 'Technological Aspects of Internet Crime Prevention' Proc. Conf. 'Internet Crime', Melbourne University, 16-17 February 1998, at http://www.rogerclarke.com/II/ICrimPrev.html

Clarke R., Dempsey G., Ooi C.N. & O'Connor R.F. (1998b) 'The Technical Feasibility of Regulating Gambling on the Internet', Conference on 'Gambling, Technology & Society: Regulatory Challenges for the 21st Century', Rex Hotel Sydney, Potts Point, 7 - 8 May 1998 , at http://www.rogerclarke.com/II/IGambReg.html

ECEG (1998) 'Electronic Commerce: Building The Legal Framework', Electronic Commerce Expert Group, Commonwealth Attorney-General's Department, 31 March 1998 at http://law.gov.au/aghome/advisory/eceg/

EPIC 'Cryptography Policy', at http://www.epic.org/alert/

Garfinkel S. (1995) 'PGP: Pretty Good Privacy' O'Reilly & Associates, 1995, esp. Chapters 2-6 and the Glossary

Grant G.L. (1997) 'Understanding Digital Signatures: Establishing Trust over the Internet and Other Networks' McGraw-Hill, 1997

Greenleaf G.W. & Clarke R. (1997) 'Privacy Implications of Digital Signatures' Proc. IBC Conf. on Digital Signatures, Sydney, 12 March 1997, at http://www.rogerclarke.com/DV/DigSig.html

Litterio F. (1995) 'Cryptography: The Study of Encryption', at: http://world.std.com/~franl/crypto/

Netscape (1996) 'Netscape Policy on Encryption Export', at http://www.netscape.com/newsref/ref/encryption_export.html

NPKI (1998) 'National Public Key Infrastructure Report', National Office of the Information Economy, March 1998, at http://www.noie.gov.au/

OGIT (1998) 'Project Gatekeeper: Implementation of Public Key Technology by Commonwealth Agencies' Office of Government Information Technology, March 1998, via http://www.ogit.gov.au/gatekeeper/index.html

OTA (1995) 'Issue Update on Information Security and Privacy in Network Environments', Chapter 2: Overview Of The 1994 OTA Report On Information Security And Privacy, June 1995, at: ftp://otabbs.ota.gov/pub/infosec.update/07ch2.txt and ftp://otabbs.ota.gov/pub/pdf/infosec.update

and mirrored at:

http://www.rogerclarke.com/II/07ch2.txt and http://www.rogerclarke.com/II/03ch2.pdf

(Note: The Office of Technology Assessment regrettably closed its doors in September 1995, when Congress withdrew its funding. Its pages live on for the time being, but are at imminent risk of disappearing; hence the mirroring of this particularly valuable description of the technology and identification of the 'key' issues).

PKAF (1996) 'Strategies for the Implementation of a Public Key Authentication Framework (PKAF) in Australia' Standards Australia, MP75, 1996

RSA (1995) 'RSA's Frequently Asked Questions About Today's Cryptography', at: http://www.rsa.com/rsalabs/faq/faq_gnrl.html

SA (1996) 'Strategies for the Implementation of a Public Key Authentication Framework in Australia' Standards Australia, DR96078, April 1996

Schneier B. (1996) 'Applied Cryptography' Wiley, 2nd Ed., 1996

Schneier B. & Banisar D. (Eds.) (1997) 'The Electronic Privacy Papers: Documents on the Battle for Privacy in the Age of Surveillance' Wiley, 1997

Security Domain (1997) 'About public key cryptography', at http://www.certificates-australia.com.au/aboutpkc.htm

UNCITRAL (1996) 'UNCITRAL Model Law On Electronic Commerce With Guide To Enactment', United Nations, 1996, at http://www.un.or.at/uncitral/texts/electcom/ml-ec.htm

UNCITRAL (1998) 'Draft Uniform Rules on Electronic Signatures', at http://www.un.or.at/uncitral/sessions/wg_ec/wp-73.htm

Utah Digital Signature Act, 1995 http://www.state.ut.us/ccjj/digsig/

Utah (1996) 'Digital Signature Tutorial', at http://www.commerce.state.ut.us/web/commerce/digsig/tutorl.htm

Utah (1997) 'Frequently Asked Questions Regarding Digital Signatures', at http://www.commerce.state.ut.us/web/commerce/digsig/dsfaq.htm

Visa (1996-) 'SET', at http://www.visa.com/cgi-bin/vee/nt/ecomm/set/main.html?2+0

Wayner P. (1996) 'Don't Lose Your Crypto Keys' BYTE (May 1996) p.137

Whittle R. (1996) 'Public Key Authentication Framework for Australia' http://www.ozemail.com.au/~firstpr/crypto/pkaf-1.htm

Ylönen T. (1996-) 'Introduction to Cryptography', at http://www.cs.hut.fi/crypto/intro.html



xamaxsmall.gif missing
The content and infrastructure for these community service pages are provided by Roger Clarke through his consultancy company, Xamax.

From the site's beginnings in August 1994 until February 2009, the infrastructure was provided by the Australian National University. During that time, the site accumulated close to 30 million hits. It passed 40 million by the end of 2012.

Sponsored by Bunhybee Grasslands, the extended Clarke Family, Knights of the Spatchcock and their drummer
Xamax Consultancy Pty Ltd
ACN: 002 360 456
78 Sidaway St, Chapman ACT 2611 AUSTRALIA
Tel: +61 2 6288 6916

Created: 11 February 1996 - Last Amended: 11 May 1998; addition of FfE licence 5 March 2004 by Roger Clarke - Site Last Verified: 15 February 2009
This document is at www.rogerclarke.com/II/CryptoSecy.html
Mail to Webmaster   -    © Xamax Consultancy Pty Ltd, 1995-2013   -    Privacy Policy