Re: Is this the first ever practically-deployed use of a threshold scheme?

2010-08-11 Thread mhey...@gmail.com
On Sun, Aug 1, 2010 at 7:10 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote:
 ...does anyone know of any significant use [of split keys] by
 J.Random luser?  I'm interested in this from a usability point
 of view.

Maybe not J.Random but J.Corporate...

A few jobs ago back in the late '90s, I worked for Network Associates
which had bought PGP (the company). We instituted the use of PGP (the
technology) corporate-wide for email and  encrypted disk volumes. PGP
allows for enforceable key recovery - corporate clients demanded it.
Our corporate key recovery key was split into, I think, 5 parts with 3
parts required for key recovery. The parts were held by various
corporate executive/officer types.

The PGP product mostly hid from the end user the fact that every
PGP-encrypted thing had an encrypted private key along with it (you
could poke around and see the key recovery blob if you really wanted
to).

I don't know what the key recovery UI looked like.

 As a corollary, has anyone gone through the process of recovering a key from
 shares held by different parties...?

It just so happens, I lost my PGP private key a year or two into this
(failed to copy it when transferring to a new desktop). We had well
documented procedures for key recovery. I never got my key or data
back. I was never informed why. Perhaps the seldom used key recovery
software had bugs and wouldn't work for my key, or we couldn't get the
required big wigs into one room, or, probably most likely, at least
three big wigs lost their shares.

Michael Heyman

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


AES in stick figures

2009-09-28 Thread mhey...@gmail.com
A Stick Figure Guide to the Advanced Encryption Standard (AES)
(A play in 4 acts)

http://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html

-Michael Heyman

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


Re: Malware using good crypto

2009-08-04 Thread mhey...@gmail.com
On Sat, Aug 1, 2009 at 11:52 PM, Udhay Shankar Nud...@pobox.com wrote:
 Interesting article. Anyone here have experience trying to
 reverse-engineer malware that uses really good crypto?

I haven't done this personally but I have worked with people who do.
Typically, the type of encryption isn't that important when you are
trying to de-obfuscate a binary, the obfuscation routines get treated
as a black box anyway. That is, you let the code do its own
de-obfuscation. This gets tricky because the fancier code knows when
you are looking at it or blocks you from looking at it (it looks to
see if a debug process is attached, or if it is running in a VM, or,
sometimes, it debugs itself so nobody else can).

Knowing the cryptographic algorithm can be useful. There is even a
plugin available for IDAPro that will look for tell-tale constants for
you and point out known cryptographic algorithms. Knowing the
cryptographic algorithm is more important after the de-obfuscated code
gets revealed because recognizing a cryptographic algorithm shortens
the reverse-engineering phase - describing a chunk of code as AES is a
lot easier and clearer then saying something like, there are these
constant tables with these values and they are used on two buffers
passed in with xors and shifts to return a single buffer with a
different value but the logic is so convoluted I cannot really tell
you how the resulting buffer is related to the initial buffers. ;-)

-Michael Heyman

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


Hacker Says iPhone 3GS Encryption Is ‘Useless’ f or Businesses

2009-07-24 Thread mhey...@gmail.com
From http://www.wired.com/gadgetlab/2009/07/iphone-encryption/:

   the supposedly enterprise-friendly encryption included with the iPhone 3GS
   is so weak it can be cracked in two minutes with a few pieces of
readily available
   freeware...“I don’t think any of us [developers] have ever seen encryption
   implemented so poorly before, which is why it’s hard to describe
why it’s such a
   big threat to security.”...Wondering where the encryption comes
into play? It
   doesn’t. Strangely, once one begins extracting data from an iPhone 3GS,
   the iPhone begins to decrypt the data on its own

-Michael

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


Re: Fast MAC algorithms?

2009-07-23 Thread mhey...@gmail.com
On Thu, Jul 23, 2009 at 1:34 AM, Peter Gutmannpgut...@cs.auckland.ac.nz wrote:
 mhey...@gmail.com mhey...@gmail.com writes:

2) If you throw TCP processing in there, unless you are consistantly going to
have packets on the order of at least 1000 bytes, your crypto algorithm is
almost _irrelevant_.
[...]
for a Linux 2.2.14 kernel, remember, this was 10 years ago.

 Could the lack of support for TCP offload in Linux have skewed these figures
 somewhat?  It could be that the caveat for the results isn't so much this was
 done ten years ago as this was done with a TCP stack that ignores the
 hardware's advanced capabilities.

TCP offload would, of course, help reduce CPU load and make crypto
algorithm choice have more of an effect. With our tests, however, to
actually show an effect, we had to use large packet sizes which
reduced the impact of TCP - I know we were using 64K packets for some
tests. Boosting the packet size also affected cycles-per-byte for
NMAC-style algorithms because the outer function gets run less often
for a given amount of data (IPSec processing occurs outbound prior to
fragmentation).

We needed to reduce the impact of TCP because it still remained that
when doing something with the data, the cycles-per-byte of that
processing greatly impacts the percentage of slowdown your MAC
algorithm choice will have.

