Re: Toshiba shows 2Mbps hardware RNG

2008-02-13 Thread Pat Farrell

Perry E. Metzger wrote:

[EMAIL PROTECTED] (Peter Gutmann) writes:

I've always wondered why RNG speed is such a big deal for anything but a few
highly specialised applications.


Perhaps it isn't, but any hardware RNG is probably better than none
for many apps, and they've managed to put the whole thing in a quite
small bit of silicon. The speed is probably icing on the cake.


One of the benefits of speed is that you can use cleanup code to control 
bias. Carl Ellison put some out on his website last century.



--
Pat Farrell
http://www.pfarrell.com/

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


Re: Toshiba shows 2Mbps hardware RNG

2008-02-13 Thread David G. Koontz
Hal Finney wrote:
 
 Looking at the block diagram for the new Toshiba circuit, and comparing
 with the Intel design, one concern I have is with attacks on the device
 via external electromagnetic fields which could modulate current flows
 and potentially influence internal random numbers. Intel attempted
 to mitigate this attack by using a pair of resistors spaced close
 together, and taking differentials between them. I don't see any such
 countermeasures in the (admittedly crude) block diagram in the Toshiba
 press release.
 


From the EE Times article, the stochastic noise source for the Toshiba RNG
is from a trap layer of Silicon Nitride in a MOSFET transistor.  An Analog
to Digital Converter is used as a gating amplifier and the random noise bit
rate is dependent on the conversion speed instead of transformer etc.impulse
response.  The difference in size between the 2 Mb/s  and 10 Mb/s RNG appear
to be due to A/D converter area (from the ISSCC session 22 advanced program).


http://www.toshiba.co.jp/rdc/rd/detail_e/e0704_03.html

It's a floating gate structure.

  it is clear from the figure that the SiN MOSFET device generates greater
current fluctuation. This is presumably because more frequent occurrence of
electron capture and emission between the Si channels and dangling bonds
owing to the remarkably large number of the traps that cause noise
generation makes possible generation of a large amount of noise. Also, the
SiN MOSFET?s ID fluctuation makes it possible to generate a larger amount of
random noise due to the respective parameter designs of the devices (gate
length, gate width, tunnel oxidized film thickness (Tox), the Si/N atomic
ratio). 

The more signal, the higher the noise immunity, presumably.  The
description reminds me of tube thermionic noise.   I'd suspect it would
benefit from a drawing done on a rotated axis showing the Trap layer as a 2D
array.

You get a random noise source that doesn't require the cryptographic
boundary be pushed into instruction/procedural space or across chip
boundaries for RNG generation, avoiding those pesky predictable random
numbers as attributed to a Microsoft software implementation recently.

Military silicon already has RNG on chip (e.g. AIM, Advanced INFOSEC
Machine, Motorola), you wonder if someone would consider an FPGA with a good
RNG hard core cell on chip, now that someone has figured out how to do
red/black separation in an FPGA compiler.  Wonder how cheap it is to spot
dope SiN or will we have to switch to anti-fuse FPGAs to take advantage?







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


Re: Open source FDE for Win32

2008-02-13 Thread Ali, Saqib
I installed TrueCrypt on my laptop and ran some benchmark tests/

Benchmark Results:
http://www.full-disk-encryption.net/wiki/index.php/TrueCrypt#Benchmarks

Pros:
1) Easy to use product. Simple clean interface. Very user-friendly!
2) Free and Open Source
3) Multiple Encryption and Hashing algorithm available.

Cons:
1) Buffered Read and Buffered Transfer Rate was almost halved after
TrueCrypt FDE was enabled :-(.
2) Access Time for large file (250+MB) increased by 11%.
3) The initial encryption of the 120 GB HDD took 2 hours.




On Feb 7, 2008 11:46 PM, Hagai Bar-El [EMAIL PROTECTED] wrote:
 List,

 Finally, an open source FDE (Full Disk Encryption) for Win32. It is the
 first one I am aware of:

 www.truecrypt.org

 TC is not a new player, but starting February 5th (version 5) it also
 provides FDE.

 Didn't get to try it yet.

 Hagai.


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


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


Dilbert on security

2008-02-13 Thread Leichter, Jerry

Today's Dilbert -

http://www.unitedmedia.com/comics/dilbert/archive/images/dilbert23667240080211.gif

is right on point
-- Jerry

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


Re: Gutmann Soundwave Therapy

