Re: [Mac_crypto] Apple should use SHA! (or stronger) to authenticate software releases

[R. A. Hettinga]

[Moderator's note: I'm ending forwards/posts on this topic, unless
someone has something stunningly new to say. --Perry]

--- begin forwarded text


To: [EMAIL PROTECTED]
From: "Arnold G. Reinhold" <[EMAIL PROTECTED]>
Subject: Re: [Mac_crypto] Apple should use SHA! (or stronger) to
 authenticate software releases
Sender: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
List-Id: Macintosh Cryptography 
List-Post: 
List-Help: 
List-Subscribe: ,

List-Archive: 
Date: Tue, 13 Apr 2004 23:53:35 -0400

>On 13 Apr 2004, at 4:04, R. A. Hettinga wrote:
>>From: "Joseph Ashwood" <[EMAIL PROTECTED]>
>>>It's not clear to me that you need all this complexity.  All you need
>>>if to arrange that the attacker does not know exactly what will be
>>>signed until it has been signed.  So you append some randomness from a
>>>good random number source to the end of the file just before you sign
>>>it, and you're safe.
>>
>>I'm not quite sure that's a good solution, that random tail provides exactly
>>what the attacker needs to make this as easy as possible. Since the random
>>tail cannot be know beforehand it cannot be known by the user of the patch.
>>If anything this would actually make an attack easier. It is only if the
>>random data is from a _bad_ random source that you might actually gain some
>>security (a bad source would at the very least have redundancy, internal or
>>external, that could be verified by the end user, making it more complex to
>>compute valid numbers). Instead it would probably be more useful to include
>>the same random number between each file, this should short circuit all but
>>the most fatal of hash flaws, but might open up other possibilities (I don't
>>have the time right now to prove things about it).
>
>It's true that the putting randomness on the tail is a bad idea if
>the attacker stands any chance of controlling the supposedly random
>data.  That's why you need to buy a good solid hardware security
>module with the ability to limit the use of the signing keys to only
>be used by your custom code that adds hardware generated random
>padding!
>

I suppose it is educational to think about different ways to solve a
problem like this, but this is getting silly. All that is needed to
prevent my attack is to use calculate and publish the SHA1 hash along
with the MD5 hash. Easy as can be.  No special hardware required.

Arnold Reinhold
___
mac_crypto mailing list
[EMAIL PROTECTED]
http://www.vmeng.com/mailman/listinfo/mac_crypto

--- end forwarded text


-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

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

Re: AES suitable for protecting Top Secret information

[Vin McLellan]

I missed that announcement too -- but Wikipedia, the web-based Free 
Encyclopedia, caught it!  See Wikipedia on AES at: 
http://en.wikipedia.org/wiki/AES

The Wikipedia module on AES Security has a link to the same NSA fact sheet 
Steve mentioned.

I was surprised.  I thought, as in so many other things, the NSA was going 
to say one thing and do another.

Suerte,
_Vin
At 4/14/2004, Steve Bellovin wrote:

I haven't seen this mentioned on the list, so I thought I'd toss it
out.  According to http://www.nstissc.gov/Assets/pdf/fact%20sheet.pdf ,
AES is acceptable for protecting Top Secret data.  Here's the crucial
sentence:
   The design and strength of all key lengths of the AES algorithm
   (i.e., 128, 192 and 256) are sufficient to protect classified
   information up to the SECRET level. TOP SECRET information will
   require use of either the 192 or 256 key lengths.
 ---
 Vin McLellan + The Privacy Guild + <[EMAIL PROTECTED]>
   22 Beacon St., Chelsea, MA 02150-2672 USA
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: DRM of the mirror universe

[David Wagner]

Jani Nurminen  wrote:
>I had this idea about reversing the roles of the actors in a typical DRM
>system, and thinking about where it might lead.
[...]
>This kind of application of DRM would probably guarantee privacy of the
>personal data of each individual person, while at the same time allow
>companies access to that data with the consent of the user.

