Re: More info in my AES128-CBC question

2007-05-12 Thread Leichter, Jerry
|  |   Frankly, for SSH this isn't a very plausible attack, since
|  |   it's not clear how you could force chosen plaintext into an
|  |   SSH session between messages.  A later paper suggested that
|  |   SSL is more vulnerable: A browser plugin can insert data into
|  |   an SSL protected session, so might be able to cause
|  |   information to leak.
|  |  
|  |  Hmm, what about IPSec?  Aren't most of the cipher suites used
|  |  there CBC mode?
|  | 
|  | ESP does not chain blocks across packets.  One could produce an
|  | ESP implementation that did so, but there is really no good reason
|  | for that, and as has been widely discussed, an implementation
|  | SHOULD use a PRNG to generate the IV for each packet.
|  I hope it's a cryptographically secure PRNG.  The attack doesn't
|  require any particular IV, just one known to an attacker ahead of
|  time.
|  
|  However, cryptographically secure RNG's are typically just as
|  expensive as doing a block encryption.  So why not just encrypt the
|  IV once with the session key before using it?  (This is the
|  equivalent of pre-pending a block of all 0's to each packet.)
| 
| But if the key doesn't change between messages then this makes the IV
| of the second block constant and if any plaintext repeats in the first
| block of plaintext then you have a problem.
I guess my proposal was ambiguous.  You don't use the encryption of
the *initial* IV for each packet; you use the encryption of what you
would otherwise have used as the IV, i.e., the last ciphertext block
of the previous packet.  The IV of the packet after that is just as
variable as it ever was.  (If it were not, then CBC would be just
about useless:  The CBC encryption of, say, the second block of two
all 0 blocks would always be the same!)
-- Jerry

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


Re: More info in my AES128-CBC question

2007-05-12 Thread Travis H.
On Wed, May 09, 2007 at 06:11:03PM -0400, Leichter, Jerry wrote:
 Just being able to generate traffic over the link isn't enough to
 carry out this attack.

Well, it depends on if you key per-flow or just once for the link.  If
the latter, and you have the ability to create traffic over the link,
and there's a 1-for-1 correspondence between plaintext and encrypted
packets, then you have a problem.

Scenarios include:

Private wifi network, you are sending packets at a customer from
unprivileged node on internet; you want known plaintext for the key
used to secure the wifi traffic, or you want the contents of his
connection.

Target is VPN'ed into corporate headquarters, you are sending packets
at them (or you send them email, they download it from their mail server)

-- 
Kill dash nine, and its no more CPU time, kill dash nine, and that
process is mine. -- URL:http://www.subspacefield.org/~travis/
For a good time on my UBE blacklist, email [EMAIL PROTECTED]


pgpEWNibI30LX.pgp
Description: PGP signature


Re: phone encryption technology becoming popular in Italy

2007-05-12 Thread Travis H.
On Wed, May 02, 2007 at 06:12:31PM +0100, Dave Korn wrote:
   If you wanted to be /really/ certain, I guess you'd have to take the tops
 off all the ICs inside and look at them under an EM, to make sure they really
 were the parts they claimed to be and don't have any extra circuitry or hidden
 functions built in

If the chips had more than a single layer, or even if they were single layer,
it's probably possible to hide some functionality.  I've heard of devices that
are capable of displaying the current flowing through the conductive regions
of the chip (electrons move just a little too fast to follow, about 1/4 the
speed of light in copper) but that's an awfully labor-intensive way to check
that everything is working to spec... it's probably cheaper to build it
yourself.

And then with respect to the non-crypto issues; are you going to cut open
every capacitor on the red signal path to check for, say, miniature FM
transmitters?

I'm reminded a bit of the US embassy in Moscow, where (using neutron
scanners) they found bugs in the girders that were the same density as
the steel, and so invisible to X-rays... in the end, they learned that
the only way to avoid these kinds of surprises was to use only their
own building materials and labor.

Earlier in this list tamper-resistant hardware was mentioned... the
downside of that is that unless you're the manufacturer, your attempts
to verify that it doesn't have any surprises look a whole lot like
the kind of tampering it is designed to resist...

