|
Posted by on November 1, 2006, 2:13 pm
If you were Registered and logged in, you could reply and use other advanced thread options
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
|
|
Posted by Anne & Lynn Wheeler on November 1, 2006, 2:49 pm
If you were Registered and logged in, you could reply and use other advanced thread options
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
|
|
Posted by Walter Roberson on November 1, 2006, 2:54 pm
If you were Registered and logged in, you could reply and use other advanced thread options >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.
|
|
Posted by Michelot on November 1, 2006, 4:02 pm
If you were Registered and logged in, you could reply and use other advanced thread options
>> 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
|
|
Posted by Michelot on November 1, 2006, 4:08 pm
If you were Registered and logged in, you could reply and use other advanced thread options
> > 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
|
| Similar Threads | Posted | | 128-bit encryption [?] | March 18, 2005, 11:35 am |
| Double Encryption!!! | July 9, 2008, 4:02 am |
| Re: Double Encryption!!! | July 9, 2008, 2:40 pm |
| Re: Double Encryption!!! | July 10, 2008, 12:01 am |
| Advanced Encryption Standard-Can any one explain?? | February 10, 2005, 7:19 am |
| Care/encryption of firewall rules | April 27, 2008, 9:11 am |
| Authentication, Authorization | July 26, 2007, 3:15 pm |
| Watchguard and HTTP authentication | March 22, 2005, 6:08 pm |
| Sonicwall VPN Authentication & Audit | June 20, 2006, 8:54 pm |
| Radius Authentication through checkpoint | November 22, 2006, 3:55 pm |
|
XML site map