Re: [Cryptography] XORing plaintext with ciphertext

2013-09-07 Thread Florian Weimer
* Dave Horsfall:

 Take the plaintext and the ciphertext, and XOR them together.  Does the 
 result reveal anything about the key or the painttext?

Yes, their length.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] Snowden fabricated digital keys to get access to NSA servers?

2013-07-04 Thread Florian Weimer
* John Gilmore:

 [John here.  Let's try some speculation about what this phrase,
 fabricating digital keys, might mean.]

Most likely, as part of his job at the contractor, he had
administrator access to a system which was used for key management,
perhaps to apply security updates, manage backups or fix the
occasional glitch.  This is precisely the kind of low-level grunt work
that I expect is outsourced to contractors.

It's also possible that he was directly charged with key management.
I can image that someone thought that as long as some agency committee
made the actual decisions, it was fine to hire an external data typist
who entered the committee decision in to the key management system.

It's really funny that NSA-level security has now turned pejorative.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: ciphers with keys modifying control flow?

2010-09-29 Thread Florian Weimer
* Steven Bellovin:

 Does anyone know of any ciphers where bits of keys modify the
 control path, rather than just data operations?

AES.  See François Koeune, Jean-Jacques Quisqater, A timing attack
aganst Rijndael. Université catholique de Louvain, Technicl Report
CG-1999.

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


Re: Obama administration revives Draconian communications intercept plans

2010-09-28 Thread Florian Weimer
   Essentially, officials want Congress to require all services that
   enable communications — including encrypted e-mail transmitters like
   BlackBerry, social networking Web sites like Facebook and software
   that allows direct “peer to peer” messaging like Skype — to be
   technically capable of complying if served with a wiretap order. The
   mandate would include being able to intercept and unscramble
   encrypted messages.

Isn't this just a clarification of existing CALEA practice?

In most jurisdictions, if a communications services provider is served
an order to make available communications, it is required by law to
provide it in the clear.  Anything else doesn't make sense, does it?
Service providers generally acknowledge this (including Research In
Motion, so I don't get why they are singled out in the article).

There are indications that governments have access to Skype these
days  Here's a blog post mentioning it:

http://www.lawblog.de/index.php/archives/2010/08/17/skype-staat-hort-mit/

(Udo Vetter is sometimes a bit sensationalist, though.)  Another
indicator is that German law enforcement no longer calls for new laws
granting them access to Skype traffic.

In any case, the cleartext requirement for lawful intercept has always
been very public.  Oddly enough, it has not been perceived as some
sort of crypto regulation, although it puts some constraints on key
management. 

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


Re: Haystack redux

2010-09-27 Thread Florian Weimer
* Adam Fields:

 I find it hard to believe that even the most uninformed dissidents
 would be using an untested, unaudited, _beta_, __foreign__ new service
 for anything. Is there any reason to believe otherwise?

I wouldn't be surprised if there are plenty such tools in circulation
which are used by various dissident groups.  It's a cost-effective way
to infiltrate them.

The problem with such tools is that you can't really know how is
listening in on the proxies.  Even if the software itself contains no
backdoors, the service as a whole might still be compromised.  Even if
the proxies are trustworthy, your usage of the tool can very likely be
discovered by traffic analysis (and usage patterns as well, if you're
unlucky, and increasingly so if the service has low latency).

There is no technical solution to oppressive governments (or
non-trustworthy ISPs, for that matter).  After all, if you're
anonymous and oppressed, you're still oppressed.

-- 
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

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


Re: towards https everywhere and strict transport security

2010-08-26 Thread Florian Weimer
* James A. Donald:

 Every time you layer one communication protocol on top of another, you
 get another round trip.

In this generality, this is not true at all.  You're confusing
handshakes with protocol layering.  You can do the latter without the
former.  For example, DNS uses UDP without introducing additional
round trips because there is no explicit handshake.  Lack of handshake
generally makes error recovery quite complex once there are multiple
protocol versions you need to support, but handshaking is *not* a
consequence of layering.

-- 
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

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


Re: MITM attack against WPA2-Enterprise?

2010-07-26 Thread Florian Weimer
* Donald Eastlake:

 It's always possible to make protocols more secure at higher cost.

On the other hand, group key vulnerabilities are nothing new.  It's
just that many protocol designers seem to not understand them.  Back
when Cisco proposed XAUTH for IPsec, there was a heated discussion
about password strength and other irrelevancies, but as far as I could
later reconstruct the discussion, no one objected to the group key
concept as such.  It was only much later, when people used XAUTH in
large deployments for providing general Internet access over insecure
media, that the group key was recognized as a vulnerability.

It's amazing that people still fail for this group key thing.  There
is quite a simple rule: If you choose the secret bits without
constraints (except length and formatting), and proceed to share those
bits, there can be no protection from those with whom you share, no
matter what cryptographic algorithms you use.

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


Re: Encryption and authentication modes

2010-07-23 Thread Florian Weimer
* David McGrew:

 can I ask what your interest in AEAD is?  Is there a particular
 application that you have in mind?

I just want to create a generic API which takes a key (most of the
time, a randomly generated session key) and can encrypt and decrypt
small blobs.  Application code should not need to worry about details
(except getting key management right, which is difficult enough).
More popular modes such as CBC lack this property, it's too easy to
misuse them.

I suppose a superficially similar primitive is contained in
Bernstein's NaCl library.  I was intrigued by its simplicity, but the
cryptographic algorithms it uses are a bit non-standard.

Right now, I would probably use it to forward session state through
browser URLs in areas which are not actually security-relevant.
Somewhat more sensitive applications are possible in the future.  In
no case I expect adversaries to actually have access to ciphertext.
To some degree, it's about being able to say yes, we use encryption
for X, and it's algorithm Y, and I want to do it right without using
CMS or modern OpenPGP, with all the complexities that come with that.

When I said that CCM wasn't widely implemented, I was referring to the
fact that none of the cryptographic libraries on my system supports it
directly.  This is a pity because once you fix the parameters, it's
much simpler to use safely than pure encryption modes.

There seems to be one downside with the CCM instance specified towards
the end of the NIST standard, though: If you on an architecture where
sizeof(size_t) == 8, then your encryption function isn't total because
it can't accept the full range of possible input lengths---or you end
up with just 64 bit for the tag, which seems to be a bit on the small
side.  I'm not sure if this is a compelling reason to use EAX or GCM,
though---especially since we're strictly limited to 31 bit array
length in some places by software and not hardware (so this limitation
will be in place for a long time).

A mode which does not rely as much on proper randomness for the IV
would be somewhat nice to have, but it seems that the only choice
there is SIV, which has received less scrutiny than other modes.

 OCB is very attractive in software, but GCM is more efficient in
 hardware because it can be implemented without pipeline stalls.  GCM
 can perform well in software, though it can't be as compact as CCM,
 and it excells with SIMD (http://eprint.iacr.org/2009/129) or modest
 hardware support like Intel's new PCLMULQDQ instruction
 (http://www.drdobbs.com/security/218102294;jsessionid=GMTY4RCFLHBMRQE1GHOSKHWATMY32JVN?pgno=3
 ).

Interesting.  But it will take about five years until our crypto code
would make use of a new hardware instruction, assuming that we'd
implement all the necessary pieces right now (thanks to desynchronized
software release cycles at several layers of the software stack).
Speed is of no particular concern anyway.  Increase in message size is
somewhat relevant (think about the URL case I mentioned), but only to
up to a degree.

-- 
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

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


Encryption and authentication modes

2010-07-14 Thread Florian Weimer
What's the current state of affairs regarding combined encryption and
authentication modes?

I've implemented draft-mcgrew-aead-aes-cbc-hmac-sha1-01 (I think, I
couldn't find test vectors), but I later came across CCM and EAX.  CCM
has the advantage of being NIST-reviewed.  EAX can do streaming (but
that's less useful when doing authentication).  Neither seems to be
widely implemented.  But both offer a considerable reduction in
per-message overhead when compared to the HMAC-SHA1/AES combination.

Are there any other alternatives to consider?  Are there any traps I
should be aware of when implementing CCM?

-- 
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

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


Re: What's the state of the art in factorization?

2010-04-22 Thread Florian Weimer
* Thierry Moreau:

 For which purpose(s) is the DNS root signature key an attractive
 target?

You might be able to make it to CNN if your spin is really good.

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


Re: What's the state of the art in factorization?

2010-04-22 Thread Florian Weimer
* Thierry Moreau:

 Florian Weimer wrote:
 * Thierry Moreau:

 For which purpose(s) is the DNS root signature key an attractive
 target?

 You might be able to make it to CNN if your spin is really good.

 But even without this self-restraint, there would be no spin for a CNN
 story. Dedication to good cryptographic key management is squarely
 dull and boring for a typical person.

I was referring to news of a breach (whether through factoring or
otherwise), not the key management procedures as such.

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


Re: Crypto dongles to secure online transactions

2009-11-09 Thread Florian Weimer
* John Levine:

 At a meeting a few weeks ago I was talking to a guy from BITS, the
 e-commerce part of the Financial Services Roundtable, about the way
 that malware infected PCs break all banks' fancy multi-password logins
 since no matter how complex the login process, a botted PC can wait
 until you login, then send fake transactions during your legitimate
 session.  This is apparently a big problem in Europe.

There are some countries which use per-transactions one-time
passwords.  These methods has been broken as well.

 So before I send it off, if people have a moment could you look at it
 and tell me if I'm missing something egregiously obvious?  Tnx.

There are already some commercial implementations (e.g. those
following ZKA's Secoder standard).  IBM apparently has something in
the works called ZTIC.  There used to be the FINREAD standard.

Attacks which would break these authentication schemes have already
been observed in the wild.  There are various means to trick people
into providing authorization for fraudulent transactions.  Tell them
that they have the opportunity to buy an expensive car at a fraction
of the price, or offer them a very attractive financial investment,
for instance.

$50 per device doesn't seem to be much, but you actually need a huge
amount of fraud that's actually prevented until it's cost-effective to
roll this out.  I don't think banks which offer real electronic
banking (that is, something pretty much like Paypal, but with consumer
rights) can legally tell high-risk from low-risk customers, so you're
basically stuck with general rollout.  While $50 per device may seem a
bit on the high side, I think it's not unrealistic if you consider
costs associated with personalization, branding, etc.

There's also the issue that a large amount of online banking happens
from work during the lunch hour.  USB dongles with software
installation requirements are problematic for those users.

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


Re: Possibly questionable security decisions in DNS root management

2009-10-22 Thread Florian Weimer
* Perry E. Metzger:

 Actually, there are routine attacks on DNS infrastructure these days,
 but clearly they're not cryptographic since that's not
 deployed. However, a large part of the point of having DNSSEC is that we
 can then trust the DNS to be accurate so we can insert things like
 cryptographic keys into it.

As far as I know, only the following classes of DNS-related incidents
have been observed:

  (a) Non-malicious incorrect DNS responses from caches

  (a1) as the result of defective software
  (a2) due to misconfiguration
  (a3) as a means to generate revenue
  (a4) as a means to generate revenue, but informed consent
   of the affected party is disputed
  (a5) to implement local community standards

  (b) Compromised service provider infrastructure

  (b1) ISP caching resolvers
  (b2) ISP-provisioned routers/DNS proxies at customer sites
  (b3) authoritative name servers and networks around authoritative
   name servers
  (b4) as the result of registrar/registry data manipulation

  (c) DNS as a traffic amplifier, used for denial-of-service attacks
  both against DNS and non-DNS targets

  (d) in-protocol, non-spoofed DNS-based reflective attacks against
  authoritative servers

  (e) unclear incidents for which sufficient data is not available

The problem is that the attacks you mentioned are in class (e), but
likely belong to (a1) and (a2) if we had more insight into them.
Certainly, bad data itself is not proof of malicious intent.

(NB: (a1) does *not* include software using predictable query source
ports.  There does not appear to be corresponding attack activity.)

 I'm particularly concerned about the fact that it is difficult to a
 priori analyze all of the use cases for DNSSEC and what the incentives
 may be to attack them.

Well, this seems to be rather constructed to me.  You state that
DNSSEC is a game changer, and then it's indeed pretty unclear what
level of cryptographic protection is required.  But in reality, DNSSEC
adoption is not likely to change DNS usage patterns.  If there's an
effect, it will be due to the more rigid protocol specification and a
gradual phase-out of grossly non-compliant DNS implementations, and
not due to the cryptography involved.

-- 
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

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


Re: Possibly questionable security decisions in DNS root management

2009-10-22 Thread Florian Weimer
* Jack Lloyd:

 On Sat, Oct 17, 2009 at 02:23:25AM -0700, John Gilmore wrote:

 DSA was (designed to be) full of covert channels.

 True, but TCP and UDP are also full of covert channels.

And you better randomize some bits covered by RRSIGs on DS RRsets.
Directly signing data supplied by non-trusted source is quite risky.
(It turns out that the current signing schemes have not been designed
for this type of application, but the general crypto community is very
slow at realizing this discrepancy.)

-- 
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

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


Re: Possibly questionable security decisions in DNS root management

2009-10-22 Thread Florian Weimer
* Victor Duchovni:
 The optimization is for DDoS conditions, especially amplification via
 forged source IP DNS requests for . IN NS?. The request is tiny,
 and the response is multiple KB with DNSSEC.

There's only one required signature in a . IN NS response, so it
isn't as large as you suggest.  (And the priming response is already
larger than 600 bytes due to IPv6 records.)

DNSKEY RRsets are more interesting.  But in the end, this is not a DNS
problem, it's a lack of regulation of the IP layer.

-- 
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

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


Re: Possibly questionable security decisions in DNS root management

2009-10-22 Thread Florian Weimer
* John Gilmore:

 So the standard got sent back to the beginning and redone to deal with
 the complications of deployed servers and records with varying algorithm
 availability (and to make DSA the officially mandatory algorithm).
 Which took another 5 or 10 years.

And it's still not clear that it works.  No additional suite of
algorithms has been approved for DNSSEC yet.  Even the upcoming
SHA-256 change is, from an implementors perspective, a minor addition
to NSEC3 support because it has been tied to that pervasive protocol
change for political reasons.

 forcibly paid by every domain owner

Not really, most ccTLDs only pay out of generosity, if they pay at all
(and if you make enough fuss at your favorite TLD operator's annual
general meeting, they are likely to cease to pay, too).

 So the total extra data transfer for RSA (versus other) keys won't
 be either huge or frequent.

Crap queries are one problem.  DNS is only efficient for regular DNS
resolution.  Caching breaks down if you use non-compliant or
compliant-to-broken-standards software.  There's also the annoying
little twist that about half of the client (resolver) population
unconditionally requests DNSSEC data, even if they are incapable of
processing it in any meaningful way (which means, in essence, no
incremental deployment on the authoritative server side).

There are some aspects of response sizes for which no full impact
analysis is publicly available.  I don't know if the 1024 bit decision
is guided by private analysis.  (It is somewhat at odds with my own
conclusions.)

-- 
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

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


Re: brute force physics Was: cleversafe...

2009-08-13 Thread Florian Weimer
* David Wagner:

 (Do note that factoring is not NP-complete.)

It's also possible to factor an n-bit number in O(n^k) integer
additions, substractions, multiplications, divisions and comparisons
to zero, for some smallish fixed value of k (an observations which is
due to Schönhage, IIRC).  So you have to look very closely at your
model of computation.  It turns out integer arithmetic isn't the
relevant one.  Until scalable quantum computers are available, it will
be difficult to forecast what the correct model will be.  There might
be practical limits not immediately apparent, similar to our lack of
means to build machine registers which can store integers in the
mathematical sense.

-- 
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

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


Re: Judge orders defendant to decrypt PGP-protected laptop

2009-03-04 Thread Florian Weimer
* Stephan Somogyi:

 At 13:08 -0500 03.03.2009, Adam Fields wrote:

When compelled to give out your password

 Unless I'm misunderstanding the ruling, Boucher is not being compelled
 to produce his passphrase (like he could under RIPA Section 49 in the
 UK), but he is being told to produce the unencrypted contents of the
 drive.

 Assuming I'm interpreting the ruling correctly, this seems little
 different than a judge approving a search warrant for a residence,
 whose execution could produce incriminating evidence that is usable
 in court.

The difference is that having your residence searched does not require
active cooperation from you.  You don't even have to disclose all your
residences which should be searched.  Forcing a suspect to decrypt
data is rather questionable because it is difficult to draw a line
between decrypting, decompressing, selecting, and producing relevant
data.

FWIW, the case which sparked this thread is rather special because
when the laptop was searched at the border, the files were visible to
a border guard.  I guess this constellation is highly unusual.

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


Re: Property RIghts in Keys

2009-02-13 Thread Florian Weimer
[Moderator's note: I've been clamping down on the IP discussion since
not much more really new was being said, but I'm allowing this through
because it brings up an interesting side point -- I will reply to it
to move to that discussion. --Perry]

* Perry E. Metzger:

 However, a cert seems almost certainly *not* to be IP.

 1) It can't be a trade secret, it is published.
 2) It can't be patented.
 3) It can't be copyrighted, it contains no creativity.

