Re: Encryption and authentication

mhostettler@xxxxxxxx writes:
Is anyone could please explain the relationship between authentication
and encryption.

Traffic can be authenticated without being encrypted. Is it possible to
have encryption without authentication?

I read that, in OSI 17799: "the cryptographic techniques protect the
confidentiality, integrity and authenticity of information".

So, it seems that encryption couldn't exist without authentication.


the security "PAIN" acronym

P - privacy (sometimes as CAIN ... confidentiality)
A - authentication
I - integrity
N - non-repudiation

so encryption technology can be used for hiding information, achieving
security "privacy" (or "confidentiality).

given that you know that only specific entities have access to a
specific encryption keys ... then it can be possible for encryption to
also imply authentication (because part of the encryption business
process requires that only specific entities have access to the
associated encryption key).

so as part of a cryptographic business process, a secure hash of
information can be taken and also encrypted. if the recomputed hash of
a decrypted message is the same as the decrypted original hash
.... then the implication is that the message has not been modified
.... providing for integrity.

and example is asymmetric key cryptography technology.

using asymmetric key cryptography technology, a public/private key
business process is defined ... where the public key is widely
publicized and the corresponding private key is kept confidential and
never divulged.

it is possible to take an entity's public key and encode a message.
privacy/confidentiality is presumed because the decoding of the
message can only be done by the entity with access to the
corresponding private key.

a digital signature business process is defined utilizing the
public/private key business process.

the secure hash of some information is calculated and encoding
with the entity's private key.

a relying party processing the information can recalculate the secure
hash and compare it with the original secure hash decoded with the
corresponding public key.

from 3-factor authentication model
http://www.garlic.com/~lynn/subintegrity.html#3factor

* something you have
* something you know
* something you are

the relying party, on matching the two secure hash (in the digital
signature business process), can infer that

1) the information has not changed (integrity)

2) "something you have" authentication, aka the original digital
signature was done by an entity with exclusive and unique access to
the corresponding private key, which has been kept confidential and
never divulged.

if you combine digital signature (for integirty and authentication)
with public key encryption of the information (for
privacy/confidentiality) ... you can achieve three of the four PAIN
characteristics.

note that "N" in PAIN is a lot harder. there is some unfortunate
semantic confusion that the term "digital signature" and the term
"human signature" both contain the word "signature". there has
sometimes been the misbelief that the "digital signature" business
process (integrity and authentication) can assume to be equivalent to
the "human signature" process which implies that the person had read,
understood, agrees, approves, and/or authorizes the information.
however there is actually a vast chasm between "digital signature" and
"human signature". misc. posts discussing various signature
characteristics
http://www.garlic.com/~lynn/subpubkey.html#signature

for other drift ... we were called in to consult with a small
client/server startup that wanted to do payments on their server.
they had this technology called SSL (or sometimes HTTPS). the
resulting payment processing implementation is sometimes now
referred to as electronic commerce
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

SSL encryption has been used to hide the credit card account number,
preserving its privacy and confidentiality.

the risk is that just divulging the account number can result in
fraudulent transactions ... various posts regarding shared secret
based business processes
http://www.garlic.com/~lynn/subintegrity.html#secret
and account number harvesting vulnerabilities
http://www.garlic.com/~lynn/subintegrity.html#harvest

.... and a little more context from a post about security proportional
to risk
http://www.garlic.com/~lynn/2001h.html#61

a little later in the x9a10 financial standards working group, the
reguirement for the x9.59 standards work was to preserve the integrity
of the financial infrastructure for all retail payments
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

part of the standard eliminated the risk associated with divulging the
account number (resulting in fraudulent transactions). digital
signature business process was used to provide integrity and
authentication. furthermore, part of the standard was a business rule
that account numbers used in x9.59 retail financial transactions could
not be used in non-authenticated transactions.

the account number scenario with SSL is that the planet needs to buried
under miles of cryptography for hiding in order to prevent fraudulent
transactions (aka enormous amounts of privacy/confidentiality).

in x9.59, the fraud risk related to divulging account numbers is
eliminated ... and therefor it is no longer necessary to hide (x9.59)
account numbers. In effect, x9.59 manages to substitute integrity and
authentication for privacy/confidentiality as countermeasure to
account number related fraud (to preserve the integrity of the
financial infrastructure for all retail payments, it is no longer
necessary to hide the account number).

lots of past posts mentioning threats, exploits, vulnerabilities, and
fraud
http://www.garlic.com/~lynn/subintegrity.html#fraud

and misc. posts mentioning assurance
http://www.garlic.com/~lynn/subintegrity.html#assurance

recent discussion regarding "naked transactions" ... requirement
for enormous amounts of "hiding" (privacy/confidentiality) because
any trival leakage of account numbers lead to enormous fraud risk.
the alternative is to armor every transaction with digital
signature (integrity, authentication) ... eliminating the enormous
fraud risk related to even trivial account number leakage:
http://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#10 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#25 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm24.htm#26 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#31 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#32 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#37 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#41 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#42 Naked Payments II - uncovering alternates, merchants v. issuers, Brits bungle the risk, and just what are MBAs good for?
http://www.garlic.com/~lynn/aadsm24.htm#43 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm25.htm#1 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#4 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#9 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm25.htm#10 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#20 Identity v. anonymity -- that is not the question
http://www.garlic.com/~lynn/aadsm25.htm#28 WESII - Programme - Economics of Securing the Information Infrastructure
http://www.garlic.com/~lynn/aadsm25.htm#38 How the Classical Scholars dropped security from the canon of Computer Science
.

Relevant Pages

  • Re: CBC questions
    ... > recognized experts in cryptography. ... > | Practical Cryptography. ... for an IND-CPA encryption scheme yields the properties INT-CTXT (and ... practical message authentication algorithms. ...
    (sci.crypt)
  • Re: CBC questions
    ... > network services allow the attacker to get the encryption of plaintexts ... according to some recognized experts in cryptography. ... "8.2 Order of Authentication and Encryption ... "We choose to authenticate first." ...
    (sci.crypt)
  • Re: Ciphers and their effect on the size of data
    ... We have a security-sensitive client that is wants common authentication between a J2EE environment and a "fat windows client". ... we'll also be facing 4/3 expansion of the payload after encryption. ... This password field will include a digital signature, or the digital signature will be in another XML element in that document. ...
    (sci.crypt)
  • Re: Ciphers and their effect on the size of data
    ... The user goes to the J2EE server, ... and submit them to the UNIX-hosted service for authentication. ... authenticate to the J2EE environment first, ... facing 4/3 expansion of the payload after encryption (for base64 ...
    (sci.crypt)
  • Efficient message authentication?
    ... Is the following message authentication algorithm known? ... One would like to combine encryption and authentication, ... faces impractically difficult patent negotiations for ...
    (sci.crypt)