Re: Fast MAC algorithms?

2009-08-02 Thread Zooko Wilcox-O'Hearn
I recommend Poly1305 by DJB or VMAC by Ted Krovetz and Wei Dai.  Both  
are much faster than HMAC and have security proven in terms of an  
underlying block cipher.


VMAC is implemented in the nice Crypto++ library by Wei Dai, Poly1305  
is implemented by DJB and is also in the new nacl library by DJB.


http://cryptopp.com/benchmarks-amd64.html

Says that VMAC(AES)-64 takes 0.6 cycles per byte (although watch out  
for that 3971 cycles to set up key and IV), compared to HMAC-SHA1  
taking 11.2 cycles per byte (after 1218 cycles to set up key and IV).


If you do any measurement comparing Poly1305 to VMAC, please report  
your measurement, at least to me privately if not to the list.  I can  
use that sort of feedback to contribute improvements to the Crypto++  
library.  Thanks!


Regards,

Zooko Wilcox-O'Hearn
---
Tahoe, the Least-Authority Filesystem -- http://allmydata.org
store your data: $10/month -- http://allmydata.com/?tracking=zsig
I am available for work -- http://zooko.com/résumé.html

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: The clouds are not random enough

2009-08-02 Thread Jerry Leichter

Why Cloud Computing Needs More Chaos:
http://www.forbes.com/2009/07/30/cloud-computing-security-technology-cio-network-cloud-computing.html

[Moderator's note: ... the article is about a growing problem -- the
lack of good quality random numbers in VMs provided by services like  
EC2

and the effect this has on security. --Perry]
The problem is broader than this.  A while back, I evaluated a  
technology that did it best to solve a basically insoluble problem:   
How does a server, built on stock technology, keep secrets that it can  
use to authenticate with other servers after an unattended reboot?   
Without tamper-resistant hardware that controls access to keys,  
anything the software can get at at boot, an attacker who steals a  
copy of a backup, say - can also get at.  So, the trick is to use a  
variety of measurements of the hardware - amount of memory, disk  
sizes, disk serial numbers, whatever you can think of that varies from  
machine to machine and is not stored in a backup - and combines them  
to produce a key that encrypts the important secrets.  Since hardware  
does need to be fixed or upgraded at times, a good implementation will  
use some kind of m unchanged out of n measurements algorithm.   
Basically, this is the kind of thing Microsoft uses to lock license  
keys to particular instances of hardware.  Yes, it can be broken - but  
you can make breaking it a great deal of work.