It seems like this is a deep rabbit hole with no obvious end.
Probably the best one could hope for is to avoid targeted attacks,
where the opponent knows you are getting something and has it
customized for you.  Widespread (indiscriminate) compromisation is
probably impractical to detect. If you're a nation, or particularly
wealthy, then perhaps you can do it all yourself, but for high-tech
devices that can get very expensive.  History is littered with examples
where countries tried to create a domestic source for some strategic
good and failed miserably.

Incidentally, on my web page I have some pictures and code for a HWRNG
that an associate built (I wrote the software); he made a limited run
of 10 or so, but if anyone wants the schematics, you'll want to send a
SASE to Brad Martin at http://www.nshore.com/ (the plans are not in an
easy-to-email form and this method filters out all but serious
inquiries).  It is actually a pretty neat device, battery powered to
avoid 60Hz signal injection (you can use a wall wart if you want to
though, the filters are good) and even enters a power-saving mode when
not in use.  My software (written for Linux and BSD) supports a mode
where it allows the device to power down when /dev/random is above a
high water mark, and automatically powers it up when it drops below
it.  One person called it the most over-engineered RNG I have ever
seen.  I think the cost to build one is about $100-200, but Brad
spent $30k of unbillable time on this personal project, mostly on the
design.  It's a shame to see that only used on 10 units.

There are, incidentally, some open-source hardware web sites, where
they have schematics for various chips and cores... although you can't
just etch your own silicon, there are shops that do all of that for
you; you just email them the layouts and send them the money, and
they can do a small run of chips for reasonable prices.
-- 
Kill dash nine, and its no more CPU time, kill dash nine, and that
process is mine. -- URL:http://www.subspacefield.org/~travis/
For a good time on my UBE blacklist, email [EMAIL PROTECTED]


pgpBE4zRtMeSN.pgp
Description: PGP signature


RE: Was a mistake made in the design of AACS?

2007-05-12 Thread Ian Farquhar \(ifarquha\)
On Thu, May 03, 2007 at 10:25:34AM -0700, Steve Schear wrote:
 Well, there's an idea: use different physical media formats for entertainment 
 and non-
 entertainment content (meaning, content created by MPAA members vs. not) and 
 don't sell
 writable media nor devices capable of writing it for the former, not to the 
 public, keeping
 very tight controls on the specs and supplies.  [...]

Sony's UMD format is an example of this approach.  I doubt even the most 
reality-disconnected marketeers in Sony could call it
anything but an abject failure.  I also doubt any company other than Sony - 
which has a long history of believing it can control
the delivery format - would have even bothered.

Ian.

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


RE: Selective disclosure

2007-05-12 Thread Benny Pinkas
Following the Waldo proof, there is recent work showing how to convince
someone that you have solved a Sudoku puzzle without revealing the solution
(this is a recent paper by Gradwohl, Naor, Rothblum and myself). The paper
describes cryptographic and *physical* protocols for this task, accompanied
by rigorous definitions and analysis.
The paper and a demo are available at
http://www.wisdom.weizmann.ac.il/~naor/PAPERS/sudoku_abs.html

Benny Pinkas

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of James Muir
Sent: Monday, May 07, 2007 11:22 PM
To: cryptography@metzdowd.com
Subject: Re: Selective disclosure

I think the first people to consider i can find Waldo proofs were
Naor, Naor  Reingold.  You might want to add a reference to their paper 
Applied Kid Cryptography in your write-up:

http://www.wisdom.weizmann.ac.il/~naor/PAPERS/waldo_abs.html

-James


Ben Laurie wrote:
 I recently wrote a layman's introduction to selective disclosure which
 I thought might interest members of this list:
 http://www.links.org/files/selective-disclosure.pdf
 
 Cheers,
 
 Ben.
 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to
[EMAIL PROTECTED]

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

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


PRZ status

2007-05-12 Thread Jon Callas
He's out of surgery, doing well, and the doctors say he'll be better  
than he's been for ten years.


Jon

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


no surprise - Sun fails to open source the crypto part of Java

2007-05-12 Thread Ian G
Does anyone know what Sun failed to opensource in the crypto 
part of Java?


http://news.com.com/Open-source+Java-except+for+the+exceptions/2100-7344_3-6182416.html