2008-02-13 Thread Peter Gutmann
Daniel Carosone [EMAIL PROTECTED] writes:
On Mon, Feb 04, 2008 at 02:48:08PM -0700, Martin James Cochran wrote:
 Additionally, in order to conserve bandwidth you might want to make a
 trade-off where some packets may be forged with small probability (in the
 VOIP case, that means an attacker gets to select a fraction of a second of
 sound, which is probably harmless)

This is ok, if you consider the only threat to be against the final endpoint:
a human listening to a short-term, disposable conversation. I can think of
some counter-examples where these assumptions don't hold:

- A data-driven exploit against an implementation vulnerability in your codec
  of choice.  Always a possibility, but a risk you might rate differently (or
  a patch you might deploy on a different schedule) for conversations with
  known and trusted peers than you would for arbitrary peers, let alone
  maliciously-inserted traffic. How many image decoding vulnerabilities have
  we seen lately, again?
[...]
Particularly for the first point, early validation for packet integrity in
general can be a useful defensive tool against unknown potential
implementation vulnerabilities.

This is an example of what psychologists call own-side bias (everyone thinks
like us), in this case the assumption that after a peer has authenticated
itself it'd never dream of sending a malformed packet and so we don't need to
do any checking after the handshake has completed.  Why would you trust data
coming from a remote system just because they've jumped through a few hoops
before sending it?  I can steal the remote system's credentials or hijack the
session and then send you anything I want, it's no safer to blindly accept the
data if there's a MAC attached or not.

More scarily, and specifically for the case of VoIP, the security of many SIP
devices is absolutely appalling (for German speakers there's a paper on this
at the DFN-Cert workshop in a few days,
https://www.dfn-cert.de/events/ws/2008/programm.html).  So the obvious attack
vector is to 0wn the peer's SIP device and ensure that it creates malformed
data packets well before the security layer ever takes effect.  As a result
your secured tunnel is pouring out carefully authenticated attack packets as
fast as it can send them.  The bad guys have been exploiting this for years,
spamming their malware out to trusted friends on contact lists, and it's
proven quite successful.

Hostile data inside a secure tunnel or wrapper is still hostile data.  As the
OP said, as long as you can deterministically detect attacks (which a 1-of-n
packet MAC will do) you're not giving up much security by not MAC'ing all
packets.

Peter.

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


Re: TLS-SRP TLS-PSK support in browsers (Re: Dutch Transport Card Broken)

2008-02-13 Thread James Cloos
 Werner == Werner Koch [EMAIL PROTECTED] writes:

Werner The last time I checked the Mozilla code they used their own crypto
Werner stuff.  When did they switched to OpenSSL and how do they solve the
Werner GPL/OpenSSL license incompatibility?

Indeed they do.  It is called nss, is available as a package of its own
on several dists, is written in C, is MPL|GPL|LGPL and has its own page at:

http://www.mozilla.org/projects/security/pki/nss/

The Gentoo ebuild even installs a pkgconfig file.

I don't recall seeing anything !zilla using it, though.

-JimC
-- 
James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6

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


Re: Open source FDE for Win32

2008-02-13 Thread Hagai Bar-El

Hello,

On 11/2/2008 06:13, Ali, Saqib wrote:

I installed TrueCrypt on my laptop and ran some benchmark tests/

Benchmark Results:
http://www.full-disk-encryption.net/wiki/index.php/TrueCrypt#Benchmarks

Pros:
1) Easy to use product. Simple clean interface. Very user-friendly!
2) Free and Open Source
3) Multiple Encryption and Hashing algorithm available.

Cons:
1) Buffered Read and Buffered Transfer Rate was almost halved after
TrueCrypt FDE was enabled :-(.
2) Access Time for large file (250+MB) increased by 11%.
3) The initial encryption of the 120 GB HDD took 2 hours.



Actually, there is one major (but temporary) limitation to TC5: It does 
not process too well partitions that are not the system partition, but 
which share the same physical drive as the system partition, if you 
elect to encrypt the entire drive.


That is, if you decide to encrypt a whole physical drive that stores 
both C: (system) and D: (another partition), you are going to face a 
situation in which your D: partition is logically gone (until you 
re-decrypt the whole thing back). Next version will fix it, the team 
promises.


Hagai.


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


Re: questions on RFC2631 and DH key agreement

2008-02-13 Thread Joseph Ashwood
- Original Message - 
From: Hal Finney [EMAIL PROTECTED]

To: [EMAIL PROTECTED]; cryptography@metzdowd.com
Sent: Sunday, February 10, 2008 9:27 AM
Subject: Re: questions on RFC2631 and DH key agreement



Joseph Ashwood writes:

From: Hal Finney [EMAIL PROTECTED]
 Joseph Ashwood writes, regarding unauthenticated DH:
 if b uses the same private key
 to generate multiple yb the value of b will slowly leak.

 I'm not familiar with this last claim, that the value of b's private 
 key
 (presuming that is what you mean) would slowly leak if it were reused 
 for

 many DH exchanges. Can you explain what you mean? Are you talking about
 LimLee style attacks where the recipient does not check the parameters
 for validity? In that case I would say the private exponent would leak
 quickly rather than slowly. But if the parameters are checked, I don't
 see how that would leak a reused exponent.

I am not immediately aware of any known attacks that have been published
about it, but it is fairly obvious that Eve has more information about 
the

private key by having a second key set with the same unknown. With only a
single pair Eve's information set is:
g_1,p_1,q_1,y_1 where y_1 = g_1^x mod p_1

By adding the second key set Eve now has
g_1,p_1,q_1,y_1 where y_1 = g_1^x mod p_1
g_2,p_2,q_2,y_2 where y_2 = g_2^x mod p_2

This is obviously additional information, and with addition key set _i
eventually Eve has the information to guess x with improves probability.


That's hardly grounds for saying that the value of the secret will
slowly leak. You have given no reason to believe that this information
will be of any practical value to Eve.


We obviously disagree. Security is alway about information control, and 
disclosing additional information for no gain is always a bad idea.


Expressing the equations differently:
Y_i = g_i^X - k_i*p_i
is equivalent to
Y_i = g_i^X mod p_i

Since Y_i, g_i, and p_i are known, k_i is irrelevant, and g_i and p_i can 
even be chosen, simple algebra shows that not all Xs can be discovered from 
a given set, but it also says that sets of possible X can be determined from 
each triple, and by choosing g,p the overlap of the sets can be reduced. 
Creating an oracle for Y,g,p triples out of the client is begging for an 
adaptive attack.



After all, exactly the same observation might be made about a digital
signature, that each signature gives additional information about the
private exponent.


Actually there is an additional random variable in the signature, and 3 
additional k_i so the algebra says that the sets will overlap simply too 
much for a similar set-based attack to work.


This is a largely fuzzy-logic based attack. And while I obviously haven't 
sorted it through that far should allow for a probability sorting of values 
for X.
   Joe 


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


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-13 Thread Philipp Gühring
Hi,

 Microsoft broke this in IE7... It is no longer possible to generate and
 enroll a client cert from a CA not on the trusted root list. So private
 label CAs can no longer enroll client certs. We have requested a fix,
 so this may come in the future, but the damage is already done...

 Also the IE7 browser APIs for this are completely different and rather
 minimally documented. The interfaces are not portable between browsers,
 ... It's a mess.

I can fully confirm this.

Microsoft claimed that they had to rewrite the API to make it more secure, but 
I only found one small security-relevant weakness that they fixed, the others 
are still there. (And even that fix wouldn´t have justified a rewrite of the 
API for websites. They could have kept the frontend-API compatible in my 
opinion.)

I had the feeling that Microsoft wants to abandon the usage of client 
certificates completely, and move the people to CardSpace instead.
But how do you sign your emails with CardSpace? CardSpace only does the 
realtime authentication part of the market ...

If anyone needs more information how to upgrade your Web-based CA for IE7:
http://wiki.cacert.org/wiki/IE7VistaSource

Best regards,
Philipp Gühring

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


Re: Gutmann Soundwave Therapy

2008-02-13 Thread Daniel Carosone
On Mon, Feb 11, 2008 at 07:01:07PM +1300, Peter Gutmann wrote:
 Daniel Carosone [EMAIL PROTECTED] writes:
 [...]
 Particularly for the first point, early validation for packet integrity in
 general can be a useful defensive tool against unknown potential
 implementation vulnerabilities.
 
 This is an example of what psychologists call own-side bias (everyone thinks
 like us), in this case the assumption that after a peer has authenticated
 itself it'd never dream of sending a malformed packet and so we don't need to
 do any checking after the handshake has completed.  Why would you trust data
 coming from a remote system just because they've jumped through a few hoops
 before sending it?  I can steal the remote system's credentials or hijack the
 session and then send you anything I want, it's no safer to blindly accept the
 data if there's a MAC attached or not.

Point taken, but I respectfully disagree with the relevance in the
present context, though of course I agree entirely in the wider
philosophical sense.

