Re: TLS-SRP & TLS-PSK support in browsers (Re: Dutch Transport Card Broken)
On Sun, Feb 10, 2008 at 07:27:28PM +0100, Werner Koch wrote: > On Thu, 7 Feb 2008 16:37, [EMAIL PROTECTED] said: > > > I don't have any idea why or why not, but all they can release now is > > source code with #ifdef openssl >= 0.9.9 ... do PSK stuff ... #endif, > > The last time I checked the Mozilla code they used their own crypto > stuff. When did they switched to OpenSSL and how do they solve the > GPL/OpenSSL license incompatibility? > You are probably right about that, they use the "NSS" library. It is sometimes easy to forget that not all the world is OpenSSL... -- /"\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Toshiba shows 2Mbps hardware RNG
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
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
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
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: Toshiba shows 2Mbps hardware RNG
>EE Times: Toshiba tips random-number generator IC > > SAN FRANCISCO -- Toshiba Corp. has claimed a major breakthrough in > the field of security technology: It has devised the world's > highest-performance physical random-number generator (RNG) > circuit. > > The device generates random numbers at a data rate of 2.0 megabits > a second, according to Toshiba in a paper presented at the > International Solid-State Circuits Conference (ISSCC) here. I'm wondering if they've considered the possibility of EMI skewing the operation of the device, or other means of causing the device to genearate "less than completely random" numbers. It is certainly an interesting device; I think this would find considerable use in communication infrastructure and high-bandwidth applications. As someone else mentioned, generating a single, random, 128 bit seed is not too difficult with current technology, but it doesn't address the issue that often times you want more than just a single key. One of the problems with the Linux random number generator is that it happens to be quite slow, especially if you need a lot of data. Some potential uses: 1.) Secure file erasure. 2.) OTP keygen for those _really_ high security applications. 3.) Faster symmetric keyset generation. You know, when you need to build 32k keys... 4.) Random seeding of communication packets. There used to be (maybe still) a TCP spoofing exploit that relied on the timing of packets; there are also various de-anonymization attacks based on clock skew. With a chip like this, you could add a small, random number to the timestamp, or even packet delay, and effectively thwart such attacks. Such systems need high-bandwidth, random number generators. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Gutmann Soundwave Therapy
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]
Please steal my personal data [OK]
Jan Miksovsky (UI designer) has an interesting post on his blog about the phishing-friendly nature of Facebook apps. Consider the following scenario: You get a message from someone you know (well, someone on your Facebook friends list, which means a complete stranger you've never met before but who you added because whoever dies with the most entries on their list wins) saying "Hey, click on/run this!". "This" is an unknown app that (by default) has access to your information and embeds itself in your Facebook experience. Sound like a phishing attack? Nope, it's SOP for Facebook: http://miksovsky.blogs.com/flowstate/2008/01/facebook-applic.html Facebook (and who knows how may other sites): Hard at work training up the next generation of phishing victims. 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)
> "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
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
- Original Message - From: ""Hal Finney"" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; 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 > Lim&Lee 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)
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
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
[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
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]