4) It can't be trademarked because the company named in the DN is long
   gone

(It's quite strange that so many of the browser root certs use DNs
which aren't correct anymore.)

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


Re: What risk is being defended against here?

2009-01-17 Thread Florian Weimer
* Jerry Leichter:

 Any speculations (beyond bureaucracy at its finest)?

I wild guess would be fraudulent testing organizations which claim to
have been subject to fraud themselves, and the testing standards body
answered with some sort of regulation.

(For certain German language test instances at certain sites, there
used to me impossibly high participation numbers.  The alleged
certificates of the results were probably simply forged, but that's
where I got the idea from.)

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


Re: Security by asking the drunk whether he's drunk

2008-12-28 Thread Florian Weimer
* Jerry Leichter:

 I got in touch with the company and actually received intelligent
 responses both at their 800 number - I placed my order that way - and
 in a response from their customer service people.  Most remarkable -  
 almost all organizations ignore such communication.  It's ironic that
 those who appear to be trying the hardest are being screwed over by
 the system that's currently in place - and will inadvertently be
 involved in training users to simply bypass yet another kind of bad
 cert warning.

This is also why I don't want browser vendors to remove CAs for which
they haven't got enough documentation, at least at this stage.  After
a few rounds of competitors attacking each other (and themselves as
well, because who knows who controls some of the older private keys
these days), the only CAs left are those where initiating RA
procedures is sufficiently difficult for law-abiding citizens--and
cost is a very likely discriminator in this area.

And for most sites, those extra $$$ are better spent on hosting with
some sort of security monitoring.

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


Re: Raw RSA binary string and public key 'detection'

2008-11-22 Thread Florian Weimer
* Dirk-Willem van Gulik:

 Been looking at the Telnic (dev.telnic.org) effort.

 In essence; NAPTR dns records which contain private details such as a
 phone number. These are encrypted against the public keys of your
 friends (so if you have 20 friends and 3 phone numbers visible to all
 friends - you need 20 subdomains x 3 NAPTR entries under your
 master').

 Aside from the practicality of this - given a raw RSA encrypted block
 and a list of public keys - is there any risk that someone could
 establish which of those public keys may have been used to create that
 block ?

If the padding scheme is decent, this should not be possible without
breaking RSA.

However, the proposal limits keys to about 250*6 bits, which seems
rather restrictive for RSA keys.

I'm also concerned about reflective attacks were you ask someone who's
trusted by the data owner to decrypt the data for you, possibly in an
automated fashion.

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


Re: voting by m of n digital signature?

2008-11-14 Thread Florian Weimer
* James A. Donald:

 Is there a way of constructing a digital signature so
 that the signature proves that at least m possessors of
 secret keys corresponding to n public keys signed, for n
 a dozen or less, without revealing how many more than m,
 or which ones signed?

What about this?

  Christian Cachin, Asad Samar
  Secure Distributed DNS
  http://www.zurich.ibm.com/security/dti/#dnsrepl

Or do you require that potential signers must not be able to prove
that they signed?

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


Re: More US bank silliness

2008-09-09 Thread Florian Weimer
* Peter Gutmann:

 On a semi-related topic, it'd be interesting to get some discussion about FF3 
 removing the FF2 SSL indicators of the padlock and (more visibly) the 
 background colour-change for the URL bar when SSL is active and replacing it 
 with a spoof-friendly indicator that's part of the favicon, i.e. part of the 
 attacker-controlled content.

To keep this in perspective, note that you could disable the location
bar altogether in FF2 (and that default changed in FF3), so the FF3
approach is actually an improvement.

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


Re: OpenID/Debian PRNG/DNS Cache poisoning advisory

2008-08-08 Thread Florian Weimer
* Eric Rescorla:

 Why do you say a couple of megabytes? 99% of the value would be
 1024-bit RSA keys. There are ~32,000 such keys.

There are three sets of keys, for big-endian 32-bit, little-endian
32-bit and little-endian 64-bit.  On top of that, openssl genrsa
generates different keys depending on the existence of $HOME/.rnd (and
-3 creates yet another set of keys, but this is more in the league of
different key length).  If the library is used for key generation
(instead of the command line tool), different keys might result.

On the other hand, the on-disk size would be comparable to the phishing
filter database.

Part of the problem of the CRL approach is that CAs usually have
policies against obtaining private keys and therefore can't prove to the
customer that their keys are compromised.  And adding a CRL entry when
the customer isn't convinced that they've got a problem is probably not
a good idea, either.

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


Looking through a modulo operation

2008-07-20 Thread Florian Weimer
I've got a function f : S - X x S where S = (Z/2Z)**96 and
X = (Z/2Z)**32.  Suppose that s_0 is fixed and (x_i, s_i) = f(s_{i-1}).
(f implements a PRNG.  The s_i are subsequent internal states and the
x_i are results.)

Now f happens to be linear.  I know the values of x_i, x_{i+1}, ...,
x_{i+k} module N, for a fixed, known N.  N is odd (but divisible by 9).
Is it possible to recover s_i with reasonable effort (better than brute
force, and k should be in the hundreds, not thousands)?  And if yes, how?
Prediction of candidates for x_{i+k+1} with high probability would be
helpful, too.

(Obviously, using f as an unpredictable PRNG is not a good idea.  But if
there's a real attack I can present, convincing the authors to replace
it would be so much easier.)

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


Re: “A Practical Attack on the MIFARE Classic”

2008-07-16 Thread Florian Weimer
* Karsten Nohl:

 The benefits clearly outweigh the risks since half a year after
 announcing the vulnerabilities, Mifare Classic is hopefully not used
 in any high security application anymore.

Isn't this a bit of wishful thinking?

The dynamics are probably very involved because you usually don't buy
from NXP, but an integrated product from a reseller.  An upgrade isn't a
free patch, either, so it needs some sort of budgeting and planning.

That being said, the chip should have been phased out years ago.  But
within half a year?  No way.

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


Re: Kaminsky finds DNS exploit

2008-07-14 Thread Florian Weimer
* Jack Lloyd:

 Perhaps there is something subtle here that is more dangerous than the
 well known problems, and all these source port randomization and
 transaction id randomization fixes are just a smokescreen of sorts for
 a fix for something Dan found.

It's not a smokescreen, it's a statistical workaround.

CERT/CC mentions this:

| It is important to note that without changes to the DNS protocol, such
| as those that the DNS Security Extensions (DNSSEC) introduce, these
| mitigations cannot completely prevent cache poisoning.

http://www.kb.cert.org/vuls/id/800113

 A statement from the MaraDNS author [3]:

 
 MaraDNS is immune to the new cache poisoning attack.

I think the CERT/CC statement is more approriate.

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


Re: Kaminsky finds DNS exploit

2008-07-14 Thread Florian Weimer
* John Levine:

CERT/CC mentions this:

| It is important to note that without changes to the DNS protocol, such
| as those that the DNS Security Extensions (DNSSEC) introduce, these
| mitigations cannot completely prevent cache poisoning.

 Why wouldn't switching to TCP lookups solve the problem?

It requires code changes on both types of servers, in order to make them
more scalable.

 It's arguably more traffic than DNSSEC, but it has the large practical
 advantage that they actually work with deployed servers today.

Implementors say that in many cases, their software as it's currently
implemented can't take the load.  It's not much worse than web traffic,
that's why I think it can be made to work (perhaps easier with kernel
support, who knows).  But code changes are apparently required.

And once you need code changes, you can roll out DNSSEC--or some
extended query ID with 64 additional bits of entropy.

On top of that, some operators decided not to offer TCP service at all.

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


Re: Kaminsky finds DNS exploit

2008-07-10 Thread Florian Weimer
* Paul Hoffman:

 The take-away here is not that Dan didn't discover the problem, but
 Dan got it fixed.

I haven't seen credible claims that the underlying issue can actually be
fixed in the classic DNS protocol.  There are workarounds on top of
workarounds.  A real fix requires more or less incompatible protocol
changes, and at that point, it might be easier to deploy DNSSEC instead.

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


Re: Secure voice?

2008-07-07 Thread Florian Weimer
* Allen:

 Interesting tidbit:

 http://www.epaynews.com/index.cgi?survey=ref=browsef=viewid=121516308313743148197block=

 Nick Ogden, a Briton who launched one of the world's first e-commerce
 processors in 1994, has developed a system for voice-signed financial
 transactions. The Voice Transact platform was developed by Ogden's
 Voice Commerce Group in partnership with U.S. speech software firm
 Nuance Communications.

Looks a bit fishy because Nuance Communications hasn't issued a similar
press release about their cooperation.  There's also a total lack of
technical content.

And calling voice recordings biometrics is a bit of a stretch--you
could ask your customer about color preferences and label it
biometrics, too.

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


Re: Strength in Complexity?

2008-07-06 Thread Florian Weimer
* Arshad Noor:

 I may be a little naive, but can a protocol itself enforce proper
 key-management?  I can certainly see it facilitating the required
 discipline, but I can't see how a protocol alone can enforce it.
 Any examples you can cite where this has been done, would be very
 helpful.

As far as I understand it, you don't actually change protocols, which
means that there's likely no way around this problem.

 The design paradigm we chose for EKMI was to have:

 1) the centralized server be the focal point for defining policy;
 2) the protocol carry the payload with its corresponding policy;
 3) and the client library enforce the policy on client devices;

 In some form or another, don't all cryptographic systems follow a
 similar paradigm?

