Encryption and authentication

Bonsoir,

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.

Is it possible to clarify that.
Thanks for your advice,
Michelot

Re: Encryption and authentication

mhostettler@voila.fr 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

Re: Encryption and authentication

In article <1162408381.436165.63230@m73g2000cwd.googlegroups.com>,
wrote:
>Traffic can be authenticated without being encrypted. Is it possible to
>have encryption without authentication?

Yes.

>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.

Public Key Encryption does not have offer authentication unless
the the sender "signs" the transmission with their private key.

Re: Encryption and authentication

mhostettler@voila.fr wrote:
> Bonsoir,
>
> 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".
>

Authenticity != Authentication

confidentiality + integrity = authenticity
(yes that's the original unaltered data)

But nothing "authenticates" where or from whom it came.

Re: Encryption and authentication

Bonsoir Walter,

>> Is it possible to
>> have encryption without authentication?
>
> Yes.

Thanks for that. It's clear now, I had a doubt with that.

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

Sorry, I made a terrible mistake: cryptography is not encryption, but a
technique that uses algorithm and keys. It allows to authentify users,
to detect information integrity and to make encryption (that is to
protect information confidentiality).

Do you agree?

> Public Key Encryption does not have offer authentication unless
> the the sender "signs" the transmission with their private key.

Interresting! is it really used? I would say that, normally, the
signature is done with the private key.


Regards,
Michelot

Re: Encryption and authentication

Bonsoir Michelot,

> > Public Key Encryption does not have offer authentication unless
> > the the sender "signs" the transmission with their private key.
>
> Interresting! is it really used? I would say that, normally, the
> signature is done with the private key.

You're sleeping Michelot. Walter is right, if the authentication is
signed, the sender signs with its private key.

Michelot

Re: Encryption and authentication

Bonsoir,

> Authenticity != Authentication
>
> confidentiality + integrity = authenticity
> (yes that's the original unaltered data)

I'm not an expert. In the draft ISO 27000, it is noted that definition:

"Authenticity: the property that ensures that the identity of a subject
or resource is the one claimed. Authenticity applies to entities such
as users, processes, systems and information".

When you say "that's the original unaltered data", it seems that is
only integrity.

Draft ISO 27000 "Data integrity: property that data has not been
altered or destroyed in an unauthorized manner.[ISO/IEC 18028-2]"

Thanks for your reply.
Michelot

Re: Encryption and authentication

Bonsoir Thorin,

> > Authenticity != Authentication
> >
> > confidentiality + integrity = authenticity
> > (yes that's the original unaltered data)

Finally, after thinking about it, it seems that I grasp that meaning.
And now, I don't really find very clear the authenticity definition
given in ISO 27000, but it is a draft.

Your word "original" is important. For that, confidentiality is
probably needed.

Best regards,
Michelot

Re: Encryption and authentication

Post removed (X-No-Archive: yes)