They also involve some elements of sound and cryptography, 
said Tom Marble, Sun's OpenJDK ambassador. We have already 
contacted the copyright holders. We were unable to negotiate 
release under an open-source license, Marble said.


To sidestep the issue, Sun for now includes the proprietary 
software as prebuilt binary modules that programmers can 
attach to the versions of Java built from source code.


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


wiretaps and encryption

2007-05-12 Thread Steven M. Bellovin
Those who remember the Crypto Wars of the 1990s will recall all of the
claims about we won't be able to wiretap because of encryption.  In
that regard, this portion of the latest DoJ wiretap report is
interesting:

Public Law 106-197 amended 18 U.S.C. 2519(2)(b) to require that
reporting should reflect the number of wiretap applications
granted for which encryption was encountered and whether such
encryption prevented law enforcement officials from obtaining
the plain text of communications intercepted pursuant to the
court orders. In 2006, no instances were reported of encryption
encountered during any federal or state wiretap.

The situation may be different for national security wiretaps, but of
course that's where compliance with any US anti-crypto laws are least
likely.  There was no mention of national security or terrorism-related
wiretaps in the report, possibly because they've all been done with
FISA warrants.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

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


Re: More info in my AES128-CBC question

2007-05-12 Thread Nicolas Williams
On Wed, May 09, 2007 at 06:04:20PM -0400, Leichter, Jerry wrote:
 |   Frankly, for SSH this isn't a very plausible attack, since it's not
 |   clear how you could force chosen plaintext into an SSH session between
 |   messages.  A later paper suggested that SSL is more vulnerable:
 |   A browser plugin can insert data into an SSL protected session, so
 |   might be able to cause information to leak.
 |  
 |  Hmm, what about IPSec?  Aren't most of the cipher suites used there
 |  CBC mode?
 | 
 | ESP does not chain blocks across packets.  One could produce an ESP
 | implementation that did so, but there is really no good reason for
 | that, and as has been widely discussed, an implementation SHOULD use
 | a PRNG to generate the IV for each packet.
 I hope it's a cryptographically secure PRNG.  The attack doesn't require
 any particular IV, just one known to an attacker ahead of time.
 
 However, cryptographically secure RNG's are typically just as expensive
 as doing a block encryption.  So why not just encrypt the IV once with
 the session key before using it?  (This is the equivalent of pre-pending
 a block of all 0's to each packet.)

But if the key doesn't change between messages then this makes the IV of
the second block constant and if any plaintext repeats in the first
block of plaintext then you have a problem.

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


Re: More info in my AES128-CBC question

2007-05-12 Thread Travis H.
On Wed, May 09, 2007 at 06:04:20PM -0400, Leichter, Jerry wrote:
 However, cryptographically secure RNG's are typically just as expensive
 as doing a block encryption.  So why not just encrypt the IV once with
 the session key before using it?  (This is the equivalent of pre-pending
 a block of all 0's to each packet.)

There's many ways to deal with it if you're willing to do more crypts
per block.  For example, you could derive an independent key and use
that to encrypt a counter for IVs... becoming a cryptographically
strong permutation... that'd work as long as you didn't send so many
IVs that you ran through most of the cycle (the last value in the
cycle is 100% predictable).

-- 
Kill dash nine, and its no more CPU time, kill dash nine, and that
process is mine. -- URL:http://www.subspacefield.org/~travis/
For a good time on my UBE blacklist, email [EMAIL PROTECTED]


pgpYqqeHkErOq.pgp
Description: PGP signature


Ross Anderson paper on fraud, risk and nonbank payment systems

2007-05-12 Thread Steve Schear
[Read the paper here: 
http://www.cl.cam.ac.uk/%7Erja14/Papers/nonbanks.pdf  Very interesting 
stuff, but not likely new to most here.]



The Federal Reserve commissioned me to research and write a
paper on fraud, risk and nonbank payment systems. I found that
phishing is facilitated by payment systems like eGold and Western
Union which make the recovery of stolen funds more difficult.
Traditional payment systems like cheques and credit card payments
are revocable; cheques can bounce and credit card charges can be
charged back. However some modern systems provide irrevocability
without charging an appropriate risk premium, and this attracts
the bad guys. (After I submitted the paper, and before it was
presented on Friday, eGold was indicted.)

I also became convinced that the financial market controls used
to fight fraud, money laundering and terrorist finance have
become unbalanced as they have been beefed up post-9/11. The
modern obsession with 'identity' - of asking even poor people
living in huts in Africa for an ID document and two utility
bills before they can open a bank account - is not only ridiculous
and often discriminatory. It's led banks and regulators to take
their eye off the ball, and to replace risk reduction with due
diligence.

In real life, following the money is just as important as following
the man. It's time for the system to be rebalanced.

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


Re: Enterprise Right Management vs. Traditional Encryption Tools

2007-05-12 Thread Ali, Saqib

Hi Jon,


Rights management systems work against polite attackers. They are
useless against impolite attackers. Look at the way that
entertainment rights management systems have been attacked.
The rights management system will be secure so long as no one wants
to break them. There is tension between the desire to break it and
the degree to which its users rely on it. At some point, this tension
will snap and it's going to hurt the people who rely on it. A
metaphor involving a rubber band and that smarting is likely apt.


What about DRM/ERM that uses TPM? With TPM the content is pretty much
tied to a machine (barring screen captures etc)

Will ERM/DRM be ineffective even with the use of TPM?

Thanks
Saqib Ali

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


Re: Enterprise Right Management vs. Traditional Encryption Tools

2007-05-12 Thread Jon Callas


On May 9, 2007, at 5:01 PM, Ali, Saqib wrote:


Hi Jon,


Rights management systems work against polite attackers. They are
useless against impolite attackers. Look at the way that
entertainment rights management systems have been attacked.
The rights management system will be secure so long as no one wants
to break them. There is tension between the desire to break it and
the degree to which its users rely on it. At some point, this tension
will snap and it's going to hurt the people who rely on it. A
metaphor involving a rubber band and that smarting is likely apt.


What about DRM/ERM that uses TPM? With TPM the content is pretty much
tied to a machine (barring screen captures etc)

Will ERM/DRM be ineffective even with the use of TPM?

Thanks
Saqib Ali


Your comment of barring screen captures etc. is a bit like saying  
that won't a bank be safe from robberies barring someone waving a gun  
in a teller's face, etc. Yeah, sure, but doesn't that kinda miss the  
point? DRM works if the attackers are polite. The less polite they  
are, the less well it works.


DRM systems for media are probably more immune to analog hole  
attacks ERM systems. Imagine that someone ERM protected an email  
showing things that Gonzales couldn't remember when he was testifying  
to Congress, or in some stock scandal, etc. A photo of a screen with  
a cell phone camera would be sufficient. We have not (yet) seen an  
attack where someone got a pre-release of a movie and then pointed a  
camera at a laptop screen, but we will.


If you add in a TPM, it depends entirely on how impolite the  
attackers are, as well as the construction of the TPM. One of the  
recent attacks against AACS involved the attackers unsoldering the  
chip and attacking it directly. That's pretty rude, but it worked.


If someone is so impolite that they'll put the TPM chip under a  
scanning electron microscope, they can probably just read the bits  
off. Very few smart cards can survive that.


Remember, this is all a trade-off between the cost of the device and  
the devotion of the attacker. TPM chips have to be very cheap,  
because the customer is ultimately paying for it. That means its  
defenses can't be very thorough. Furthermore, while the owner of the  
device is the attacker, you can't afford very many defenses. If a  
music player, for example, went DOA because it it was dropped, went  
over/under temperature, and so on, it would be a financial nightmare,  
as you probably have to replace them under warranty. People who hate  
DRM would buy devices, monkeywrench them, and then demand a refund.


ERM systems have the advantage that in general the attackers are more  
polite. More people want to break AACS than rights-controlled analyst  
reports. However, once something really juicy happens, like just  
needing the content registration key for a document that will get a  
politician in jail -- well, plenty of people can hack that. Now, all  
of a sudden, the attackers won't be polite, and that metaphor I made  
about a rubber band snapping will seem modest.


Really, you're much better off with real crypto and personnel policies.

Jon

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


Re: Enterprise Right Management vs. Traditional Encryption Tools

2007-05-12 Thread Hagai Bar-El
Hello,

On 08/05/07 20:16, Ali, Saqib wrote:
 I was recently asked why not just deploy a Enterprise Right Management
 solution instead of using various encryption tools to prevent data
 leaks.
 
 Any thoughts?

The encryption tools function according to simple, well understood,
and more-or-less enforceable security models. Their assumptions are well
understood and, most importantly, match the environments they run on.
They solve a simple problem, and solve it effectively.

Rights management solutions have complex security models, and run in
environments that do not always satisfy the assumptions. They aim at
providing complex functionality, but they often (always?) fail to
deliver due to their over-complexity and unrealistic assumptions.

If your security needs can be met by the simple functional model of the
encryption tools, then you will prefer to enjoy the assurance and the
reasonable robustness they provide, which is the most desirable feature
after all.

Hagai.

-- 
Hagai Bar-El - Information Security Analyst
T/F: 972-8-9354152 Web: www.hbarel.com

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


Re: Ross Anderson paper on fraud, risk and nonbank payment systems

2007-05-12 Thread Allen



Steve Schear wrote:

[snip]


In real life, following the money is just as important as following
the man. It's time for the system to be rebalanced.


In fact, I believe, it is even more important because it is the 
snail trail that connects the people involved. Significant sized 
anti-social activities are very rarely one-man bands.


Given this, rather than requiring proof of identity to open bank 
accounts, etc, we should encourage transactions through the 
normal channels in order to better follow the money, if we are 
truly after criminals. All the extra controls do is force 
ordinary people who can't, for whatever reason, meet the proof of 
identity standards to create covert channels to transact their 
business. These then become the means the real crooks then use to 
commit whatever it is they do.


The best parallels I can think of are Prohibition and the War on 
Drugs. Look at the total chaos brought on by Prohibition. 
Fortunately we were wise enough to put a stop to that relatively, 
for social controls, quickly. The War on Drugs; however, we have 
not been as smart about, and now, just over 100 years later we 
are spending multi-billions to bring forth an occasional mouse 
displayed in screaming headlines.


Both Prohibition and the War on Drugs responded to each new 
general control by creating covert channels for transacting 
business. The $10,000 alert system created smurfing where 
deposits were always less. Now that they have instituted controls 
on transfers of $5,000 or more, guess what? I think you can see 
the trend. In addition by imposing general controls what they do 
is spread the work around. The crooks have to hire more people to 
do the work which creates a mindset in a larger number of people 
that laws oppress and that you are better off living outside the 
law.


To bring it back to encryption, what are the goals we are trying 
to achieve by using encryption? Are they goals whereby we create 
barriers between people? Or are the goals to assist people in 
creating connections that are secure and enhance trust? The tools 
themselves are neutral.


Best,

Allen

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


Re: no surprise - Sun fails to open source the crypto part of Java

2007-05-12 Thread Florian Weimer
* Ian G.:

 Does anyone know what Sun failed to opensource in the crypto part of
 Java?

The Sun JCE provider appears to be missing, which means that few
cryptographic algorithms are actually implemented in the source drop.
All the symmetric encryption algorithms are missing, for instance.

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


Re: no surprise - Sun fails to open source the crypto part of Java

2007-05-12 Thread Nicolas Williams
 Subject: Re: no surprise - Sun fails to open source the crypto part of Java

Were you not surprised because you knew that said source is encumbered,
or because you think Sun has some nefarious motive to not open source
that code?

If the latter then keep in mind that you can find plenty of crypto code
in OpenSolaris, which, unless you think the CDDL does not qualify as
open source, is open source.  I've no first hand knowledge, but I
suspect that the news story you quoted from is correct: the code is
encumbered and Sun couldn't get the copyright holders to permit release
under the GPL in time for the release of Java source under the GPL.

Nico
-- 

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


Re: no surprise - Sun fails to open source the crypto part of Java

2007-05-12 Thread Jack Lloyd
On Fri, May 11, 2007 at 04:42:47PM +0200, Ian G wrote:

 They also involve some elements of sound and cryptography, 
 said Tom Marble, Sun's OpenJDK ambassador. We have already 
 contacted the copyright holders. We were unable to negotiate 
 release under an open-source license, Marble said.

I believe at least some versions of Java used RSADSI's JSAFE for the
low-level crypto code, which would explain why that portion of it
wasn't included.

-Jack

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