No, there are things like digital cash and mental poker which do not
work with a trusted third party.  I think it's even possible to compute
RSA signatures from a split private key in a way that is secure against
byzantine failure (IOW, a certain number of key holders needs to
cooperate to forge a signature or recover the private key).  There's
also quite a bit of research on operations on encrypted databases.

Of course, you cannot actually run an ordinary web shop on top of such
protocols because interfaces to the public and to the processors are
essentially fixed.  Cryptographically securing the middle end seems
rather pointless to me because the public-facing front end is the
component that causes most of the trouble.  (And I'm not fully convinced
that more encryption is the answer to that.)

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


Re: German banks liable for phishing (really: keylogging) attacks

2008-07-05 Thread Florian Weimer
* Stephan Neuhaus:

 This article: http://www.spiegel.de/wirtschaft/0,1518,563606,00.html
 (sorry, German only) describes a judgment made by a German district
 court which says that banks are liable for damages due to phishing
 attacks.

District court may be a bit misleading, it's the entry-level court for
this particular type of dispute, at the lowest place in the hierarchy.

 In the case in question, a customer was the victim of a
 keylogger even though he had the latest anti-virus software installed,

The latest part is not clear.  I'm also puzzled that forensics could
not recover the actual malware.

(A keylogger alone is not quite good enough--you need to disrupt
transmission of the one-time password to the bank's server if you want
to to use the password later on.  OTOH, the disruption component does
not necessarily appear in AV descriptions.)

 and lost 4000 Euro. The court ruled that the bank was liable because
 the remittance in question had demonstrably not been made by the
 customer and therefore the bank had to take the risk.

Well, the open question is not whether the bank has to take the risk
(after all, the transaction has been successfully disputed, even before
the case went to court), but if the customer was negligent and needs to
share some of the damage.

For instance, if a computer takes 15 minutes to boot, constantly
displays pop-up ads, and sporadically shows error messages during
browsing, I would hope that it's reasonable to assume that the machine
is not safe for on-line banking--no matter what the anti-virus says
about the state of the machine.

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


Re: ITU-T recommendations for X.509v3 certificates

2008-07-05 Thread Florian Weimer
* Peter Gutmann:

Or is it unreasonable to expect that the specs match what is actually needed
for interoperability with existing implementations (mostly in the TLS, S/MIME
area)?

 There is very little correspondence between PKI specs and reality.

I should have written that my main goal was to extract the public key
material, and perhaps the validity period.  I want to use the
certificates as interoperable public key containers, mainly in order to
be able to rely on proven TLS implementations for encryption and
authentication.

 The brokenness in X.509 implementations creates a self-sustaining cycle in
 which applications that accept certs are more or less oblivious to anything
 that's in the cert (beyond basic stuff like correct formatting and encoding,
 and so on), so you can get away with almost anything (and then in turn because
 apps will accept anything, cert creators can create arbitrarily broken certs
 without being caught out by it, so the cycle is self-sustaining).

I guess parsing X.509 certs to derive further semantic content is
comparable to mail header parsing.  That is a futile exercise, too, but
sometimes unavoidable (for finding spam injection points, for instance).

But to be honest, I really don't see the point of extracting further
data from the certificates.  I can't reach OCSP servers and CRL
distribution points anyway because they are firewalled off.  I still
need to map a DN to some application-specific entity, and I need to
grant specific capabilities to it because I don't want to grant blanket
permission to the CAs involved--but this means I can directly bind this
metadata to the certificate, using the DN instead does not really
simplify set-up.  The lack of indirection makes key rollover more
difficult, granted, but you don't have to deal with broken random number
generators every other day, so I'm not sure if this is such a bad
trade-off.

 If you want to be really lazy, use an X.509v1 cert where you don't even need
 to bother with extensions.  A downside (?) of this is that some applications
 will treat it as a CA root cert.

I've got a couple of X.509v1 certs with extensions in production use,
which are a bit difficult to phase out. 8-( Turns out that this is not
so interoperable after all.

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


Re: Strength in Complexity?

2008-07-05 Thread Florian Weimer
* Peter Gutmann:

 [1] Show of hands, how many people here not directly involved with X.509 work
 knew that the spec required that all extensions in CA root certificates
 (trust anchors in recent X.509 jargon) be ignored by an implementation?
 So if you put in name constraints, key usage constraints, a policy
 identifier, etc, then a conforming implementation is supposed to look at
 them, throw them away, and proceed as if they weren't there?

Are you sure that the constraints are not supposed to be applied when
the root certificate is actually processed, after its signature has been
verified by the trust anchor?

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


Re: Strength in Complexity?

2008-07-05 Thread Florian Weimer
* Arshad Noor:

 The author of an article that appeared in InformationWeek this week
 (June 30, 2008) on Enterprise Key Management Infrastructure (EKMI):

 http://www.informationweek.com/shared/printableArticle.jhtml?articleID=208800937

 states the following:

 There are, of course, obstacles that must still be overcome by EKMI
 proponents. For example, the proposed components are somewhat simple
 by design, which concerns some encryption purists who prefer more
 complex protocols, on the logic that they're more difficult to break
 into.

First of all, a simple SKSML request for a symmetric key is a whopping
77 lines of SOAPWSS/whatever XML; the server response is 62 lines even
without the container.  If this is not enough to make every complexity
fanboy happy, I don't know what can do the trick.

On a more serious note, I think the criticism probably refers to the
fact that SKSML does not cryptopgrahically enforce proper key
management.  If a participant turns bad (for instance, by storing key
material longer than permitted by the protocol), there's nothing in the
protocol that stops them.

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


Re: Strength in Complexity?

2008-07-05 Thread Florian Weimer
* Peter Gutmann:

 Florian Weimer [EMAIL PROTECTED] writes:
* Peter Gutmann:
 [1] Show of hands, how many people here not directly involved with X.509 
 work
 knew that the spec required that all extensions in CA root certificates
 (trust anchors in recent X.509 jargon) be ignored by an 
 implementation?
 So if you put in name constraints, key usage constraints, a policy
 identifier, etc, then a conforming implementation is supposed to look at
 them, throw them away, and proceed as if they weren't there?

Are you sure that the constraints are not supposed to be applied when
the root certificate is actually processed, after its signature has been
verified by the trust anchor?

 Yup.  The app is supposed to read the cert, parse and process the extensions,
 and then throw them away.  The text from the spec is:

   3.3.60 trust anchor: A trust anchor is a set of the following information in
   addition to the public key: algorithm identifier, public key parameters (if
   applicable), distinguished name of the holder of the associated private key
   (i.e., the subject CA) and optionally a validity period. The trust anchor
   may be provided in the form of a self-signed certificate. A trust anchor is
   trusted by a certificate using system and used for validating certificates
   in certification paths.

 Rendered into English, that says take the pubic key, owner name, and 
 validity period, and ignore everything else in the cert.

Let me rephrase my remark: The trust anchor is conceptually separate
from a root CA certificate.  It is only used to validate it the CA
certificate.  Nothing in that section gives you permission to ignore
extensions on the CA certificate (skipping the first entry in the
certification path).  In addition, the trust anchor cannot be used
directly to verify certificates issued by the CA because the subject DN
does not match.  Ergo, the extensions on the CA certificate are still in
force.

 Luckily no sane implementation pays any attention to this nonsense :-).