This kind of idea has been discussed before.  Personally, I'm not
convinced we're likely to see this take off any time soon.  There are
some technological barriers, but a bigger one may well be incentives.
I'd argue the true source of many privacy problems may be more from the
imbalance in bargaining power between the consumer and the corporation
(the corporation can often more or less dictate terms -- or, at least,
there is not much room for personalized negotiation and bargaining).
Fixing the power imbalance may well be a precondition to deploying
technology-based privacy defenses (be it DRM, or anything else).

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

Re: DRM of the mirror universe

[Barney Wolff]

On Tue, Apr 13, 2004 at 11:05:10PM +0300, Jani Nurminen wrote:
> 
> But what content could the consumer-become-content-provider, the
> ordinary person, you or me (let's call this actor the "user"), produce?
> What could be interesting and rare for the corporation but found in
> abundance from the user? One answer is personal data. 
> 
> Upon request by some corporation, the user decides to accept the
> request. The user creates a DRM-protected file containing the personal
> data the user wishes to reveal. When proper DRM technology is being used
> (the same technology used to protect e.g. movies), the user can be sure
> that the corporation is not able to 
>   * use the personal data after the license period (e.g. 2 hours) has
> expired
>   * share the personal data with third party companies without
> permission
>   * do other non-authorized nasty stuff with the personal data 

DRM only works because the supplier of the content has itself certified
the software used to process the content, or trusts the entity that
has certified the software.  Who would you trust to certify the software
that some corporation will use to process your personal data?

Another issue is that DRM works best to protect massive content.  For
example, whether you are HIV-positive is a single bit.  How would you
prevent me from capturing that bit from my screen with a camera?  If
the DRM prevents any association of your data with your identity, the
data will not be worth much to me.

Also, even assuming the DRM works, what prevents the user from presenting
false data?  The only data I can't lie about is what I generate as a
side-effect of something else, for example a click-stream.  But that's
already available reliably to the server(s) now, without DRM.

-- 
Barney Wolff http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.

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

Re: Definitions of "Security"?

[Anne & Lynn Wheeler]

At 08:01 AM 4/14/2004, [EMAIL PROTECTED] wrote:

Hi,

I'm looking for interesting and unusal defitions of the
term "Security" (or "secure")
there was a discussion on PAIN taxonomy for security earlier in the year 
... misc. references
http://www.garlic.com/~lynn/aadsm17.htm#3 Non-repudiation (was RE: The PAIN 
mnemonic)
http://www.garlic.com/~lynn/aadsm17.htm#5 Non-repudiation (was RE: The PAIN 
mnemonic)



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

Re: Definitions of "Security"?

[Lars Eilebrecht]

According to [EMAIL PROTECTED]:

> I'm looking for interesting and unusal defitions of the
> term "Security" (or "secure").

See http://en.wikipedia.org/wiki/Security


ciao...
-- 
Lars Eilebrecht
[EMAIL PROTECTED]

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

Re: DRM of the mirror universe

[Paul A.S. Ward]

Jani Nurminen wrote:

[...]
But what content could the consumer-become-content-provider, the
ordinary person, you or me (let's call this actor the "user"), produce?
What could be interesting and rare for the corporation but found in
abundance from the user? One answer is personal data. 

Upon request by some corporation, the user decides to accept the
request. The user creates a DRM-protected file containing the personal
data the user wishes to reveal. When proper DRM technology is being used
(the same technology used to protect e.g. movies), the user can be sure
that the corporation is not able to 
 * use the personal data after the license period (e.g. 2 hours) has
expired
 * share the personal data with third party companies without
permission
 * do other non-authorized nasty stuff with the personal data 

Using the "evil" DRM technology a very "good" (good and evil is
subjective!) purpose can be achieved: the preservation of the user's
privacy. 
 

Welcome to ACME.com.  In order to do business with ACME.com we require
that your personal data  be provided without restriction.  If you don't 
like that, no
problem.  Feel free to do business with others.

(Don't believe that?  Gee, how many websites require javascript, java, 
activeX?)

Paul

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

Re: Definitions of "Security"?

[Thierry Moreau]

[EMAIL PROTECTED] wrote:

Hi,

I'm looking for interesting and unusal defitions of the
term "Security" (or "secure").
I'm fully aware that it is difficult or impossible to give
a precise, compact, and universal definitions, and some
book authors explicitely say so. However, there are definitions
(or attempts to give those), and I'd be interested to compare
them. If you know of any definition that might be interesting
for any reason, please send me a link or citation. thanx
"a well-informed sense of assurance that information risks and controls 
are in balance"

From:
James M. Anderson, Why We Need a New Definition of Information Security, 
Computers & Security, vol 22, no. 4, May 2003, 2003, pages 308-313.

--

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
H2M 2A1
Tel.: (514)385-5691
Fax:  (514)385-5900
web site: http://www.connotech.com
e-mail: [EMAIL PROTECTED]
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Definitions of "Security"?

[hadmut]

Hi,

I'm looking for interesting and unusal defitions of the
term "Security" (or "secure").

I'm fully aware that it is difficult or impossible to give
a precise, compact, and universal definitions, and some
book authors explicitely say so. However, there are definitions
(or attempts to give those), and I'd be interested to compare
them. If you know of any definition that might be interesting
for any reason, please send me a link or citation. thanx

regards
Hadmut

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

AES suitable for protecting Top Secret information

[Steve Bellovin]

I haven't seen this mentioned on the list, so I thought I'd toss it 
out.  According to http://www.nstissc.gov/Assets/pdf/fact%20sheet.pdf ,
AES is acceptable for protecting Top Secret data.  Here's the crucial 
sentence:

   The design and strength of all key lengths of the AES algorithm
   (i.e., 128, 192 and 256) are sufficient to protect classified
   information up to the SECRET level. TOP SECRET information will
   require use of either the 192 or 256 key lengths.


--Steve Bellovin, http://www.research.att.com/~smb


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

Re: TCFS available for NetBSD-1.6.2

[Ivan Krstic]

VaX#n8 wrote:
I've done a survey of the various crypting file system tools, would anyone
be interested in a summary of available options?
This would likely be an interesting read for many on the list. Perhaps 
you can put up a PDF somewhere?

Cheers,
Ivan
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

DRM of the mirror universe

[Jani Nurminen]

Hello,

I had this idea about reversing the roles of the actors in a typical DRM
system, and thinking about where it might lead. I hope the idea will
stimulate some discussion: is the idea dead on arrival? Does it have
merit? Is it feasible? Is there something like this being built today?

Here goes... The main idea is this: the ordinary consumer (you or me)
becomes the "content provider". The content provider (the corporation)
becomes "the consumer". Thus, we have now reversed the roles.

But what content could the consumer-become-content-provider, the
ordinary person, you or me (let's call this actor the "user"), produce?
What could be interesting and rare for the corporation but found in
abundance from the user? One answer is personal data. 

Upon request by some corporation, the user decides to accept the
request. The user creates a DRM-protected file containing the personal
data the user wishes to reveal. When proper DRM technology is being used
(the same technology used to protect e.g. movies), the user can be sure
that the corporation is not able to 
  * use the personal data after the license period (e.g. 2 hours) has
expired
  * share the personal data with third party companies without
permission
  * do other non-authorized nasty stuff with the personal data 

Using the "evil" DRM technology a very "good" (good and evil is
subjective!) purpose can be achieved: the preservation of the user's
privacy. The user gets to decide who can receive and use the information
in the first place. The user can disallow use by companies the user
considers not to be trustworthy, or who he considers to be immoral, or
annoying, or who have the most idiotic advertisements. 

This kind of application of DRM would probably guarantee privacy of the
personal data of each individual person, while at the same time allow
companies access to that data with the consent of the user. To me this
seems like best of both worlds.

The role-reversal idea could help in achieving balance between the
concerns of the corporation and the concerns of the consumer, and
benefit all parties involved. At the very least, the idea can offer
possibilities for stimulating and interesting discussion. 

(Note: I wrote this originally as a blog article, and it's mostly copy +
paste from there with minor editing.. and some attitude removed :-) )

-- 
GPG 0x6EE92B3E - http://www.lut.fi/~jnurmine/



signature.asc
Description: This is a digitally signed message part

Re: [Mac_crypto] Apple should use SHA! (or stronger) to authenticate software releases

[Andy Isaacson]

On Mon, Apr 12, 2004 at 06:00:26PM -0700, Joseph Ashwood wrote:
> > From: Nicko van Someren <[EMAIL PROTECTED]>
> >
> > It's not clear to me that you need all this complexity.  All you need
> > if to arrange that the attacker does not know exactly what will be
> > signed until it has been signed.  So you append some randomness from a
> > good random number source to the end of the file just before you sign
> > it, and you're safe.
> 
> I'm not quite sure that's a good solution, that random tail provides exactly
> what the attacker needs to make this as easy as possible. Since the random
> tail cannot be know beforehand it cannot be known by the user of the patch.
> If anything this would actually make an attack easier. It is only if the
> random data is from a _bad_ random source that you might actually gain some
> security (a bad source would at the very least have redundancy, internal or
> external, that could be verified by the end user, making it more complex to
> compute valid numbers). Instead it would probably be more useful to include
> the same random number between each file, this should short circuit all but
> the most fatal of hash flaws, but might open up other possibilities (I don't
> have the time right now to prove things about it).

You and Nicko are discussing different attacks.

One attack is "Find two patches which have the same MD5".  This falls to
a birthday-paradox attack with 2^64 work, and is somewhat easier if the
patch format includes a random tail.  (The collision attack needs 64
bits of controllable input in the message.)  Short of a compromise of the
developer's machine, it's hard to see how this type of hash collision can
be leveraged into getting a malicious patch distributed as genuine.

Another attack is "Submit a carefully sculpted change through normal
channels which results in the new patch having an attacker-determined
hash value".  The work factor is somewhat difficult to estimate, but is
probably a significant multiple higher than 2^64, primarily due to the
more-complex iterator due to having to emulate the workflow of the
developer when computing hash values.  In this attack, the assumption is
that the attacker submits a diff (a very innocuous one, but with a
special structure), which is integrated, and the result is a (binary)
patch which is signed by the developer.  The attacker was able to craft
the diff so as to cause MD5(patchA) to match MD5(patchB) and then
distributes patchB with the signature from patchA.

This second attack is made infeasible by simply appending 64 bits of
randomness to the patch before signing it.  Since the attacker could not
possibly know those bits, so his work required increases by a *power* (I
believe -- haven't done the math carefully) of 64.

These are straightforward extensions of Van Oorschot & Wiener's 1994
paper "Parallel Collision Search with Application to Hash Functions and
Discrete Logarithms".

The obvious conclusion is that nobody should be using MD5 any more;
follow the OpenBSD project's lead and distribute SHA1 alongside your MD5
distribution.  Or SHA-256 if you're really paranoid.

> On a related note does anyone happen to know of any useful papers on
> patching, specifically patch integrity/source verification?

I don't see how this is any different from the generic source validation
problem.

-andy

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

Cryptonomicon.Net - Key Splitting : First (and Second) Person Key Escrow

[R. A. Hettinga]

 Key Splitting : First (and Second) Person Key Escrow
Date: Monday, April 12 @ 08:00:00 EDT
Topic: Algorithms / Asymmetric Cipher



 One of our missions here at Cryptonomicon.Net is to advocate the use of
appropriate cryptographic technology. One technology that's sorely missed
in a number of commercial products is key splitting. Never heard of key
splitting? That's not surprising. A recent google search on 'key-split' and
'key-splitting' turned up about 6000 results, while a search on 'PKI'
returned over a million hits. 'Secret Sharing', the technical term,
produces a few more hits, but not nearly as many as 'PKI'.




 Key Splitting, sometimes inaccurately called First Person Escrow, is a
technique by which some "secret" string of bits (like you're web server's
private key) is "split" into two or more "shares." The shares are
distributed to trusted individuals to hold safe until such time as they are
needed. In the event that your secret is destroyed (or more likely you
forget the PIN or password used to encrypt your web server's private key,)
the shares are recombined to recover the secret. Key Splitting is like an
insurance policy for your keys.

 There are more than a couple algorithms for creating key shares. Menezes,
et al.'s Handbook of Applied Cryptography presents the subject in a good
way. We especially like the Handbook of Applied Cryptography as a source,
as they provide a good deal of the math for math-minded implementors, but
also spend time discussing the development of ideas and algorithms. Readers
can also download sections of the "HAC" as .PDF's. Bruce Schneier's
perennial favorite Applied Cryptography also describes key splitting
algorithms, and for the less mathematically inclined has an expanded "plain
English" description.

 Why should you care about Key Splitting? With the growth of crypto-enabled
products: browsers, email clients, VPN clients, wireless access points, et
cetera; more and more people are using strong encryption to protect their
privacy or to establish their online identities. But in the rush to get
products out the door, sometimes product managers forget to support proper
key management techniques. While we've yet to see a product that gives out
it's private keys to anyone who asks, we have seen a number of products
where keys are encrypted under device master keys. What happens if you lose
the device master key? Well... the answer from the support people is "don't
lose the master key!" Some of these products have master keys derivable
from serial numbers and salt values. One product we've seen (and you know
who you are) derives it's device master key from it's serial number without
salting. An attacker wishing to steal the device's master key (and all of
the keys it protects) needs only to hash all possible serial numbers. As
there were less than 10,000 of these devices made, this is certainly a
tractable problem for an attacker.

 Key Splitting allows your IT staff to essentially back up the
cryptographic module protecting your sensitive secret and private keys. If
you're thinking that this sounds like it could be a security problem, then
give yourself a few extra points. Key Splitting systems should be used in
conjunction with a well defined IT process to protect the integrity of the
system. There are, fortunately, several examples of how to properly do key
splitting from a procedural point of view; your local CISSP should be able
to find a process that works for you as it's unlikely that any one process
will work for ALL environments.

 If you are in a position where you specify security features for your IT
infrastructure, surprise your sales rep by asking "What key splitting
features does your product support?" Give the supplier extra points if the
sales rep understands what you're asking.

 If you are a product manager, please add key splitting to the list of key
management features in your product. Security is playing a larger role in
modern IT systems, and customers are starting to add modern key management
features to their list of "best common practices." By supporting your
customers' practices, you're only making your products more marketable.







 This article comes from Cryptonomicon.Net
http://www.cryptonomicon.net/

 The URL for this story is:
http://www.cryptonomicon.net//modules.php?name=News&file=article&sid=742

-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

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

Re: my periodic rant on quantum crypto

[David Honig]

At 03:37 PM 4/12/04 -0400, Perry E. Metzger wrote:
>
>QC can only run over a dedicated fiber over a short run, where more
>normal mechanisms can work fine over any sort of medium -- copper, the
>PSTN, the internet, etc, and can operate without distance limitation.


Nice essay.  I especially liked the discussion of authentication.

Its also the case AFAIK that the quantum-carrying fiber
can only carry one photon at a time.  (Perhaps you can multiplex
different frequencies, if your demultiplexor doesn't change the
quantum properties).  Now while there *is* a lot of dark fiber,
sending one photon at a time is a pretty good way to keep the
construction crews digging up roads :-) 

Similar quantum-hype is sometimes argued in RNG discussions
by those with very narrow views of what an RNG needs and
consists of.



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