Virtualization changes all of this.  Every copy of a virtual machine  
is will be identical as far as most of these measurements are  
concerned.  Conversely, if you try to let the physical level show  
through - e.g., use the disk serial number of the real disk on which a  
virtual disk lives - you disrupt some of the things VM's are trying to  
provide, lie easy transportability of instances from one hardware  
home to another.  The last I heard about the technology I looked at,  
they didn't have any good solution for VM's (though I haven't kept up  
and don't know the current status).


Ultimately, the only solution is for hypervisors to take on some  
security roles - passing along unforgeable ID's and random numbers  
from hardware and other resources that they have access to but do not  
export to the guest OS's. That doesn't *solve* the problem.  It puts  
us back where we were before the virtualization craze:  Needing to  
write a secure OS and various secure
services.  However, since hypervisors are much smaller and *much* more  
limited in operation than full OS's, so the problems may be  
correspondingly easier to solve.

-- Jerry


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


AES, RC4

2009-08-02 Thread PETER SCHWEITZER
Referring to your note of August 1: I haven't found anything about  
breaking RC4 if used with a newly randomly generated key (unrelated to  
any others) for every communication session. I would appreciate being  
enlightened!


(Of course one should throw away initial parts of the stream. I  
suggested doing this to Ron Rivest  RSA in the early 1980s,  
legitimately knowing about the still-secret RC4 cipher-logic from a  
client, to whom I made the same suggestion. But even if one doesn't,  
the result isn't what I would call breaking RC4.) I should say that  
I was appalled when I first learned of people using RC4 with related  
keys; its structure certainly suggested to me that there would be  
vulnerabilities.


Is your partly negative recommendation for AES' ...for most new  
protocol purposes to do with the recent related-key attack? Which I  
would certainly agree is very disquieting, even though, as you say, it  
has no current negative consequences.


I may speculate elsewhere about who knew what  why before the recent  
publication.


Thank you!

P.
(Peter Schweitzer)


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Fast MAC algorithms?

2009-08-02 Thread James A. Donald

Joseph Ashwood wrote:

RC-4 is broken when used as intended.

...

If you take these into consideration, can it be used correctly?


James A. Donald:

Hence tricky


Joseph Ashwood wrote:
By the same argument a Viginere cipher is tricky to use securely, same 
with monoalphabetic and even Ceasar. Not that RC4 is anywhere near the 
brokenness of Viginere, etc, but the same argument can be applied, so 
the argument is flawed.


You cannot use a Viginere cipher securely. You can use an RC4 cipher 
securely:  To use RC4 securely discard the first hundred bytes of 
output, and renegotiate the key every gigabyte.



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


ANNOUNCING Tahoe, the Lofty-Atmospheric Filesystem, v1.5

2009-08-02 Thread Zooko Wilcox-O'Hearn

Dear people of Perry's cryptography mailing list:

Please check out the new release of Tahoe-LAFS.  We claim that it is  
the first cloud storage technology which offers real security.  If  
you can find a weakness in the cryptographic structure (or any  
security hole whatsoever), then you will be added to the Hall Of Fame  
at http://hacktahoe.org .  :-)


Regards,

Zooko

---
The Tahoe-LAFS team is pleased to announce the immediate availability of
version 1.5 of Tahoe, the Lofty Atmospheric File System.

Tahoe-LAFS is the first cloud storage technology which offers security
and privacy in the sense that the cloud storage service provider itself
can't read or alter your data. Here is the one-page explanation of
its unique security and fault-tolerance properties:

http://allmydata.org/source/tahoe/trunk/docs/about.html

This release is the successor to v1.4.1, which was released April 13,
2009 [1]. This is a major new release, improving the user interface and
performance and fixing a few bugs, and adding ports to OpenBSD, NetBSD,
ArchLinux, NixOS, and embedded systems built on ARM CPUs. See the NEWS
file [2] for more information.

In addition to the functionality of Tahoe-LAFS itself, a crop of related
projects have sprung up to extend it and to integrate it into operating
systems and applications.  These include frontends for Windows,
Macintosh, JavaScript, and iPhone, and plugins for duplicity, bzr,
Hadoop, and TiddlyWiki, and more. See the Related Projects page on the
wiki [3].


COMPATIBILITY

Version 1.5 is fully compatible with the version 1 series of
Tahoe-LAFS. Files written by v1.5 clients can be read by clients of all
versions back to v1.0. v1.5 clients can read files produced by clients
of all versions since v1.0.  v1.5 servers can serve clients of all
versions back to v1.0 and v1.5 clients can use servers of all versions
back to v1.0.

This is the sixth release in the version 1 series. The version 1 series
of Tahoe-LAFS will be actively supported and maintained for the
forseeable future, and future versions of Tahoe-LAFS will retain the
ability to read and write files compatible with Tahoe-LAFS v1.

The version 1 series of Tahoe-LAFS is the basis of the consumer backup
product from Allmydata, Inc. -- http://allmydata.com .


WHAT IS IT GOOD FOR?

With Tahoe-LAFS, you can distribute your filesystem across a set of
servers, such that if some of them fail or even turn out to be
malicious, the entire filesystem continues to be available. You can
share your files with other users, using a simple and flexible access
control scheme.

We believe that the combination of erasure coding, strong encryption,
Free/Open Source Software and careful engineering make Tahoe-LAFS safer
than RAID, removable drive, tape, on-line backup or other Cloud storage
systems.

This software comes with extensive tests, and there are no known
security flaws which would compromise confidentiality or data integrity
in typical use.  (For all currently known issues please see the
known_issues.txt file [4].)


LICENCE

You may use this package under the GNU General Public License, version 2
or, at your option, any later version.  See the file COPYING.GPL [5]
for the terms of the GNU General Public License, version 2.

You may use this package under the Transitive Grace Period Public
Licence, version 1 or, at your option, any later version.  (The
Transitive Grace Period Public Licence has requirements similar to the
GPL except that it allows you to wait for up to twelve months after you
redistribute a derived work before releasing the source code of your
derived work.) See the file COPYING.TGPPL.html [6] for the terms of
the Transitive Grace Period Public Licence, version 1.

(You may choose to use this package under the terms of either licence,
at your option.)


INSTALLATION

Tahoe-LAFS works on Linux, Mac OS X, Windows, Cygwin, Solaris, *BSD, and
probably most other systems.  Start with docs/install.html [7].


HACKING AND COMMUNITY

Please join us on the mailing list [8].  Patches are gratefully accepted
-- the RoadMap page [9] shows the next improvements that we plan to make
and CREDITS [10] lists the names of people who've contributed to the
project.  The Dev page [11] contains resources for hackers.


SPONSORSHIP

Tahoe-LAFS was originally developed thanks to the sponsorship of
Allmydata, Inc. [12], a provider of commercial backup services.
Allmydata, Inc. created the Tahoe-LAFS project and contributed hardware,
software, ideas, bug reports, suggestions, demands, and money (employing
several Tahoe-LAFS hackers and instructing them to spend part of their
work time on this Free Software project).  Also they awarded customized
t-shirts to hackers who found security flaws in Tahoe-LAFS (see
http://hacktahoe.org ). After discontinuing funding of Tahoe-LAFS RD in
early 2009, Allmydata, Inc. has continued to provide servers, co-lo
space and bandwidth to the open source project. Thank you to Allmydata,
Inc. for their generous and 

Re: AES, RC4

2009-08-02 Thread Joseph Ashwood

-
From: PETER SCHWEITZER pe...@infosecsys.com
Subject: AES, RC4

Referring to your note of August 1: I haven't found anything about 
breaking RC4 if used with a newly randomly generated key (unrelated to 
any others) for every communication session. I would appreciate being 
enlightened!


If a completely unrelated new key is used, and the key has sufficient 
entropy, and it isn't used for too long, and the entropy of the key is 
fairly smoothly distributed, and the first several bytes are discarded, and 
I'm probably missing a couple of requirements, then RC4 is reasonably 
secure. On the other hand using AES-128 in CTR mode, the key requires 
sufficient entropy. That is the difference, particularly attempting to make 
sure there the RC4 kys are truly unrelated is continually difficult.


Is your partly negative recommendation for AES' ...for most new  protocol 
purposes to do with the recent related-key attack? Which I  would 
certainly agree is very disquieting, even though, as you say, it  has no 
current negative consequences.


The last few weeks have not been kind to AES-256, a couple new attacks, the 
related key on the full structure, and the more recent significant erosion 
in other areas. Like I said, not enough to force an immediate retirement, 
AES-256 remains functionally secure, but the argument for usage is getting 
more difficult, AES-256 seems to be no more secure than AES-128, and is 
slower.
   Joe 


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Fast MAC algorithms?

2009-08-02 Thread Joseph Ashwood

--
From: James A. Donald jam...@echeque.com
Subject: Re: Fast MAC algorithms?


Joseph Ashwood wrote:

RC-4 is broken when used as intended.

...

If you take these into consideration, can it be used correctly?


James A. Donald:

Hence tricky


Joseph Ashwood wrote:

By the same argument a Viginere cipher is tricky to use securely, same
with monoalphabetic and even Ceasar. Not that RC4 is anywhere near the
brokenness of Viginere, etc, but the same argument can be applied, so the
argument is flawed.


You cannot use a Viginere cipher securely. You can use an RC4 cipher
securely:  To use RC4 securely discard the first hundred bytes of output,
and renegotiate the key every gigabyte.


The way to use a Viginere securely is to apply an All-Or-Nothing-Transform 
to the plaintext, then encrypt, this results in the attacker entropy of the 
system that is in excess of the size, and therefore a OTP. There are other 
ways, but this method is not significantly more complex than the efforts 
necessary to secure RC4 and results in provable secrecy. It is just tricky 
to use a Vigenere securely.
   Joe 


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Protocol Construction WAS Re: Fast MAC algorithms?

2009-08-02 Thread Joseph Ashwood

--
From: Ray Dillinger b...@sonic.net
Subject: Re: Fast MAC algorithms?


I mean, I get it that crypto is rarely the weakest link in a secured
application.  Still, why are folk always designing and adopting
cryptographic tools for the next decade or so instead of for the
next few centuries?


Because we have no idea how to do that. If you were to ask 6 months ago we 
would've said AES-256 will last at least a decade, probably 50 years. A few 
years before that we were saying that SHA-1 is a great cryptographic hash. 
Running the math a few years ago I determined that with the trajectory of 
cryptographic research it would've been necessary to create a well over 
1024-bit hash with behaviors that are perfect by todays knowledge just to 
last a human lifetime, since then the trajectory has changed significantly 
and the same exercise today would probably result in 2000+ bits, 
extrapolating the trajectory of the trajectory, the size would be entirely 
unacceptable. So, in short, collectively we have no idea how to make 
something secure for that long.



So far, evidence supports the idea that the stereotypical Soviet
tendency to overdesign might have been a better plan after all,
because the paranoia about future discoveries and breaks that motivated
that overdesign is being regularly proven out.


And that is why Kelsey found an attack on GOST, and why there is a class of 
weak keys. That is the problem, all future attacks are rather by definition 
a surprise.



This is fundamental infrastructure now!  Crypto decisions now
support the very roots of the world's data, and the cost of altering
and reversing them grows ever larger.


By scheduling likely times for upgrades the prices can be assessed better, 
scheduled better, and works far better for business than the OH . OUR 
 IS BROKEN experience that always results from trying to plan for 
longer than a few years at a time. It is far cheaper to build within the 
available knowledge, and design for a few years.




If you can deploy something once, even something that uses three
times as many rounds or key bits as you think now that you need,


Neither of those is a strong indicator of security. AES makes a great 
example, AES-256 has more rounds than AES-128, AES-256 has twice as many key 
bits as AES-128, and AES-256 has more attacks against it than AES-128. An 
increasing number of attack types are immune to the number of rounds, and 
key bits has rarely been a real issue.


There is no way predicting the far future of cryptography, it is hard enough 
to predict the reasonably near future.
   Joe 


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


GPGPU MD5 collision search shown at Black Hat

2009-08-02 Thread Perry E. Metzger

An implementation of MD5 collision searching done on GPUs instead of
ordinary CPUs -- substantially faster searches with fewer processors.

http://www.blackhat.com/presentations/bh-usa-09/BEVAND/BHUSA09-Bevand-MD5-PAPER.pdf

I imagine that if anyone really cared to generate such things really
quickly, custom hardware would be fastest of all.

-- 
Perry E. Metzgerpe...@piermont.com

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: The clouds are not random enough

2009-08-02 Thread Ben Laurie
On Sat, Aug 1, 2009 at 10:06 PM, Jerry Leichterleich...@lrw.com wrote:
 Why Cloud Computing Needs More Chaos:

 http://www.forbes.com/2009/07/30/cloud-computing-security-technology-cio-network-cloud-computing.html

 [Moderator's note: ... the article is about a growing problem -- the
 lack of good quality random numbers in VMs provided by services like EC2
 and the effect this has on security. --Perry]

 The problem is broader than this.  A while back, I evaluated a technology
 that did it best to solve a basically insoluble problem:  How does a server,
 built on stock technology, keep secrets that it can use to authenticate with
 other servers after an unattended reboot?  Without tamper-resistant hardware
 that controls access to keys, anything the software can get at at boot, an
 attacker who steals a copy of a backup, say - can also get at.  So, the
 trick is to use a variety of measurements of the hardware - amount of
 memory, disk sizes, disk serial numbers, whatever you can think of that
 varies from machine to machine and is not stored in a backup - and combines
 them to produce a key that encrypts the important secrets.  Since hardware
 does need to be fixed or upgraded at times, a good implementation will use
 some kind of m unchanged out of n measurements algorithm.  Basically, this
 is the kind of thing Microsoft uses to lock license keys to particular
 instances of hardware.  Yes, it can be broken - but you can make breaking it
 a great deal of work.

 Virtualization changes all of this.  Every copy of a virtual machine is will
 be identical as far as most of these measurements are concerned.

I'd imagine (I'm not particularly interested in licence enforcement,
so I really am imagining), that the opposite was the problem: i.e.
that the host could run you on any VM which might have wildly varying
characteristics, depending on what the real machine underneath was,
and what else you were sharing with. So, every time you see the
measurements, they'll be different.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Unattended reboots (was Re: The clouds are not random enough)

2009-08-02 Thread Arshad Noor

Jerry Leichter wrote:
  How
does a server, built on stock technology, keep secrets that it can use 
to authenticate with other servers after an unattended reboot?  Without 
tamper-resistant hardware that controls access to keys, anything the 
software can get at at boot, an attacker who steals a copy of a backup, 
say - can also get at.  


I would be very interested in learning what conclusions you came to,
Jerry.  It is my experience that even *with* tamper-resistant hardware
(TPM, HSM, smartcard), the threat of breach is very high if the server
is configured for unattended reboots.

Almost every e-commerce site (that needs to be PCI-DSS compliant) I've
worked with in the last few years, insists on having unattended reboots.
Even when the server is configured with a FIPS-certified HSM and the
cryptographic keys are in secure storage with M of N controls for access
to the keys, in order for the application to have access to the keys in
the crypto hardware upon an unattended reboot, the PINs to the hardware
must be accessible to the application.  If the application has automatic
access to the PINs, then so does an attacker who manages to gain entry
to the machine.

If you (or anyone on this forum) know of technology that allows the
application to gain access to the crypto-hardware after an unattended
reboot - but can prevent an attacker from gaining access to those keys
after compromising a legitimate ID on the machine - I'd welcome hearing
about it.  TIA.

Arshad Noor
StrongAuth, Inc.

P.S. As an aside, the solution we have settled on is to have the key-
custodians enter their PINs to the crypto-hardware (even from remote
locations, if needed, through secure channels).  While it does not
provide for unattended reboots, it does minimize the latency between
reboots while ensuring that there is nothing persistent on the machine
with PINs to the crypto-hardware.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com