I think your interpretation actually leads to a non-compliant
implementation.  Obviously, wording of that section could be less
confusing.

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


Re: skype claims they have no technical means to assist wiretapping

2008-06-16 Thread Florian Weimer
* Perry E. Metzger:

 Excerpt:

  Jennifer Caukin, Skype's director of corporate communications
  replied to us: We have not received any subpoenas or court
  orders asking us to perform a live interception or wiretap of
  Skype-to-Skype communications. In any event, because of Skype's
  peer-to-peer architecture and encryption techniques, Skype would
  not be able to comply with such a request.

 http://news.cnet.com/8301-13578_3-9963028-38.html?part=rsstag=feedsubj=TheIconoclast

It's sort-of industry practice to wiretap peer-to-peer voice-over-IP
environments by asking the naming service not to signal the availability
of a direct, end-to-end, but to fall back to some media gateway (which
is there for interoperability with the phone network anyway).  I'm
surprised that is compliant with regulatory requirements, but
apparently, it is.

So, at that point, it wouldn't be Skype-to-Skype anymore.  It also
solves the problem of getting access to the media stream (which is the
difficult part for traditional VoIP systems, which are encrypted only in
the marketing brochures).

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


Re: RIM to give in to GAK in India

2008-05-27 Thread Florian Weimer
* Dave Korn:

In a major change of stance, Canada-based Research In Motion (RIM)
may allow the Indian government to intercept non-corporate emails
   
sent over BlackBerrys.


   Research In Motion (RIM), the Canadian company behind the BlackBerry
   handheld, has refused to give the Indian government special access to
**
   its encrypted email services.   [ ... ]
   
   According to the Times of India, the company said in a statement:

 The BlackBerry security architecture for enterprise customers is
   
   purposefully designed to exclude the capability for RIM or any third
   party to read encrypted information under any circumstances. We regret

   [  Hmm, two contradictory stories, whoever woulda thunk it?  There's
 probably some politicking going on, mixed up with marketeering and
 FUD-spinning.  ]

If you look closely, there's no contradiction.  Non-enterprise customers
don't run their own gateway, so RIM just acts as a telco, which
naturally has got access to all the data.  The Indian government doesn't
need special access, either, because Lawful Intercept services etc.
aren't that special anymore.

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


Re: [ROS] The perils of security tools

2008-05-23 Thread Florian Weimer
* Peter Gutmann:

 Debian seem to be particularly bad for not reporting changes to
 maintainers,

This shouldn't be the case.  There's a clear policy that non-packaging
changes (basically, anything beyond trivial build fixes and pathname
changes for FHS compliance) should be submitted upstream.

 I've got a few packages that are contained in a number of distros and
 I notice via occasional Google searches for semi-related items that
 I'm getting hits to CVS change logs for my code where someone is
 repeatedly re-applying some patch to every new version I release.

If you name names, we can certainly fix that.  I couldn't figure out
what packages are affected on Debian's side.

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


Re: [ROS] The perils of security tools

2008-05-23 Thread Florian Weimer
* Ben Laurie:

 Jonathan S. Shapiro wrote:
 Ben: I'm idly curious. Was this exceptionally unusual case where use of
 uninitialized memory was valid properly commented in the code?

It's mentioned in the manpage for a function that eventually calls the
function that was (correctly) patched--through a function pointer.  The
incorrectly patched function looks somewhat parallel, but it's not.

There is no local comment in the source code for this particular case of
uninitialized memory access.

 Well. Kinda. It didn't really explain why:

   i=fread(buf,1,n,in);
   if (i = 0) break;
   /* even if n != i, use the full array */
   RAND_add(buf,n,(double)i);

 There is in theory a second place where it might used an uninitialised
 buffer, but I think in practice that never happens.

AFAIK, this piece of code is not really related and rarely used outside
OpenSSL itself.  And in the OpenSSL case, the fread call always
overwrites the whole buffer, it seems.

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


Re: [ROS] The perils of security tools

2008-05-23 Thread Florian Weimer
* Ben Laurie:

 I must confess that I said that because I did not have the energy to
 figure out the other routes to adding entropy, such as adding an int
 (e.g. a PID, which I'm told still makes it in there).

The PID dependency is there because of the need for fork
support--obviously, the PRNG must return a different key stream in the
parent and child process, but the two cannot communicate with each
other.

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


Re: OpenSparc -- the open source chip (except for the crypto parts)

2008-05-05 Thread Florian Weimer
* Perry E. Metzger:

 Marcos el Ruptor [EMAIL PROTECTED] writes:

 Nonsense. Total nonsense. A half-decent reverse engineer does not
 need the source code and can easily determine the exact operation of
 all the security-related components from the compiled executables,
 extracted ROM/EPROM code or reversed FPGA/ASIC layout

 I'm glad to know that you have managed to disprove Rice's
 Theorem.

Call me a speciest, but it's not clear if Rice's Theorem applies to
humans.

While Marcos' approach is somewhat off the mark (source-code
equivalent that works for me vs. conformance of potentially
malicious code to a harmless spec), keep in mind that object code
validation has been performed for safety-critical code for quite a
while.  The idea is that code for which some soundness property cannot
be shown simply fails validation.  It doesn't matter if the validator
is not clever enough, or if the code is actually bogus.

(And for most (all?) non-trivial software, source code acquisition
costs are way below validiation costs, so public availability of
source code is indeed a red herring.)

-- 
Florian Weimer[EMAIL PROTECTED]
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

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


Re: How is DNSSEC

2008-03-26 Thread Florian Weimer
* James A. Donald:

 From time to time I hear that DNSSEC is working fine, and on examining
 the matter I find it is working fine except that 

 Seems to me that if DNSSEC is actually working fine, I should be able
 to provide an authoritative public key for any domain name I control,
 and should be able to obtain such keys for other domain names, and use
 such keys for any purpose, not just those purposes envisaged in the
 DNSSEC specification.  Can I?  It is not apparent to me that I can.

DNS is hierarchical.  Nobody wants the DoD (who are traditionally quite
good at keeping secret data) or any other institution to keep keys at
important positions in the hierarchy.  And nobody wants to be the keep
irreplaceable keys, either, which makes introduction at levels below the
DNS root difficult.

This is not a problem with the browser PKI because it's possible to
replace root certificates with a software update (which can be automated
in many cases).

And as Bill pointed out, it's not possible to use the DNS keys directly.
However, you can bootstrap another key based on data from DNS.  This
even works without DNSSEC.  DKIM does that, for instance.

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


Re: SSL/TLS and port 587

2008-01-23 Thread Florian Weimer
* Ed Gerck:

 The often expressed idea that SSL/TLS and port 587 are somehow able
 to prevent warrantless wiretapping and so on, or protect any private
 communications, is IMO simply not supported by facts.

Huh?  Have you got a source for that?  This is he first time I've
heard of such claims.

Message submission over 587/TCP gives the receiver more leeway
regarding adjusting message contents to police (add a message ID,
check the Date and From headers, and so on).  The abuse management
contract is also different: once you accept a message over 587/TCP,
it's your fault (and your fault alone) if this message turns out to be
spam.  There's nothing related to confidentiality that I know of.

-- 
Florian Weimer[EMAIL PROTECTED]
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

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


Re: patent of the day

2008-01-23 Thread Florian Weimer
* Saqib Ali:

 can anyone please shed more light on this patent. It seems like a
 patent on the simple process of cryptographic erase..

Exactly.  Niels Provos, Encrypting Virtual Memory, USENIX Security
2000, looks like something pretty close to prior art:

| We investigate several alternative solutions to prevent confidential
| data from remaining on backing store, e.g. erasing data physically
| from the backing store after pages on it become unreferenced.
| However, we find that encryption of data on the backing store with
| volatile random keys has several advantages over other approaches:
| 
| * The content of a page disappears when its respective encryption key
|   is deleted, a very fast operation. [...]

AFAICS, the patent does not reference the paper.

-- 
Florian Weimer[EMAIL PROTECTED]
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

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


Re: Question on export issues

2008-01-02 Thread Florian Weimer
* Ivan Krstić:

 We've recently had to jump through the BIS crypto export hoops at
 OLPC. Our systems both ship with crypto built-in and, due to their
 Fedora underpinnings, allow end-user installation of various crypto
 libraries -- all open-source -- through our servers. It was a
 nightmare; the regulations and paperwork appear to be designed for the
 use case of individual applications that utilize a handful of
 primitives and attempt to keep the user from examining or modifying
 the utilized crypto. Trying to fit a Linux distribution into this
 model proved, er, challenging.

