Using a MAC in addition to symmetric encryption

2008-06-29 Thread Erik Ostermueller
Hello all,

If I exchange messages with a system and the messages are encrypted with a 
symmetric key, what further benefit would we get by using a MAC (Message 
Authentication Code) along with the message encryption?
Being new to all this, using the encrytpion and MAC together seem redundant.

Thanks,

--Erik Ostermueller



  

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


The wisdom of the ill informed

2008-06-29 Thread Allen

Hi gang,

All quiet on the cryptography front lately, I see. However, that 
does not prevent practices that *appear* like protection but are not 
even as strong as wet toilet paper.


I had to order a medical device today and they need a signed 
authorization for payment by my insurance carrier. No biggie. So 
they ask how I want it set to me and I said via e-mail. Okay. /Then/ 
they said it was an encrypted file and I thought, cool. How wrong 
could I be?


Very. The (I hate to use this term for something so pathetic) 
password for the file is 6 (yes, six) numeric characters!


My 6 year old K6-II can crack this in less than one minute as there 
are only 1.11*10^6 possible.


You can lead a horse to water

Best,

Allen

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Why doesn't Sun release the crypto module of the OpenSPARC?

2008-06-29 Thread zooko

On Jun 26, 2008, at 6:55 PM, David G. Koontz wrote:


[Moderator's note: this seems to be much more about the open source
 wars and such than about crypto and security. I'm not going to
 forward replies on this topic that don't specifically address
 security issues -- those who were not interested in the original
 thread may want to skip this message, too. --Perry]



The high-order bit here is that the reason Sun has not open sourced  
the crypto module of the Sparc T2 along with all the other modules is  
the US government's export restrictions and their extra-legal  
implicit threats.  I've received another e-mail from a Sun employee  
stating that crypto export restrictions are the issue and that Sun  
management feels that it is too risky to defy the government's  
pressure because the government has the power to do billions of  
dollars in damage to the company by temporarily suspending their  
export licences for their whole suite of products.


My conclusions are:

1.  We didn't exactly win the free-crypto struggle after all (see Ian  
Grigg's and Sameer Parekh's comments [1, 2]), and


2.  I'm going to keep designing my security systems to be optimized  
for software crypto and not to rely on hardware acceleration.  In  
particular, that means that I can continue to consider the Tiger hash  
(faster in software but not available in commodity hardware) to be  
faster than the SHA-256 hash (slower in software but available in  
hardware in the Sparc T2 and probably other commodity products).   
Likewise newfangled ciphers like Salsa20 and EnRUPT will be  
considered by me to be faster than AES (because they are faster in  
software) rather than slower (because AES might be built into the  
commodity hardware).


Note that it would also be a reasonable stance to rely on hardware  
implementations of crypto even though there are not commodity open  
source hardware implementations.  The beginning of this thread was  
the question of how to weigh the threat of hardware backdoors, and  
what countermeasures we can use to gain assurance that we're not  
vulnerable to hardware backdoors.  I'm not saying that having the  
source code for your hardware is either necessary or sufficient to  
protect yourself from that threat, but it might help, and I currently  
think it is a better strategy to design around the assumptions of  
software crypto.


Regards,

Zooko

[1] https://financialcryptography.com/mt/archives/001064.html
[2] http://www.creativedestruction.com/archives/000937.html

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Using a MAC in addition to symmetric encryption

2008-06-29 Thread Greg Rose

Erik Ostermueller wrote:

If I exchange messages with a system and the messages are encrypted with a 
symmetric key, what further benefit would we get by using a MAC (Message 
Authentication Code) along with the message encryption?
Being new to all this, using the encrytpion and MAC together seem redundant.


One of my favourite papers, by Steve Bellovin, is at 
http://www.usenix.org/publications/library/proceedings/sec96/bellovin.html


It shows a number of ways in which IPsec with encryption but no 
integrity can fail.


Abstract:
The Internet Engineering Task Force (IETF) is in the process of adopting 
standards for IP-layer encryption and authentication (IPSEC). We 
describe a number of attacks against various versions of these 
protocols, including confidentiality failures and authentication 
failures. The implications of these attacks are troubling for the 
utility of this entire effort.


Greg.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Using a MAC in addition to symmetric encryption

2008-06-29 Thread Eric Rescorla
At Fri, 27 Jun 2008 07:52:59 -0700 (PDT),
Erik Ostermueller wrote:
 If I exchange messages with a system and the messages are encrypted
 with a symmetric key, what further benefit would we get by using a
 MAC (Message Authentication Code) along with the message encryption?
 Being new to all this, using the encrytpion and MAC together seem
 redundant.

Encryption doesn't necessarily provide integrity.

Consider the case of a stream cipher like RC4, where you have
a function RC4(K) which generates a string of bytes from the
key K.

The encryption function is then:

Ciphertext[i] = RC4(K)[i] XOR Plaintext[i]


It should be apparent that an attacker can make targeted
modifications to the plaintext. Say he knows that plaintext
byte i is 'A' and he wants it to be 'B', he just changed
Ciphertext[i]' = Ciphertext[i] XOR 'A' XOR 'B'. Mission
accomplished.

-Ekr



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Using a MAC in addition to symmetric encryption

2008-06-29 Thread Jonathan Katz

On Fri, 27 Jun 2008, Erik Ostermueller wrote:


Hello all,

If I exchange messages with a system and the messages are encrypted with a 
symmetric key, what further benefit would we get by using a MAC (Message 
Authentication Code) along with the message encryption?
Being new to all this, using the encrytpion and MAC together seem redundant.

Thanks,

--Erik Ostermueller


As the other posters have already commented, encryption alone does not
(in general) provide integrity. Furthermore, care must be taken in how
the encryption scheme and the MAC are combined, with
encryption-followed-by-MACing-the-ciphertext being the best choice
unless you know what you are doing. For further discussion, see the
textbook by Katz-Lindell (Section 4.9), and/or the following paper:
http://www-cse.ucsd.edu/users/mihir/papers/oem.html

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: The wisdom of the ill informed

2008-06-29 Thread Arshad Noor

[Moderator's note: Top posting considered uncool. --Perry]

While programmers or business=people could be ill-informed, Allen,
I think the greater danger is that IT auditors do not know enough
about cryptography, and consequently pass unsafe business processes
and/or software as being secure.

This is the reason why we in the OASIS Enterprise Key Management
Infrastructure Technical Committee have made educating IT Auditors
and providing them guidelines on how to audit symmetric key-management
infrastructures, one of the four (4) primary goals of the TC.  While
the technology is well understood by most people on this forum, until
we educate the gate-keepers, we have failed in our jobs to secure IT
infrastructure.

Arshad Noor
StrongAuth, Inc.

Allen wrote:

Hi gang,

All quiet on the cryptography front lately, I see. However, that does 
not prevent practices that *appear* like protection but are not even as 
strong as wet toilet paper.


I had to order a medical device today and they need a signed 
authorization for payment by my insurance carrier. No biggie. So they 
ask how I want it set to me and I said via e-mail. Okay. /Then/ they 
said it was an encrypted file and I thought, cool. How wrong could I be?


Very. The (I hate to use this term for something so pathetic) password 
for the file is 6 (yes, six) numeric characters!


My 6 year old K6-II can crack this in less than one minute as there are 
only 1.11*10^6 possible.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]