Re: Merkle Signature Scheme is the most secure signature scheme possible for general-purpose use

[mhey...@gmail.com]

On Fri, Sep 3, 2010 at 10:29 AM, Jack Lloyd  wrote:
> On Fri, Sep 03, 2010 at 09:45:20AM +0100, Ben Laurie wrote:
>
> ...narrow-pipe designs have a huge null space for messages
> which are exactly as big as the compression function input
> size. For instance hashing inputs that are multiples of 512 bits,
> SHA-256 will only produce about 63% of the possible 2^256
> outputs.
>
So we deal with SHA-255.33 instead of SHA-256. Not a big enough
difference to worry about.

-Michael Heyman

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

Lasers crack commercial encryption systems

[mhey...@gmail.com]

From: 

   Quantum hackers have performed the first 'invisible' attack on two commercial
   quantum cryptographic systems...they have fully cracked their
encryption keys,
   yet left no trace of the hack..."Our hack gave 100% knowledge of
the key, with
   zero disturbance to the system," he says...In Makarov and colleagues' hack,
   Eve [blinds] Bob's detector — shining a continuous, 1-milliwatt
laser at it. While
   Bob's detector is thus disabled, Eve can then intercept Alice's signal...The
   cunning part is that while blinded, Bob's detector cannot function
as a 'quantum
   detector' that distinguishes between different quantum states of
incoming light.
   However, it does still work as a 'classical detector' — recording a
bit value of 1
   if it is hit by an additional bright light pulse, regardless of the
quantum properties
   of that pulse.



Michael HEyman

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

Verizon Business RISK data crime–investigation tea m's 2010 Data Breach Investigations Report

[mhey...@gmail.com]

I haven't read the report
,
except for the executive summary at the end of the pdf and another
summary here 
.
Note that 4 out of 5 victims subject to PCI-DSS had not achieved
compliance.

>From the executive summary:

WHO IS BEHIND DATA BREACHES?
70% resulted from external agents (-9%)
48% were caused by insiders (+26%)
11% implicated business partners (-23%)
27% involved multiple parties (-12%)

HOW DO BREACHES OCCUR?
48% involved privilege misuse (+26%)
40% resulted from hacking (-24%)
38% utilized malware (<>)
28% employed social tactics (+16%)
15% comprised physical attacks (+6%)

WHAT COMMONALITIES EXIST?
98% of all data breached came from servers (-1%)
85% of attacks were not considered highly difficult (+2%)
61% were discovered by a third party (-8%)
86% of victims had evidence of the breach in their log files
96% of breaches were avoidable through simple or intermediate controls (+9%)
79% of victims subject to PCI-DSS had not achieved compliance
 
Michael Heyman

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

Re: 2048-bit RSA keys

[mhey...@gmail.com]

On Tue, Aug 17, 2010 at 1:46 AM, Joseph Ashwood  wrote:
>
> The storage required for 2048 is approximately 2^64 bytes...
>
And from the density (1TB per cubic inch) in US Patent Application
20090094406, that gives about 70,000 gallons of memory or about 14 of
my father-in-law's average sized backyard swimming pools.

Dive in, the bits are the perfect temperature.

-Michael Heyman

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

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

[mhey...@gmail.com]

On Sun, Aug 1, 2010 at 7:10 AM, Peter Gutmann  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

[mhey...@gmail.com]

A Stick Figure Guide to the Advanced Encryption Standard (AES)
(A play in 4 acts)



-Michael Heyman

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

Re: Malware using good crypto

[mhey...@gmail.com]

On Sat, Aug 1, 2009 at 11:52 PM, Udhay Shankar N 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

[mhey...@gmail.com]

>From :

   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?

[mhey...@gmail.com]

On Thu, Jul 23, 2009 at 1:34 AM, Peter Gutmann wrote:
> "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?

[mhey...@gmail.com]

On Wed, Jul 22, 2009 at 1:43 AM, Nicolas
Williams 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.



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

-Michael Heyman

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

security fail (from failblog)

[mhey...@gmail.com]

See .

-Michael Heyman

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

Re: CPRNGs are still an issue.

[mhey...@gmail.com]

On Thu, Dec 11, 2008 at 8:42 PM, Damien Miller  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
 - 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