Debian has been filing notices for crypto export for years (at BXA for
some time; nowadays, it's likely BIS).  So far, nobody there has
complained that what is being done is insufficient.

Here are some details: http://www.debian.org/legal/cryptoinmain
The actual process may have changed a bit over the years.

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


Re: PlayStation 3 predicts next US president

2007-12-13 Thread Florian Weimer
* William Allen Simpson:

 Assuming,
   Dp := any electronic document submitted by some person, converted to its
 canonical form
   Cp := a electronic certificate irrefutably identifying the other person
 submitting the document
   Cn := certificate of the notary
   Tn := timestamp of the notary
   S() := signature of the notary

   S( MD5(Tn || Dp || Cp || Cn) ).

 Of course, I'm sure the formula could be improved, and there are
 traditionally fields identifying the algorithms used, etc. -- or something
 else I've forgotten off the top of my head -- but please argue about the
 actual topic of this thread, instead of incessant strawmen.

The problem is not the outer MD5 (explicitly mentioned in your
description), but that Dp is typically (well, to the extent such
services have been deployed) some kind of hash.  This has got the
advantage that the timestamping service does not need to know the
contents of the document.  On the other hand, if the timestamping
service archives Dp and can reveal it in a dispute, evil twins can be
identified and analyzed -- which undermine the submitting party's claim
that it submitted the second document instead of the first.

Of course, this is actually cheating by substituting proven protocols
for fragile cryptography.  And the result is still open to
interpretation, but all evidence is.

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


Re: Seagate announces hardware FDE for laptop and desktop machines

2007-10-05 Thread Florian Weimer
* Ivan Krstić:

 On Oct 3, 2007, at 4:39 AM, Florian Weimer wrote:
 But this exhibits an issue with disk-based encryption: you can't
 really know what they are doing, and if they are doing it right.
 (Given countless examples of badly-deployed cryptography, this isn't
 just paranoia, but a real concern.)

 Precisely. If you're keeping secrets from your nosy siblings and
 coworkers, hardware FDE is more than adequate. If you have reason to
 believe someone skilled and resourceful might really want your data,
 you almost certainly have no business using a blackbox encryption
 system operating in a way that's not publicly documented -- even if
 the system is buzzword-compliant -- and implemented by a company
 (hard disk vendor) where crypto is about as far from their core
 competency as you can get.

I think the really interesting question is what happens when you lose
a FDE-ed hard drive.  Do you still need to publish the incident and
contact potentially affected individuals?  If the answer is no, I'm
sure this technology will be quickly adopted, independently of its
actual implementation.

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


Re: Seagate announces hardware FDE for laptop and desktop machines

2007-10-03 Thread Florian Weimer
* Simon Josefsson:

 One would assume that if you disable the password, the data would NOT be
 accessible.  Making it accessible should require a read+decrypt+write of
 the entire disk, which would be quite time consuming.  It may be that
 this is happening in the background, although it isn't clear.

Perhaps this section wasn't updated?  A password-based lock method is
present in most laptop drives today.

But this exhibits an issue with disk-based encryption: you can't
really know what they are doing, and if they are doing it right.
(Given countless examples of badly-deployed cryptography, this isn't
just paranoia, but a real concern.)

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


Re: interesting paper on the economics of security

2007-08-22 Thread Florian Weimer
* Hal Finney:

 Information on the quality of AV and other security products is widely
 available on the net, in magazines and other places that consumers
 might look for reviews and comparisons. This is completely unlike
 the situation with individual used cars. I don't see this analogy as
 particularly accurate.

I don't, either, but for a different reason.

The tests I've seen are mostly worthless because they do not weigh
their results based on the actual threats a typical user faces.  After
all, these days, the goal is not to avoid the embarrassments caused by
a virus infection or a spam bot operating from your network, but to
avoid actual loss due to fraud (or perceived fraud).  Mere detection
rates do not reflect that.[1] So there is certainly a lack of
information.

But in contrast to the used care market, the seller doesn't really
know how useful their products are to the buyer, either.  Some vendors
(those offering spam filtering as a service, for instance) might have
a better idea than their customer what's happening, but for the
broader market, return on security investment is a completely
imaginary figure for both buyers and sellers.  Only if you look at
things like pro-forma regulatory compliance, it's possible to obtain
hard facts.

[1] This might sound like marketing gibberish from some of the
big-name vendors, but I think it's true.  It does not mean that a
product which looks bad in a synthetic test gives adequate results in
the real world, though.

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


Re: How the Greek cellphone network was tapped.

2007-07-10 Thread Florian Weimer
* John Ioannidis:

 Florian Weimer wrote:

 It's also an open question whether network operators subject to
 interception requirements can legally offer built-in E2E encryption
 capabilities without backdoors.
 

 You probably meant device vendors, not network operators. The whole
 *point* of E2E security is that network operators are not involved. If
 they were, it wouldn't be end-to-end!

Uh-oh, no.  The protocol characteristics don't change depending on who
is selling you the device.  Many telcos have an aversion to end-to-end
protocols.  Building reliable networks for ill-behaving end systems
has been a pretty recent idea (and we are still far away from a
complete solution).

There aren't any interception requirements for device vendors, either,
at least not any I'm aware of.  They aren't telcos.  Projects like
OpenMoko should not be affected.

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


Re: How the Greek cellphone network was tapped.

2007-07-09 Thread Florian Weimer
* Ian Farquhar:

 Crypto has been an IP minefield for some years.  With the expiry of
 certain patents, and the availability of other unencumbered crypto
 primitives (eg. AES), we may see this change.  But John's other
 points are well made, and still valid.  Downloadable MP3 ring tones
 are a selling point.  E2E security isn't (although I've got to
 wonder about certain teenage demographics... :)

It's also an open question whether network operators subject to
interception requirements can legally offer built-in E2E encryption
capabilities without backdoors.

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


Re: UK RIPA Pt 3

2007-07-05 Thread Florian Weimer
* Peter Fairbrother:

 I forgot to mention that Pt.3 also includes coercive demands for
 access keys - so for instance if Mr Bill Gates came to the UK, and if
 there was some existing question about Microsoft's behaviour in some
 perhaps current EU legal matter, Mr Gates could be required to give up
 the keys to the Microsoft internal US servers. Or go to jail.

Well, if Mr Gates is a witness and not a suspect, such coercive
measures are well within the legal framework of most countries.  As a
witness, you must testify.  It simply does not matter if the
information you are asked to provide is encrypted, or is stored in a
database and needs significant preprocessing to obtain.  It would be
quite surprising if this was any different in the UK.

So it's purely the self-incrimination part that is questionable from a
legal POV.  I think this bears repeating because we face a similar
discussion in Germany regarding covert data seizure using
technological measures, and the discussion focuses almost entirely on
the technological measures.  But the legal obstacle is just the
covertness.

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


Re: Hackers target C-level execs and their families

2007-07-05 Thread Florian Weimer
* Udhay Shankar N.:

 Hasn't this already been going on a while? I'm only surprised there
 hasn't been a big public incident yet.

Doesn't this one count?

| According to Chief Superintendent Arye Edelman, head of the Tel Aviv
| fraud squad, which ran the investigation, Haephrati used two methods
| to plant his malicious software (or malware) in the target
| computers. One was to send it via e-mail. The other was to send a disk
| to the target company that purported to contain a business proposal
| from a well-known company that would arouse no suspicions. Then, when
| an employee loaded the disk to view the proposal, the Trojan horse
| would infect his computer.

http://www.haaretz.co.il/hasen/pages/ShArt.jhtml?itemNo=581790contrassID=Cd=1

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


Re: The bank fraud blame game

2007-07-02 Thread Florian Weimer
* Ian G.:

 Banks are the larger and more informed party.

But not as far as client-side fraudulent activity is concerned.  After
all, the attacked systems are not under their administrative control.

 They need to provide systems that are reasonable given the situation
 (anglo courts generally take this line, when pushed, I'm unsure what
 continental courts would do with that logic).

We have courts that are traditionally bank-friendly, and courts that
aren't.  While we do not heavily rely on case law, it's a bit of luck
which one sets the precedent (which will eventually help to shape
legislation).

And what's worse, the situation is so unstable that a case that gets
decided in favor of one party might actually end up shifting the risks
to the other party in the long run because the environment keeps
changing rapidly.

 Customers aren't in any position to dictate security requirements to
 banks.

And vice versa.

It might even happen that we see competion from foreign, EU-based
banks that offer transactions without the safeguards German banks have
agreed to among each other.  We'll see if this increase in convenience
turns out to be a major selling point.

 Unfortunately for the banks, there is a vast body of evidence that
 we knew and they knew or should have known that the PC was insecure
 [1].

I think the extent to which end users, hardware and software
manufacturers, and ISPs don't care about compromised machines was a
real surprise.  If there's malware on the PC, it's not just banking
that is affected.  You'd expect people to do something about it, but
no one does without significant external pressure.

And if you look closely at which attacks security experts predict (and
not just self-proclaimed ones!), and which actually materialize, there
are significant differences.  These differences are usually mulled
over by ambiguous terminology, but the gap is there.

 So, by fielding a system -- online commerce -- with a known
 weakness, they took responsibility for the fraud (from all places).

They didn't build the Internet, they didn't provide the PC and its
software, they don't even run the most-frequented online commerce
applications.  But in a moment of weakness, they started to take
responsibility.  And the real difficulties began.

For a rare security success story, look at how ISPs manage to sell a
completely insecure product which puts their customers at significant
risk, and take virtually no blame for it.  And technologically, banks
are not that different from mail providers.  They just pass around
messages.  Why should they be responsible for their content, if ISPs
aren't?

 Now they are in the dilemma.  The customer can't provide evidence of
 the fraud, because the system fielded doesn't support it (it's login
 authentication not transaction authorisation).

Non-digital crime faces the same problem.  You haven't got a
cryptographically secured audit trail, either.  But clues can still be
found.

 [1] To my knowledge, continental banks knew of the risks and acted in
 the 90s, then scaled it down because the risks proved overstated.
 Brit banks knew of the risks and didn't care.  American banks didn't
 care.

The American banking system is mainly protected by its obsolescence.
It's not an end-to-end transaction system, unlike the European ones.

 [2] Again, continental banks are shifting to SMS authorisation
 (dual-channel) ... Brit banks are unsure what to do ...

The new APACS standard should be a huge leap forward for the UK.
AFAIK, it includes the limited form of transaction signing that is
possible within the constraints.  Of course, it's still not foolproof,
but the non-fools can actually detect a compromised terminal.

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


Re: The bank fraud blame game

2007-07-02 Thread Florian Weimer
* Anne  Lynn Wheeler:

 In the mid-90s, financial institutions looking at the internet for
 online, commercial banking and cash management (i.e. business
 equivalent to consumer online banking) were extremely conflicted
 ... they frequently were almost insisting on their own appliance at
 the business (and low-end of SOHO at least overlaps high-end
 of consumer online banking).

Well, in 1994, German Postbank already had 300,000 online banking
customers.  (To put this into perspective, there are somewhere around
3 million online customers today, and this was well before the
Internet took off in Germany.)

On top of that, there were other forms of digital banking that were
mainly used by business customers, such as transactions submitted on
floppy disks.

 Various of the PC-based dedicated financial applications go to
 quite some lengths to compensate for kind of vulnerabilities
 typically associated with browser activity. For instance,
 instead of relying on a trusted third party to certify that
 some remote location really has a valid digital certificate,
 they have a trusted repository of valid financial institutions.

Oh really?

In Germany, early digital banking had no cryptographic protection at
all.  Integrity and confidentiality were inherited from the underlying
phone system.  There were no end-to-end digital signatures.  Nothing.
Just a one-time password for each transaction, but the password was
not tied to the transaction in any way.

 This has the added benefit of eliminating the horribly complex
 and vulnerable PKI-type of operation

Except that there aren't any attacks on the browser PKI.  That's part
of the reason why the certificate prices plummeted. 8-/

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


Re: The bank fraud blame game

2007-07-01 Thread Florian Weimer
* Jerry Leichter:

 OK, I could live with that as stated.  But:

   The code also adds: We reserve the right to request access to
   your computer or device in order to verify that you have taken
   all reasonable steps to protect your computer or device and
   safeguard your secure information in accordance with this code.

   If you refuse our request for access then we may refuse your
   claim.

 The delay between when you were defrauded and when they request
 access is unspecified.

But if you don't do this, customers can repudiate *any* transaction,
even those they have actually issued.  In other words, you run into
tons of secondary fraud, where people claim they are victims, but they
actually aren't.

Customers need to provide some evidence that they are actually
victims.  Just claiming the virus did it can't be sufficient.

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


Re: IBM Lost Tape(s)

2007-06-11 Thread Florian Weimer
* John Ioannidis:

 I wonder how much it cost them to find current addresses for
 everybody so we could be notified.

I guess it's pretty easy because your personal information is
available to so many organizations, without any safeguards.
Obviously, they had your social security number (it's only the backup
that was lost), so they could work from that.

And more data is being collected: If you participate in their
monitoring program, Kroll can associate an email address with your
SSN, which is probably something that wasn't possible before.

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


Re: 307 digit number factored

2007-06-09 Thread Florian Weimer
* Victor Duchovni:

 But no one is issuing certificates which are suitable for use with
 SMTP (in the sense that the CA provides a security benefit).  As far
 as I know, there isn't even a way to store mail routing information in
 X.509 certificates.

 There is no need to store routing information:

   http://www.postfix.org/TLS_README.html#client_tls_limits
   http://www.postfix.org/TLS_README.html#client_tls_levels
   http://www.postfix.org/TLS_README.html#client_tls_verify
   http://www.postfix.org/TLS_README.html#client_tls_secure

 The short summary is that full security is only available when the
 receiving MX hosts have certs that match the recipient domain,