Remember that we're also talking about practical deployment decisions:
 - if someone steals credentials, they can do all sorts of mischief
   and damage; the incremental risk in the present discussion is that
   doing 'lossy'/partial validation may allow additional injection and
   MITM attacks beyond those.
 - especially for the other cases I gave (SNMP and NTP), the
   alternative mitigating controls are such strong things as IP
   address based ACLs (on UDP packets). I'll take the stronger tool if
   it's on offer.

The fact this kind of authentication is applied before the packet gets
to more complex and potentially vulnerable parsing and processing code
gives me a valuable opportunity to be defensive, especially as an end
customer deploying some random vendor's kit.

In those cases, I don't have visibility of the implementation, but I
do have some assurance about the order of operations and can put that
structural knowledge to good use.  Much the same is true in this
discussion about protocol design; we're making no specifications about
processing of the data once the transport hands it off, but we're
starting to make assumptions about the risks therein, and the reliance
those layers may be placing on the transport, for better or worse.

Your criticism would be fair if I was advocating blindly accepting the
data or not doing any checking after the initial handshake.  It would
be fair criticism of a codec vendor who took such a stance, relying
overly on transport authentication (or forcing me to). I am most
certainly not advocating that, merely recognising that sometimes such
checking may be deficient or vulnerable, or just simply uncertain. 

Good defensive protocol design lets me validate the blob before
inspecting the fields; poor defensive programming conflates frame
validation with more detailed syntactic and semantic validation later.

If there are authentication-hijacking vulnerabilities in the endpoints
(like your SIP gateway), sure, I'm screwed in a number of ways.
That's sad, but a given regardless of whatever variant and detail of
keying and MACing mechanism this discussion comes up with.

 Hostile data inside a secure tunnel or wrapper is still hostile data. 

If cryptography can come up with some way to ensure robustness against
hostile data all the way down an implementation stack, regardless of
layering, we'll all be surprised.  Some of us might even be very rich.

Otherwise, it's a risk mitigation tool, subject to constraints we need
to understand.  If the constraints are ones of key management and
endpoint security, I can use the mechanism in my toolkit.  If the
constrains mean that every fourth SNMP request or routing update will
be unauthenticated, it's much less use to me as a structural security
layer; the bar isn't raised in any practical sense.

 As the OP said, as long as you can deterministically detect attacks
 (which a 1-of-n packet MAC will do) you're not giving up much
 security by not MAC'ing all packets.

I attempted to illustrate, with some counterexamples, threat models
where even one unauthenticated packet could lose you more than not
much security.  Threats where detection of the attack wasn't enough,
or was too late, or was itself the point.

Robust implementation behind that MAC is essential, and helps realise
and provide assurance around not much, as well as addressing broader
threats that are more likely in the overall economic argument we
acknowledged at the outset, but is outside what I saw as the OP's
scope, and not part of the incremental risk I was highlighting.

--
Dan.

pgpHBm0jjURiV.pgp
Description: PGP signature


Re: Toshiba shows 2Mbps hardware RNG

2008-02-13 Thread Peter Gutmann
[EMAIL PROTECTED] (Hal Finney) writes:

When the Intel RNG came out several years ago, built into the bus controller
chipset, it was not widely accepted by the cryptographic community due to
fears of back doors or internal weaknesses. A generally positive analysis by
Cryptographic Research (http://www.cryptography.com/intelRNG.pdf) failed to
assuage these concerns.

I think a much bigger reason for its non-acceptance was that it wasn't there
(either present or available or accessible) in most cases.  The PRNG in VIA's
C7 series hasn't had any of these problems, and is supported out of the box by
a pile of software and even some distros (typically via /dev/random).

Peter.

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


Re: Toshiba shows 2Mbps hardware RNG

2008-02-13 Thread Peter Gutmann
Danilo Gligoroski [EMAIL PROTECTED] writes:
At 04:02 AM 2/10/2008, Peter Gutmann wrote:
Perry E. Metzger [EMAIL PROTECTED] writes:

\snip
So your potential market for this is people running Monte Carlo simulations
who don't like PRNGs.  Seems a bit of a limited market...

I think that the market is a little bit bigger than just applications running
Monte Carlo simulations. For example, Gambling industry - which is also multi-
billion industry world-wide.

The security target for the gambling industry is to pass (incredibly
stringent) auditing requirements.  A simple PRNG seeded from a factory-set
initial value is fine as long as it's been certified to death.  The impression
I got from this some time ago from people who work in this area was that they
really wanted deterministic PRNGs rather than nondeterministic hardware ones,
although at the time I didn't ask whether it was because it made certification
easier or because they just didn't trust unpredictable RNGs (unpredictable
meaning that an infinite number of environmental variations can cause it to
potentially do things that you don't want).

Peter.

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