To throw another monkey wrench into the works, obviously, you may
think But what if I have a low power application, trying to be green,
you know. So I want to use less processor intensive cryptography to
save energy? Well, I sat in the middle of a group of people doing
work for another DARPA project (SensIT) shortly after the ACSA
project. The SensIT project was for low energy wireless sensors in
which we experimented with different key exchange/agreement techniques
in an attempt to economize energy. As a throw-in result, the SensIT
people found it takes 3 orders of magnitude more energy to transmit or
receive data on a per-bit basis than it does to do AES+HMAC-SHA1 (it
came as a surprise to me back then that reception and transmission
take similar amounts of energy). Moral: don't scrimp on crypto to save
energy - at least for wireless, I don't know what it costs to send a
bit down a twisted pair or fiber.

The SensIT final report is available here:
http://www.cs.umbc.edu/courses/graduate/CMSC691A/Spring04/papers/nailabs_report_00-010_final.pdf.

-Michael Heyman

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


Re: Fast MAC algorithms?

2009-07-22 Thread mhey...@gmail.com
On Wed, Jul 22, 2009 at 1:43 AM, Nicolas
Williamsnicolas.willi...@sun.com wrote:

 But that's not what I'm looking for here.  I'm looking for the fastest
 MACs, with extreme security considerations...In the crypto world
 one never designs weak-but-fast algorithms on purpose, only
 strong-and-preferably-fast ones.  And when an algorithm is
 successfully attacked it's usually deprecated, put in the ash heap of
 history.  But there is a place for weak-but-fast algos, as long as
 they're not too weak.

It just so happens that I worked on a DARPA funded project about 10
years ago looking at the effects of any possible strength vs speed
trade off available for different MACing algorithms. We built the
capability into FreeS/Wan's IPSec. Some of our MACs were so weak we
called them Partial MACs (PMACs). PMACs authenticated only randomly
selected pieces of the packet. We figured PMACs were good enough for
video - who cares if Eve can feed you a frame or two of partially
spoofed video as long as you can't get enough to notice.

http://www.isso.sparta.com/documents/acsa_final_report.pdf

The major take aways include:

1) HMAC-SHA1-96 can typically triple the amount of CPU required to
move IP packets through the kernel over a no-crypto option.
HMAC-MD5-96 can double it.

2) If you throw TCP processing in there, unless you are consistantly
going to have packets on the order of at least 1000 bytes, your crypto
algorithm is almost _irrelevant_. TCP costs up to ~1000 cycles per
byte on 10 byte packets, 100 cycles per byte on 100 byte packets, and
only gets down to ~15 cycles per byte at 1000 byte packets. For
reference, HMAC-SHA1-96 takes about 25 cycles per byte for ~1000 byte
packets. These are PentiumII numbers for a Linux 2.2.14 kernel,
remember, this was 10 years ago.

3) If your host is actually going to do something with the data you
receive, it is really really hard to find something that the crypto
algorithm will affect. A coworker of mine struggled for to find a real
world desktop application in which you could actually see a result
(other then some numbers in a log file). Finally he found that viewing
a video remotely in an X-window (thats uncompressed video) would have
occasional drops that becomes noticeable if you pick your video well.
Our video was of a circular radar screen with a rotating update line
(I think it came from a screen saver). With this contrived
application, we could change the MAC algorithm and see more or less
disturbance in the video.

I'd like to emphasize points 2 and 3. You need an application that
either doesn't use TCP or that only uses TCP with MTU sized packets to
even want to care about crypto performance. I don't think the paper
points it out, but all are testing was done with two machines
connected directly to each other. Any out of order processing TCP
needs to do will only decrease the effect a MAC algorithm has. Also if
you want to do _anything_ with the data other than ignore it, it will
only further decrease the effect the MAC algorithm has. We tried
timing FTP transfers, streaming an MPEG, and numerous other things
that I don't remember but all these things had too much overhead to
allow the choice of MAC algorithm to be noticed. 10 years of kernel
network stack development and CPU improvements may have changed the
numbers slightly but I believe you need a really specialized case,
probably including real time requirements on marginal CPUs, before you
need to look at faster MAC algorithms.

Thanks for letting me reminisce about a really fun project (sprinkling
rdtsc around the Linux kernel and getting Steve Kent upset (not
really) at our attempted subversion of IPSec intent - we ended up
doing it the way he wanted even though my way would have been cleaner
grin/).

-Michael Heyman

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


security fail (from failblog)

2009-05-22 Thread mhey...@gmail.com
See http://failblog.org/2009/05/22/security-fail-5.

-Michael Heyman

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


Re: CPRNGs are still an issue.

2008-12-16 Thread mhey...@gmail.com
On Thu, Dec 11, 2008 at 8:42 PM, Damien Miller d...@mindrot.org wrote:
 On Thu, 11 Dec 2008, James A. Donald wrote:

 If one uses a higher resolution counter - sub
 microsecond - and times multiple disk accesses, one gets
 true physical randomness, since disk access times are
 effected by turbulence, which is physically true
 random.

 Until someone runs your software on a SSD instead of a HDD. Oops.

Before we give up on using drive timings, does anyone have evidence to
verify this assertion? The reviews I have seen using tools like HD
Tune and HD Tach seem to show timing noise reading and writing SSDs. I
don't know where the noise comes from - it is probably not turbulence
grin/ - but it may be random enough that a long series of tests, say
for a second or so (don't forget, these drives are fast), could
provide a nice pool of unguessable bits.

-Michael Heyman

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