Which runs into the same problem as HTTP because the set of recipient
domain names is not known at the time the TLS handshake occurs.

 or the sender is willing to manually (in his MTA configuration) bind
 the recipient domain to the subject names (or in 2.5 fingerprints)
 of the appropriate MX hosts.

And if you use fingerprints, there is no need for PKI.  And in my
experience, PKI doesn't buy you that much if you need to configure
per-client privileges and things like that.  Using the DN instead of a
fingerprint doesn't seem to be worth the trouble.

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


Re: 307 digit number factored

2007-05-23 Thread Florian Weimer
* Victor Duchovni:

 That's good of you not to expect it, given that zero of the major CAs 
 seem to support ECC certs today, and even if they did, those certs 
 would not work in IE on XP.

 We are not talking about this year or next of course. My estimate is
 that Postfix releases designed this year, ship next year, are picked up
 by some O/S vendors the year after and shipped perhaps a year after that,
 then customers take a few years to upgrade, ... So for some users Postfix
 2.5 will be their MTA upgrade in 2011 or later. So we need to anticipate
 future demand by a few years to be current at the time that users begin
 to use the software.

But no one is issuing certificates which are suitable for use with
SMTP (in the sense that the CA provides a security benefit).  As far
as I know, there isn't even a way to store mail routing information in
X.509 certificates.

-
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-14 Thread Florian Weimer
* Ian G.:

 My worry was that they hadn't open sourced the architecture component,
 the part that wasn't meant to be replaceable. However even if open
 sourced, Sun may still wield a stick over the providers by insisting
 that they manage the signing process for the providers.

The signing provider PKI is a joke, it's sole purpose is to ensure
that Sun has got a fax allegedly from you in which you promise that
you will comply with applicable export regulations.

The root CA list shipped in OpenJDK should be empty at this stage (at
least this is mentioned somewhere on the OpenJDK web page) because it
is not clear what the criteria are to populate it.

-
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: Public key encrypt-then-sign or sign-then-encrypt?

2007-05-02 Thread Florian Weimer
* Travis H.:

 Also there's a semantic issue; am I attesting to the plaintext,
 or the ciphertext?  It's possible the difference could be important.

With sign, then encrypt, it's also possible that the receiver decrypts
the message, and then leaks it, potentially giving the impression that
the signer authorized the disclosure.  There has been a fair bit of
buzz about this confusion.  But the lesson from that seems to be that
signature semantics are very hard to agree upon, and most marginally
successful standards sidestep the issue anyway, acting as a mere
transport protocol.

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


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

2007-05-02 Thread Florian Weimer
* Perry E. Metzger:

 This seems to me to be, yet again, an instance where failure to
 consider threat models is a major cause of security failure.

Sorry, but where's the security failure?  Where can you buy hardware
devices that can copy HD disks?  Or download software that does, with
a readily usable interface?

In that sense, even CSS hasn't really been broken.

Even the flurry of DMCA takedown notices isn't necessarily a bad move.
It might help to shape the future of how access to content is
regulated in some very particular way.

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


Re: DNSSEC to be strangled at birth.

2007-04-05 Thread Florian Weimer
* Peter Gutmann:

 Dave Korn [EMAIL PROTECTED] writes:

Surely if this goes ahead, it will mean that DNSSEC is doomed to widespread
non-acceptance.

 I realise this is a bit of a cheap shot, but:

 How will this be any different from the current situation?

You can see that the keys change and draw your conclusions.  Right
now, you need to watch the actual data, which is a bit unwieldy (2.5%
daily change rate for .COM/.NET and things like that).

By the way, who else has expressed willingness to hold the key, under
reasonable conditions?  Would it be preferable if some
non-governmental organization held the keys, after receiving an
indemnification guarantee from Congress?

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


Re: DNSSEC to be strangled at birth.

2007-04-05 Thread Florian Weimer
* Simon Josefsson:

 However, in practice I don't believe many will trust the root key
 alone -- for example, I believe most if not all Swedish ISPs would
 configure in trust of the .se key as well.

There are some examples that such static configuration is extremely
bad.  Look at the problems with bogon filters, or how long
decommissioned root server IP addresses continue to receive queries.

It's not a problem if you do this for .SE as a Swedish ISP because you
notice quickly that something is amiss.  But if too many people do
this for most TLDs, it will become practically impossible to change
keys.

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


Re: Failure of PKI in messaging

2007-02-15 Thread Florian Weimer
* James A. Donald:

 Obviously financial institutions should sign their
 messages to their customers, to prevent phishing.  The
 only such signatures I have ever seen use gpg and come
 from niche players.

Deutsche Postbank uses S/MIME, and they are anything but a niche
player.  It doesn't help against phishing in the sense that deters the
attackers and reduces the PR impact.

 I have heard that the reason no one signs using PKI is
 that lots of email clients throw up panic dialogs when
 they get such a message, and at best they present an
 opaque, incomprehensible, and useless interface.  Has
 anyone done marketing studies to see why banks and
 massively phished organizations do not sign their
 messages to their customers?

Why bother, when it's been shown it doesn't make a difference?

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


Re: Free WiFi man-in-the-middle scam seen in the wild.

2007-01-30 Thread Florian Weimer
* Perry E. Metzger:

 If you go over to, say, www.fidelity.com, you will find that you can't
 even get to the http: version of the page any more -- you are always
 redirected to the https: version.

Of course, this only helps if users visit the site using bookmarks
that were created after the switch.  If they enter fidelity.com (or
even just fidelity) into their browsers to access it, switch to
HTTPS won't help at all.  Perhaps this explains why someone might
think that serving the login page over HTTPS is just security theater.

In the same we use use HTTPS and are still vulnerable to MITM
attacks department, there's the really old issue of authenticating
cookies which are not restricted to HTTPS, but will be happily sent
over HTTP as well. *sigh*

Apart from that, the article you linked to does not even mention
actual attacks with an identity theft motive.  What's worse, the
suggested countermeasures don't protect you at all.  Ad-hoc networks
are insecure, and those with an access point are secure?  Yeah, right.

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


Re: Fwd: [FDE] Largest Ever Single FDE implementation

2007-01-03 Thread Florian Weimer
* Saqib Ali:

 You can read about the competition, which will come to a close in the
 next 90 days at:

 http://www.fbo.gov/spg/USAF/AFMC/ESC/FA8771-07-R-0001/Attachments.html

In the process, the following document has been published:

http://www.herbb.hanscom.af.mil/download.asp?rfp=R1450FileName=2006_12_20_DAR_Vendor_Day_List__2_.xls

Is it standard practice to publish so many contact details of those
who are involved in the bidding process?

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


Re: ATM vulnerability

2006-12-21 Thread Florian Weimer
 I hesitate to use the syllable crypto in describing this paper,
 but those who have not seen it may find it interesting.

 http://www.arx.com/documents/The_Unbearable_Lightness_of_PIN_Cracking.pdf

 Or profitable.

In a weired sense, yes.  If I understand the paper correctly, the
authors show that given the current protocol requirements, spending
money on HSMs is a total waste.

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


Re: Hamiltonian path as protection against DOS.

2006-10-03 Thread Florian Weimer
* James A. Donald:

 DOS is now a major problem - every business, online
 games, money movers, banks, porno sites, casinos, now
 comes under DOS attack from extortionists.

How do Hamiltonian paths protect against the H.R.4411 attack?

(Part of the DoS problem online casinos face is that due to their
activity, which was illegal before, they are extremely reluctant to
approach law enforcement about this matter.)

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


Re: Circle Bank plays with two-factor authentication

2006-10-01 Thread Florian Weimer
* Steven M. Bellovin:

 Again -- the scheme isn't foolproof, but it's probably *good enough*.  

I agree that if you consider this scheme in isolation, it's better
than plain user names and passwords.  But I wonder if it significantly
increases customer confusion because banks told their customer that
they won't *ask* for credentials via email, but now a bank is
*sending* them by email.

 As for keystroke loggers -- the bad guy would have to capture enough table
 entries that they'd have a reasonable probability of seeing challenges
 they'd already received.

If this technology enters the attacker's radar screen, the keystroke
logger would be changed to scan mail folders for the message sent by
the bank.  Or it would alter the login page to display an empty
matrix, without any further explanations. 8-/

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


Re: Locating private keys in RAM?

2006-09-07 Thread Florian Weimer
* Douglas F. Calvert:

 I remember seeing a paper about identifying private keys in RAM. I
 thought it was by Rivest but I can not locate it for the life of me.
 Does anyone remember reading something like this? The basic operation
 was to identify areas in RAM that had certain characteristics such as
 random bits and identifiable key headers...
 Any help would be greatly appreciated...

From findkey.c in The Coroner's Toolkit:

/*  A. Shamir and N. van Someren, Playing Hide and Seek With Stored
/*  Keys, 1998.
/*  http://www.ncipher.com/products/files/papers/anguilla/keyhide2.pdf.

(The web page no longer exists, though.)

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


Re: Recovering data from encrypted disks, broken CD's

2006-07-29 Thread Florian Weimer
* Steven M. Bellovin:

 I wonder how accurate this is.  It's certainly true that some drives have
 vendor passwords to unlock them.  It's hard to see how they could break
 through (good) software encryption,

A lot of software tends to create temporary files in random places.
If you don't encrypt the whole disk (including swap space and the
suspend-to-disk area), plaintext might be written to the disk and can
be recovered even though the actual cryptography is sound.  This
assumes that transparent decryption is used--the situation is worse if
you need to create a temporary plaintext copy on disk before you can
actually process the data.

(Now I only need to figure out why sequential disk I/O takes such a
significant hit when using dm-crypt. *sigh*)

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


Re: NIST hash function design competition

2006-07-20 Thread Florian Weimer
* Travis H.:

 On 7/11/06, Hal Finney [EMAIL PROTECTED] wrote:
 : So what went wrong? Answer: NIST failed to recognize that table lookups
 : do not take constant time. âTable lookup: not vulnerable to timing
 : attacks, NIST stated in [19, Section 3.6.2]. NIST's statement was,
 : and is, incorrect.

 That's interesting, since it is in line with conventional reasoning
 about algorithms.  I've skimmed his paper, and I've taken a class on
 computer architecture and I haven't the foggiest idea where the
 variable timing comes from.  Does anyone know if any of the following
 account for the phenomenon?

 1) cache fills as we ascend through memory
 2) additions (base+index) taking non-constant time (could be fixed
 with pointers if we're going sequentially)
 3) virtual memory considerations (e.g. fetching new a page for a higher 
 address)
 4) TLB misses

Is this about Colin Percival's work?  IIRC, it's mainly about shared
associative caches which leak information about what addresses are
being cached across trust boundaries.

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


Re: Greek cellular wiretapping scandal

2006-06-25 Thread Florian Weimer
* Steven M. Bellovin:

 I have more than a passing aquaintance with the complexity of phone
 switch software; doing that was *hard* for anyone, especially anyone
 not a switch developer.

Isn't Ericsson's switching software written in Erlang, is highly
modular and officially supports run-time code replacement (like many
COBOL systems, but unlike, say, traditional IOS)?  This means that at
least no rootkit is needed.  You just replace the parts of the
system you are interested in using the standard system interfaces
intended for this purpose.  Of course, the complexity of the attack is
still significant.

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


Re: Status of SRP

2006-06-06 Thread Florian Weimer
* Anne  Lynn Wheeler:

 Florian Weimer wrote:
 FINREAD is really interesting.  I've finally managed to browse the
 specs, and it looks as if this platform can be used to build something
 that is secure against compromised hosts.  However, I fear that the
 support costs are too high, and that's why it hasn't caught on in
 retail online banking.

 if they can build a $100 PC ... you think that they could build a
 finread terminal for a couple bucks. sometimes there are issues with
 volume pricing ... you price high because there isn't a volume and
 there isn't a volume because you price high.

The problem is not hardware costs, but support costs.  You really
don't want to outsource this to the cheapest call center in the world.
Even relatively simple changes like the indexed TAN rollout are
rather expensive as a result.

 there is one issue missing from the actual FINREAD specification.

 when we were doing X9.59 financial standard ... we allowed for a
 digital signature for authentication as well as for a digital
 signature from the environment that the transaction was performed
 in. the issue from a relying party standpoint ... is what assurances
 do they have as to the actual environment that a transaction was
 executed in. consumers could claim they were using a FINREAD terminal
 when they weren't. counterfeit FINREAD terminals could be out in the
 wild.

You mean something like remote attestation?  I find it hard to believe
that this capability is available today in a relatively open
environment, on a platform supporting multiple applications developed
by different applications.

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


Re: Status of SRP

2006-06-03 Thread Florian Weimer
* Ka-Ping Yee:

 Passpet's strategy is to customize a button that you click.  We
 are used to recognizing toolbar buttons by their appearance, so
 it seems plausible that if the button has a custom per-user icon,
 users are unlikely to click on a spoofed button with the wrong
 icon.  Unlike other schemes, such as special-looking windows or
 a custom image shown with the login form, this strategy requires
 the user to directly interact with the customized UI element.

I'm not sure if this can't be defeated by something like a Choose a
new funny icon for your security button! offer. 8-( However, this
points to a more general problem: We have no real-world studies how
users make their day-to-day trust decisions when using the Internet.

For example, if I need to judge the trustworthyness of a web page, a
large factor is the way I got there.  If it was a link from an email
message that looks like spam, or something that was returned by a
search engine, I'm rather sceptical.  This is why those 80% can't
tell a phishing page apart from the real one web-base studies are
quite worthless.  They simply do not present enough context.

| The field for entering your master password isn't labelled Enter
| your password: - instead, it's labelled Enter Betty's secret:.
| Since the persona differs from user to user, it's hard to even ask
| for the password because the spoofer doesn't know what to call it.

I suppose this can be circumvented if you you use email to lure the
victim to the fake web page and have obtained names matching the email
addresses.  Even if you want to present the full address to the
victim, you can buy this data from direct marketing companies, I
think.

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


Re: Status of SRP

2006-06-03 Thread Florian Weimer
* Anne  Lynn Wheeler:

 Florian Weimer wrote:
 If you've deployed two-factor authentication (like German banks did in
 the late 80s/early 90s), the relevant attacks do involve compromised
 customer PCs. 8-( Just because you can't solve it with your technology
 doesn't mean you can pretend the attacks don't happen.

 EU finread terminal was countermeasure to (widely held impression
 that) PCs are extremely vulnerable to compromise.

You say that as if that assumption were unrealistic.
Transaction-rewriting malware is out in the wild. 8-(

FINREAD is really interesting.  I've finally managed to browse the
specs, and it looks as if this platform can be used to build something
that is secure against compromised hosts.  However, I fear that the
support costs are too high, and that's why it hasn't caught on in
retail online banking.

 card authentication required pin entry to work ... and finread
 terminal had its own PIN-pad distinct the vulnerable PC
 keyboard. orientation was towards transaction authentication ... with
 the finread terminal also having its own display of what was being
 authentication.

The interesting part is that it's possible to create an application
that runs exclusively on the trustworthy component and presents the
actual transaction data to the user before it is signed.

Previous card readers/smart card combinations relied on host software
to provide the display contents, without any way to check that it
matches the blob that was to be signed.  Of course, it's still
possible to develop a FINREAD application that behaves that way,
perhaps in order to cut down development costs.  As usual, just
because it's FINREAD, it's not automatically secure (and a
transparent mode exists as well).

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


Re: Status of SRP

2006-06-01 Thread Florian Weimer
* James A. Donald:

 The obvious solution to the phishing crisis is the widespread
 deployment of SRP, but this does not seem to happening.  SASL-SRP was
 recently dropped.  What is the problem?

There is no way to force an end user to enter a password only over
SRP.  That's why SRP is not effective against phishing (even the
mimicry variant).  In that regard, the password input field was a huge
mistake.  Fortunately, it doesn't matter because today, we must assume
that the client is thoroughly compromised, which means that entering
passwords over SRP isn't safe, either.

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


Re: Status of opportunistic encryption

2006-05-29 Thread Florian Weimer
* Sandy Harris:

 Recent news stories seem to me to make it obvious that anyone with privacy
 concerns (i.e. more-or-less everyone) should be encrypting as much of their
 communication as possible. Implementing opportunistic encryption is the
 best way I know of to do that for the Internet.

 I'm somewhat out of touch, though, so I do not know to what extent people
 are using it now. That is my question here.

It seems to me opportunistic encryption has moved to the application
layer, at least as far as Internet mail is concerned.  Many MTAs use
TLS automatically with whatever certificates they can get.  Of course,
this only guards against active attacks, but it seems to me that this
is a reasonable threat model.  At least it's like to hide your
important GnuPG-encrypted messages from the casual traffic
analyst. 8-

 and that both of FreeS/WAN's successor projects (openswan.org and
 strongswan.org) mention it in their docs. However, I don't know if it
 actually being used.

Didn't Openswan announce that opportunistic encryption is deprecated?
My impression was that, according to its creators, Freeswan was mainly
about OE, but people used it as a regular IPsec implementation on
Linux.  Openswan tried to bridge that gap, even while the Freeswan
project itself was still active.

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


Re: picking a hash function to be encrypted

2006-05-15 Thread Florian Weimer
* Travis H.:

 IIUC, protocol design _should_ be easy, you just perform some
 finite-state analysis and verify that, assuming your primitives are
 ideal, no protocol-level operations break it.

Is this still true if you don't know your actual requirements?

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


Re: History and definition of the term 'principal'?

2006-04-29 Thread Florian Weimer
* Hadmut Danisch:

 The only precise definition I found is in a law dictionary where it is
 defined as a legal term.

The OED might also be helpful:

  B. [...] 2. a. A chief actor or doer; the chief person engaged in
  some transaction or function, esp. in relation to one employed by or
  acting for him (deputy, agent, etc.); the person for whom and by
  whose authority another acts.
  [...] 1962 H.O. Beecheno Introd. Business Stud. xiii. 117 Whereas an
  agent is not normally allowed to relend his principal's money at
  interest .. a bank is allowed to do this.  1976 Times 22
  Par. (Baltic Exchange Suppl.) p. i/9 The Baltic is unusual in being
  open both to middle men and principals.

I think this is a strong indication that the term is used in one of
its original meanings.  It also explained why nobody thinks it's
necessary to define it properly.

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


Re: NPR : E-Mail Encryption Rare in Everyday Use

2006-03-08 Thread Florian Weimer
* Bill Stewart:

 Or you could try using the Google Keyserver -
   just because there isn't one
 doesn't mean you can't type in 9E94 4513 3983 5F70
 or 9383DE06   or   [EMAIL PROTECTED] PGP Key
 and see what's in Google's cache.

What a peculiar advice.  We know for sure that Google logs these
requests and stores them indefinitely. 8-(

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


Re: NPR : E-Mail Encryption Rare in Everyday Use

2006-02-28 Thread Florian Weimer
* Ben Laurie:

 I don't use PGP - for email encryption I use enigmail, and getting
 missing keys is as hard as pressing the get missing keys button.

A step which has really profound privacy implications.

I couldn't find a PGP key server operator that committed itself to
keeping logs confidential and deleting them in a timely manner (but I
didn't look very hard, either).  Of course, since PGP hasn't
progressed as faster as our computing resources, I'm nowadays in a
position to run my own key server, but this is hardly a solution to
that kind of problem.

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


Re: GnuTLS (libgrypt really) and Postfix

2006-02-14 Thread Florian Weimer
* Werner Koch:

 On Sat, 11 Feb 2006 12:36:52 +0100, Simon Josefsson said:

   1) It invoke exit, as you have noticed.  While this only happen
  in extreme and fatal situations, and not during runtime,
  it is not that serious.  Yet, I agree it is poor design to
  do this in a library.

 I disagree strongly here.  Any code which detects an impossible state
 or an error clearly due to a programming error by the caller should
 die as soon as possible.  If you try to resolve the problem by working
 around it will increase code complexity and thus error won't be
 detected.  (Some systems might provide a failsafe mechanism at a top
 layer; e.g. by voting between independed developed code).

_exit in libraries is fine if you don't service multiple clients from
a single process.  However, with the advent of heavy VMs and stuff
like that, there is a trend towards serving multiple clients from a
single process (which is quite a bad idea in almost all cases, but
this view is rather unpopular).  There are also libraries which
require proper cleanup procedures, otherwise the next program start
can be quite costly (think of databases, where you want to avoid log
replay).  Some services have even been implemented following a
single-process model for more than a decade (IRC servers, for
example).

A user-defined fatal error function (which must not return) would be
a compromise, I think.  Of course, such a function should never be
called if you just see wrong or unsual input.  But with a bit of
optimism, the process could recover from an error which is not locally
recoverable (throw an exception, terminate the offending thread, and
leak the allocated resources).

Now if the library maintains global, per-process state, this is a real
problem.  You can't know for sure if this state is consistent after a
fatal error, unless you program carefully to avoid this situation.
Yet another reason to move this functionality to a separate process. 8-)

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


Re: AW: [Clips] Banks Seek Better Online-Security Tools

2005-12-07 Thread Florian Weimer
* Ulrich Kuehn:

 In 2000 someone here in Germany already demonstrated how to attack
 smart card based HBCI transactions. Those transactions are
 authorized by an RSA signature done by the card.

Here's a link: http://www.heise.de/newsticker/meldung/9349

 The attack relyed on the card reader not having a separate keyboard
 for PIN entry.

In this particular implementation, yes.

There are other attacks if you control the end user system:

You can display a dialog box requesting that the user enters the PIN
on the host, and not on the PIN pad.  Typical smartcard work in
various card readers (with and without PIN pads), so you can later use
the PIN to create additional transactions.

It turns out that you need not do this, though: once the end user has
entered the PIN, you can create as many signatures as you like.  In
this sense, the PIN/TAN approach is more secure than smartcards.

 Interestingly, I wonder what would happen if a reader with display
 and keyboard is used in an online attack, i.e. the adversary sneaks
 in a fraudulent transaction when the hash for the signature is
 computed. I do not know from the top of my head what is supposed to
 be displayed in the reader's display, so I do not know what impact
 such an attempt would have.

The display contents is supplied by the end user computer, not the
smartcard, so it's still possible to break this scheme just by
attacking the computer.

 Any suggestions?

Postbank's mTAN is promising because uses a separate channel which is
currently not very easy to attack, but the activation procedure is
fundamentally flawed.  Costs are probably too high to introduce this
as a general countermeasure, though.

In the long term, we need a standardized device which generates TANs
which depend on the transaction contents (target account and amount).
Standardization is important because you don't want to carry around
such a device for each plastic card you own.

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


Re: [Clips] Banks Seek Better Online-Security Tools

2005-12-06 Thread Florian Weimer
* Nicholas Bohm:

 [EMAIL PROTECTED] wrote:
 You know, I'd wonder how many people on this
 list use or have used online banking.  
 
 To start the ball rolling, I have not and won't.
 
 --dan

 I do.

 My bank provides an RSA SecureId, so I feel reasonably safe against
 anyone other than the bank.

But it's just a token measure.  You should be afraid of your own
computer, your own network.  SecureID does not authenticate the server
you're going to send your data to.  It does not detect if your
computer is compromised.

Sure, right now, it might help you personally, but once these simple
tokens gain market share, attackers will adjust.  It's not a general
solution.

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


Re: [Clips] Banks Seek Better Online-Security Tools

2005-12-06 Thread Florian Weimer
 You know, I'd wonder how many people on this
 list use or have used online banking.  

 To start the ball rolling, I have not and won't.

Why?  Repudiating transactions is easier than ever.  As a consumer, I
fear technology which is completely secure according to experts, but
which can be broken nevertheless.  The current situation is very
different.  Everybody agrees that online banking is insecure, and in
most markets, it's the banks who swallow the losses, not the consumer
(even those who were very stupid).

For those of you who haven't rolled out a national ID scheme in time,
there's still the general identity theft problem, but this affects you
even if you don't use online banking.

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


Re: [Clips] Banks Seek Better Online-Security Tools

2005-12-06 Thread Florian Weimer
* Eugen Leitl:

 The German PIN/TAN system is reasonably secure, being an effective
 one-time pad distributed through out of band channel (mailed dead
 tree in a tamperproof envelope).

Some banks have optimized away the special envelope. 8-(

 It is of course not immune to phishing (PIN/TAN harvesting), which
 has become quite rampant recently.

And we face quite advanced attack technology, mainly compromised end
systems.  We are well beyond the point where simple tokens (like RSA
SecureID) would help.

 I do have a HBCI smartcard setup with my private account but don't use it
 since it's locked in a proprietary software jail.

The way the current attacks are carried out, smartcard-based HBCI is
less secure than the PIN/TAN model because with HBCI, you don't need
to authorize each transaction separately.  At this stage, few people
recognize this problem, and German banks put high hopes on
smartcard-based online banking, despite its high costs in terms of
consumer devices and support calls.

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


Re: [Clips] Banks Seek Better Online-Security Tools

2005-12-06 Thread Florian Weimer
* Jonathan Thornburg:

 Ahh, but how do you know that the transaction actually sent to the
 bank is the same as the one you thought you authorized with that OTP?
 If your computer (or web browser) has been cracked, you can't trust
 _anything_ it displays.  There are already viruses in the wild
 attacking German online banking this way:
   http://www.bsi.bund.de/av/vb/pwsteal_e.htm

Of course you don't.  In some sense, the next-generation security
technology which U.S. banks plan to roll out (either voluntarily, or
due to regulation) has already been broken in Germany.

If you bring the topic up in discussions, the usual answer is don't
MITM me! (meaning: Don't mention man-in-the-middle attacks,
including compromised customer systems, because you know we can't
defend against them! This is not fair!).  But this is not a valid
response when experience shows that the relevant attacks *are* MITM
attacks.

 I also don't trust RSAsafe or other such 2-factor authentication
 gadgets, for the same reason.

I'm always glad to read someone who agrees with me on this matter. 8-)

I don't understand why almost everyone is in a frenzy to deploy them.
If you can somehow weasel through the next 6 months or so, it will be
completely non-repudiatable that transactions covered by two-factor
authentication are fully repudiatable.  You can save a lot of money
(including your customers' money) if you manage to skip this
technology cycle.  The only problem could be that the media and
security experts smack you if you don't deploy the same, broken
countermeasures everyone else does.

By the way, one interesting aspect of the online banking problem is
its implications for threat modelling, attack trees, and similar
approaches.  It would be interesting to compare a few models and why
they fail to adequately describe the situation.  My hunch is that
these models do not take two factors into account: Attacks aren't
targeted by the cost/revenue alone, tradition plays a major role, too,
as does sheer luck.  And you are caught in a feedback loop; the
attacks change as you deploy new countermeasures, and the changes are
mostly unpredictable.

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


Re: ISAKMP flaws?

2005-11-18 Thread Florian Weimer
* Peter Gutmann:

 I haven't been following the IPSec mailing lists of late -- can anyone
 who knows details explain what the issue is?

These bugs have been uncovered by a PROTOS-style test suite.  Such test
suites can only reveal missing checks for boundary conditions, leading to
out- of-bounds array accesses and things like that.  In other words, trivial
implementation errors which can be easily avoided using proper programming
tools.

 I feel a need to comment on statements like this... at several times
 in the past I've seen people make sweeping generalisation like this,
 Everyone knows about this security weakness, this { paper | article
 | security alert } isn't { novel | interesting | worth publishing },

Touché.

 or some variant thereof (in this case these trivial errors are
 easily avoided).

Of course, the relevance of a bug and how easily it could have been
avoided are completely different matters.  I mainly wanted to point
out that there is no new cryptography involved.

 What makes these statements rather unconvincing is that the majority
 of all implementations out there all make these trivial
 easily-avoided errors

They have chosen different trade-offs, focusing on performance,
time-to-market and things like that.  It's hard enough to create an
ISAKMP implementation that works at all.

 In this particular case if the problem is so trivial and easily
 avoided, why does almost every implementation (according to the
 security advisory) get it wrong?

How many completely independent implementations are there?

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


Re: ISAKMP flaws?

2005-11-18 Thread Florian Weimer
* William Allen Simpson:

 Quoting Photuris: Design Criteria, LNCS, Springer-Verlag, 1999:

   The hallmark of successful Internet protocols is that they are
   relatively simple.  This aids in analysis of the protocol design,
   improves implementation interoperability, and reduces operational
   considerations.

 Compare with Photuris [RFC-2522], where undergraduate (Keromytis) and
 graduate (Spatscheck, Provos) students independently were able to
 complete interoperable implementations (in their spare time) in a
 month or so

Photuris uses a baroque variable-length integer encoding similar to
that of OpenPGP, a clear warning sign. 8-/ The protocol also contains
nested containers which may specify conflicting lengths.  This is one
common source of parser bugs.

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


Re: ISAKMP flaws?

2005-11-18 Thread Florian Weimer
* William Allen Simpson:

 Florian Weimer wrote:
 Photuris uses a baroque variable-length integer encoding similar to
 that of OpenPGP, a clear warning sign. 8-/ 

 On the contrary:

  + a VERY SIMPLE variable-length integer encoding, where every number
has EXACTLY ONE possible representation (unlike ASN.1 which even the
spell-checker wants to replace with assinine).

  + similar to that of OpenPGP, the most common Open Source security
software of the era, where the code could be easily reused (as it
was in the initial implementation).

Even back then, the integer encoding was considered to be a mistake.

| I concur completely. I once got so fed up with this habit that I
| tromped around the office singing, Every bit is sacred / Every bit
| is great / When a bit is wasted / Phil gets quite irate.
| 
| Consider this to be one of the prime things to correct. Personally,
| I think that numbers should never (well, hardly ever) be smaller
| than 32 bits.

(Jon Callas, 1997-08-08)

 The protocol also contains
 nested containers which may specify conflicting lengths.  This is one
 common source of parser bugs.
 
 On the contrary, where are internal nested containers in the protocol?

Variable-length integers within other fields, for example.  You can't
avoid this phenomenon in its entirety, of course, without sacrificing
some of the advantages of a binary encoding.

 Again, the ISAKMP flaws were foreseeable and avoidable.  And Photuris
 was written before the existence of ISAKMP.

I like ISAKMP as much as the next guy, but somehow I doubt that
simpler protocols necessarily lead to more robust software.  Sure,
less effort is needed to implement them, but writing robust code still
comes at an extra cost. *sigh*

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


Re: ISAKMP flaws?

2005-11-17 Thread Florian Weimer
* Perry E. Metzger:

 I haven't been following the IPSec mailing lists of late -- can anyone
 who knows details explain what the issue is?

These bugs have been uncovered by a PROTOS-style test suite.  Such
test suites can only reveal missing checks for boundary conditions,
leading to out-of-bounds array accesses and things like that.  In
other words, trivial implementation errors which can be easily avoided
using proper programming tools.

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


Re: FW: Fermat's primality test vs. Miller-Rabin

2005-11-13 Thread Florian Weimer
* Charlie Kaufman:

 The probability of a single run of Miller-Rabin or Fermat not
 detecting that a randomly chosen number is composite is almost
 vanishingly small.

How do you chose a random integer, that this, based on which
probability distribution? 8-)

Anyway, one can show that for some fixed number, the probability that
one run of the Miller-Rabin algorithm fails (i.e. reports potentially
prime for a composite) does not exceed 1/4.  Knuth gives a proof in
an exercise in Volume 2 of The Art of Computer Programming, including
an example that the 1/4 bound is pretty good.  However, this answers a
slightly different question.

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


Re: How broad is the SPEKE patent.

2005-11-11 Thread Florian Weimer
* James A. Donald:

 I figured that the obvious solution to all this was to deploy zero 
 knowledge technologies, where both parties prove knowledge of the 
 shared secret without revealing the shared secret.

Keep in mind that one party runs the required software on a computed
infected with spyware and other kinds of Trojan horses.  This puts the
effectiveness of zero-knowledge proofs into question.

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


Re: Cisco VPN password recovery program

2005-10-20 Thread Florian Weimer
* Perry E. Metzger:

 Via cryptome:

 http://evilscientists.de/blog/?page_id=343

The Cisco VPN Client uses weak encryption to store user and group
passwords in your local profile file.  I coded a little tool to
reveal the saved passwords from a given profile file.

 If this is true, it doesn't sound like Cisco used a particularly smart
 design for this.

Why?  In essence, this is the PSK that is used to authenticate the VPN
gateway.  It must be available in cleartext on the client.

(Later versions offer asymmetric encryption as well.)

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


Re: Cisco VPN password recovery program

2005-10-20 Thread Florian Weimer
 http://www.cisco.com/en/US/products/hw/vpndevc/ps2284/products_configuration_guide_chapter09186a00803ee1f0.html#wp2477015

 - - -

 Cisco Client Parameters

 Allow Password Storage on Client - Check this box to allow IPSec
 clients to store their login passwords on their local client
 systems. If you do not allow password storage (the default), IPSec
 users must enter their password each time they seek access to the
 VPN. For maximum security, we recommend that you not allow password
 storage.

 - - -

I really doubt that this affects group password (PSK).

In some cases, network administrators used the password obfuscation to
force their users to use Cisco's VPN client.  Competing products, such
as vpnc, do not enforce client-side policies.  However, there's been a
website where you can upload the obfuscated password, and it returns
the password in clear text for quite some time now.  It is implemented
by running the Cisco client under a debugging tool, intercepting a
memcpy call that copies the password.

In the end, the publication of the algorithm doesn't change the
security of the system (there wasn't much to start with).  But it's
certainly easier to write interoperable software using this
information.

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


  1   2   >