XML-proof UIDs
Does anyone have robust code to generate globally unique IDs which won't break XML parsing, and work on several platforms? I was thinking of using an entropy pool to seed a cryptographic PRNG, used to generate a sequence of SHA-1 hashes, dumped to an XML-armored representation. Thanks. -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE pgp0.pgp Description: PGP signature
Re: The future of security
On Fri, May 28, 2004 at 09:46:03AM -0700, bear wrote:
> Spam won't stop until spam costs the spammers money.
If I'm a node in a web of trust (FOAF is a human), prestige will
percolate through it completely. That way I can color a whole domain with a
nonboolean trust hue, while a domain of fakers will have only very few
connections (through compromises, or human mistakes), which will rapidly sealed,
once actually used to do something to lower their prestige ("I signed the key
of a spammer, please kill me now").
Of course, tracking prestige globally, robustly in a p2p fashion is
difficult, and will require agoric load levelling elements (to prevent bad
nodes from DoSing the global store) which also requires prestige tracking.
--
Eugen* Leitl http://leitl.org";>leitl
__
ICBM: 48.07078, 11.61144http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
http://moleculardevices.org http://nanomachines.net
pgpnR1gxzugWi.pgp
Description: PGP signature
Re: Satellite eavesdropping of 802.11b traffic
On Fri, May 28, 2004 at 01:19:15PM -0500, Matt Crawford wrote: > Don't dismiss possibilities for wireless data eavesdropping without > considering the possibilities of this new chip > > http://pr.caltech.edu/media/Press_Releases/PR12490.html > > and its friends > > http://www.chic.caltech.edu/ If you want to fly a LEO constellation of them, you need a very sparse structure (or a huge density of pongsats, which doesn't agree with observations). -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpjSdYUSaXAn.pgp Description: PGP signature
Re: The future of security
On Sun, May 30, 2004 at 12:36:53PM -0700, bear wrote:
> > > If I'm a node in a web of trust (FOAF is a human), prestige will
> > > percolate through it completely. That way I can color a whole
> > > domain with a nonboolean trust hue, while a domain of fakers will
> > > have only very few connections (through compromises, or human
> > > mistakes), which will rapidly sealed, once actually used to do
> > > something to lower their prestige ("I signed the key of a spammer,
> > > please kill me now").
> >
> >The trouble is that it requires human action, which is expensive and
> >becoming more expensive.
Sending mail originating with a person always requires human action.
If one cannot be bothered to mark friends in his addressbook as humans (in
fact, the very act of adding someone to an addressbook is sufficient, that
information just needs to be processed).
Do spammers have many friends? They certainly network.
> The bigger problem is that webs of trust don't work.
> They're a fine idea, but the fact is that nobody keeps
> track of the individual trust relationships or who signed
The point of an automated web of trust is that the machine is doing the
accounting for you.
> a key; few people even bother to find out whether there's
> a path of signers that leads from them to another person,
> or whether the path has some reasonably small distance.
Human network connectivity have such properties. The entire graph is
connected, and each person is reachable via a few hops. Given that there are
only a few billion people on this planet, such a database should be quite
easy to store and to query in a P2P fashion. It only becomes nontrivial when
it has to distributed, and immune to content forgery and DoS.
> I have not yet seen an example of "reputation" favoring
> one person over another in a web of trust model; it looks
> like people can't be bothered to keep track of the trust
> relationships or reputations within the web.
The real issue is whether people can volunteer information stored in their
addressbook. Not everybody is an Orkut/Friendster/FOAF exhibitionist.
--
Eugen* Leitl http://leitl.org";>leitl
__
ICBM: 48.07078, 11.61144http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
http://moleculardevices.org http://nanomachines.net
pgpWOhjdsjGGI.pgp
Description: PGP signature
Re: The future of security
On Mon, May 31, 2004 at 08:27:49PM -0700, bear wrote: > >The point of an automated web of trust is that the machine is doing the > >accounting for you. > > Does it? If there were meaningful reputation accounting You got fooled by the present tense. If there was such an architecture, I wouldn't have written that message. The distributed tamper-proof cryptographic p2p store should have been a dead giveaway. > happening, we'd be getting feedback and value judgements > from the system on the people we were corresponding with. > Have you ever seen any? No, of course. See above. > Has there been *ANY* instance of negative consequences > accruing to someone who signed the key of an entity which > later defected? Machine-moderated or not, the web of > trust fails. The web of trust sure fails, dunno about machine-moderated. There's no such animal yet. > Have you seen any web-of-trust implementation that even > *considers* the trustworthiness of the key servers? Have > you seen any web-of-trust implementation that works to > cut out defectors, but couldn't be "autospammed" to cut > out anyone you didn't like? If you don't have their key, you can't pretend to sign the spambots'. If you sign the spambots', you burn whatever little prestige you have happened to start out with, and drained the mana of whatever hapless warm body signed your keys. > Sorry; but the fact is no web-of-trust implementation to > date works, or even comes close to working. Web of trust is useless, if Johnny User is supposed to do the checking. -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpPzt821GHi8.pgp Description: PGP signature
Re: Article on passwords in Wired News
On Thu, Jun 03, 2004 at 08:14:39PM +1200, Peter Gutmann wrote: > One-time passwords (TANs) was another thing I covered in the "Why isn't the > Internet secure yet, dammit!" talk I mentioned here a few days ago. From > talking to assorted (non-European) banks, I haven't been able to find any that Customers hate PINs/TANs (have to carry then around, PINs typically are not alphanumeric, and fixed-length, print is low-contrast). Which is why power users have a (Windows-only, for some reason couldn't get GNUcash working, despite right crypto libraries and proper port punched through firewall) HBCI software alternatives. Which are not used widely, alas. Banks tried to push smart cards, but very half-heartedly (didn't offer free readers, which could have created critical mass). Now some folks are trying to use existing smartcard-authenticated mobile phone infrastructure for online payments, but it has its own problems (Bluetooth/IrDa, security, fax effect, etc). -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpp37oZjAHGy.pgp Description: PGP signature
Interview with Glenn Henry, founder of VIA processor subsidiary Centaur (fwd from [EMAIL PROTECTED])
From: Eugen Leitl <[EMAIL PROTECTED]> Subject: Interview with Glenn Henry, founder of VIA processor subsidiary CeTo: [EMAIL PROTECTED] Date: Tue, 15 Jun 2004 18:51:21 +0200 http://linuxdevices.com/articles/AT2656883479.html [ker-snip] The third one, is one you haven't asked me about, this is actually my pet hobby, here -- we've added these fully sophisticated and very powerful security instructions into the... Q19: That was my last question! A19: So the classic question is, hey, you built some hardware, who's going to use it? Well, the answer is, six months after we first started shipping our product with encryption in it [story], we have three or four operating systems, including Linux, OpenBSD, and FreeBSD, directly supporting our security features in the kernel. Getting support that quickly can't happen in the Microsoft world. Maybe they'll support it someday, maybe they won't. Quite honestly, if you want to build it, and hope that someone will come, you've got to count on something like the free software world. Free software makes it very easy for people to add functionality. You've got extremely talented, motivated people in the free software world who, if they think it's right to do it, will do it. That was my strategy with security. We didn't have to justify it, because it's my hobby, so we did it. But, it would have been hard to justify these new hardware things without a software plan. My theory was simple: if we do it, and we do it right, it will appeal to the really knowledgeable security guys, most of whom live in the free software world. And those guys, if they like it, and see it's right, then they will support it. And they have the wherewithal to support it, because of the way open software works. So those are my three themes, ignoring the fourth one, that's obvious: that without competition, Windows would cost even more. To summarize, for our business, [Linux is] important because it allows us to build lower-cost PC platforms, it allows people to build new, more sophisticated embedded applications easier, and it allows us, without any software costs, to add new features that we think are important to the world. Our next processor -- I haven't ever told anyone, so I won't say what it is -- but our next processor has even more things in it that I think will be just as quickly adopted by the open source software world, and provide even more value. It's always bothered me that hardware can do so many things relatively easily and fast that aren't done today because there's no software to support it. We just decided to try to break the mold. We were going to do hardware that, literally, had no software support at the start. And now the software is there, in several variations, and people are starting to use it. I actually think that's only going to happen in the open source world. Q20: We'd like a few words from you about your security strategy, how you've been putting security in the chips, and so on. A20: Securing one's information and data is sort of fundamental to the human need -- it's certainly fundamental to business needs. With the current world, in which everyone's attached to the Internet -- with most peoples' machines having back-door holes in them, whether they know it or not -- and with all the wireless stuff going on, people's data, whether they know it or not, is relatively insecure. The people who know that are using secure operating systems, and they're encrypting their data. Encrypting of data's been around for a long time. We believe, though, that this should be a pervasive thing that should appear on all platforms, and should be built into all things. It turns out, though, that security features are all computationally intensive. That's what they do. They take the bits and grind them up using computations, in a way that makes it hard to un-grind them. So, we said, they're a perfect candidate for hardware. They're well-defined, they're not very big, they run much faster in hardware than in software -- 10 to 30 times, in the examples we use. And, they are so fundamental, that we should add the basic primitives to our processor. How did we know what to add? We added government standards. The U.S. government has done extensive work on standardizing the encryption protocols, secure digital signature protocols, secure hash protocols. We used the most modern of government standards, built the basic functions into our chip, and did it in such a way that made it very easy for software to use. Every time you send an email, every time you send a file to someone, that data should be encrypted. It's going out on the Internet, where anyone with half a brain can steal it. Second, if you really care about not letting people have access to certain data that's on your hard drive, it ought to be en
Re: EZ Pass and the fast lane ....
On Sun, Jul 11, 2004 at 10:39:18AM +0200, Amir Herzberg wrote: > So I think this observation about EZ Pass is probably true, but for some > time ago; with current technology, reading license plates is possible > (which, I guess, has some alarming privacy implications...). While Toll Collect (the german system) isn't yet operational, the license plate realtime OCR part is. It does read license plates in realtime via video from overhead bridges, no slowing down necessary. The police is very interested to keep that part of the infrastructure operational, for obvious reasons. Currently, all non-truck license plates are discarded, but it's clear enough theres demand for realtime tracing of select and movement profiles for the masses, for data mining. -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgppD15jCtboO.pgp Description: PGP signature
[Muscle] [PATCH] MuscleCard engine for OpenSSL (fwd from mgold@cbnco.com)
From: Michael Gold <[EMAIL PROTECTED]> Subject: [Muscle] [PATCH] MuscleCard engine for OpenSSL To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Date: Fri, 27 Aug 2004 16:21:23 -0400 Reply-To: [EMAIL PROTECTED], MUSCLE <[EMAIL PROTECTED]> I've created a patch to add a MuscleCard engine to OpenSSL 0.9.7d, allowing it to access smart cards using the MuscleCard API. It is located at: http://www.scs.carleton.ca/~mgold/patches/openssl-add-mcard.patch This engine implements RSA encryption (signing) and decryption using a private key stored on a MuscleCard-compatible smart card. It has been tested with a Cyberflex e-gate 32K Java Card running MUSCLE's CardEdgeApplet (using the MCardPlugin service for PCSC Lite). Usage example - This command will use the MuscleCard engine to create a self-signed certificate: openssl req -new -text -sha1 -x509 \ -engine musclecard -keyform engine \ -key "E-Gate 00 00:0:1::/var/ssl/cflex_pub.key" \ -out cacert.pem The meaning of the key string is as follows: Use PCSC Lite reader "E-Gate 00 00" Private key 0 Authenticate with PIN #1, value "" Public key is stored in /var/ssl/cflex_pub.key (to export public key 1 using muscleTool: "exportkey 1 /var/ssl/cflex_pub.key") - Michael ___ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle -- -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpyZD9poPZbT.pgp Description: PGP signature
[wearables] CFP: Workshop on Pervasive Computing and Communication Security (fwd from [EMAIL PROTECTED])
From: Bob Mayo <[EMAIL PROTECTED]> Subject: [wearables] CFP: Workshop on Pervasive Computing and Communication Security To: [EMAIL PROTECTED] Date: Thu, 2 Sep 2004 16:36:15 -0700 (PDT) Reply-To: [EMAIL PROTECTED] CALL FOR PAPERS PerSec 2005 Second IEEE International Workshop on Pervasive Computing and Communication Security Held in conjunction with IEEE PerCom 2005 8 March 2005, Kauai island, Hawaii, USA http://www.cl.cam.ac.uk/persec-2005/ Research in pervasive computing continues to gain momentum. The importance of security and privacy in a pervasive computing environment cannot be underestimated. PerSec 2005 will bring together the world's experts on this topic and provide an international forum to stimulate and disseminate original research ideas and results in this field. Contributions are solicited in all aspects of security and privacy in pervasive computing, including: Models for access control, authentication and privacy management. Incorporation of contextual information into security and privacy models, and mechanisms. Management of tradeoffs between security, usability, performance, power consumption and other attributes. Architectures and engineering approaches to fit security and privacy features into mobile and wearable devices. Biometric methods for pervasive computing. Descriptions of pilot programs, case studies, applications, and experiments integrating security into pervasive computing. Auditing and forensic information management in pervasive settings. Protocols for trust management in networks for pervasive computing. Incorporation of security into communication protocols, computing architectures and user interface designs for pervasive computing. Impact of security and privacy in relation to the social, legal, educational and economic implications of pervasive computing. INSTRUCTIONS FOR AUTHORS Papers must be sent to persec-2005 at cl.cam.ac.uk as file attachments in Adobe PDF format. Papers must have authors' affiliation and contact information on the first page. Papers must be unpublished and not being considered elsewhere for publication. In particular, papers submitted to PerSec must not be concurrently submitted to PerCom in identical or modified form. Papers must be formatted in strict accordance with the IEEE Computer Society author guidelines published at ftp://pubftp.computer.org/Press/Outgoing/proceedings/INSTRUCT.HTM. For your convenience, templates are available at ftp://pubftp.computer.org/Press/Outgoing/proceedings/. LaTeX is recommended. Papers are limited to 5 pages in IEEE 8.5x11 conference format. Excessively long papers will be returned without review. Papers selected for presentation will be published in the Workshop Proceedings of PerCom 2005 by IEEE Press. IMPORTANT DATES === Paper submission: 13 September 2004 Acceptance Notification: 15 November 2004 Camera-ready manuscripts: 29 November 2004 PerSec Workshop: 8 March 2005 (first day of PerCom, which runs until the 12th) PROGRAM CO-CHAIRS = * Frank Stajano, University of Cambridge, UK * Roshan Thomas, McAfee Research, USA SECRETARY = * Boris Dragovic, University of Cambridge, UK Contact email (goes to co-chairs and secretary): persec-2005 at cl.cam.ac.uk STEERING COMMITTEE CHAIR * Ravi Sandhu, George Mason University, USA PROGRAM COMMITTEE = * Tuomas Aura, Microsoft Research, UK * Mark Corner, UMass, USA * Srini Devadas, MIT, USA * Boris Dragovic, University of Cambridge, UK * Naranker Dulay, Imperial College, UK * Kris Gaj, George Mason University, USA * Robert Grimm, NYU, USA * Dieter Hutter, DFKI, Germany * Ari Juels, RSA Laboratories, USA * Tim Kindberg, HP Labs Bristol, UK * Cetin Kaya Koc, Oregon State University, USA * Marc Langheinrich, ETH Zurich, Switzerland * Mark Lomas, BIICL, UK * Robert N. Mayo, HP Labs Palo Alto, USA * Refik Molva, Eurecom, France * Kai Rannenberg, University of Frankfurt, Germany * Stephen Weis, MIT ------ -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpGBv9c4Gh1h.pgp Description: PGP signature
Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from hal@finney.org) (fwd from touch@ISI.EDU)
From: Joe Touch <[EMAIL PROTECTED]>
Subject: Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd frTo:
"Discussions of anonymous Internet security." <[EMAIL PROTECTED]>
Date: Fri, 10 Sep 2004 09:03:50 -0700
Reply-To: "Discussions of anonymous Internet security." <[EMAIL PROTECTED]>
Clarifications below...
Eugen Leitl wrote:
>- Forwarded message from "\"Hal Finney\"" <[EMAIL PROTECTED]> -
>
>From: [EMAIL PROTECTED] ("Hal Finney")
>Date: Thu, 9 Sep 2004 12:57:29 -0700 (PDT)
>To: [EMAIL PROTECTED], [EMAIL PROTECTED],
> [EMAIL PROTECTED]
>Subject: Re: potential new IETF WG on anonymous IPSec
>
>
>>The IETF has been discussing setting up a working group
>>for anonymous IPSec. They will have a BOF at the next IETF
>>in DC in November. They're also setting up a mailing list you
>>might be interested in if you haven't heard about it already.
>>...
>> http://www.postel.org/anonsec
>
>
>To clarify, this is not really "anonymous" in the usual sense.
It does not authenticate the endpoint's identification, other than "same
place I had been talking to."
There's no difference between having no "name" and having a name you
cannot trust. I.e., I could travel under the name "anonymous" or "", or
under the name "A. Smith". If you don't know whether I am actually A.
Smith, the latter is identical to the former.
>Rather it
>is a proposal to an extension to IPsec to allow for unauthenticated
>connections.
Correction: it is a proposal to extend Internet security - including
Ipsec, but also including TCP-MD5 (sometimes called "BGP MD5") and other
security mechanisms at various layers. It is not focused only on IPsec.
>Presently IPsec relies on either pre-shared secrets or a
>trusted third party CA to authenticate the connection. The new proposal
>would let connections go forward using a straight Diffie-Hellman type
>exchange without authentication.
This is one option, but not the only one.
>It also proposes less authentication
>of IP message packets, covering smaller subsets, as an option.
There are two aspects:
- smaller portion of the packet is hashed
- none of the packet is hashed, but a cookie is used
>The point has nothing to do with anonymity;
The last one, agreed. But the primary assumption is that we can avoid a
lot of infrastructure and impediment to deployment by treating an
ongoing conversation as a reason to trust an endpoint, rather than a
third-party identification. Although anonymous access is not the primary
goal, it is a feature of the solution.
>rather it is an attempt
>to secure against weaknesses in TCP which have begun to be exploited.
Please review the draft; there are a number of reasons this is being
considered, not the least of which is to reduce the cumbersome
requirement of key infrastructure as well as to avoid performance penalties.
>Sequence number guessing attacks are more successful today because of
>increasing bandwidth, and there have been several instances where they
>have caused disruption on the net. While workarounds are in place, a
>better solution is desirable.
Please be more specific; how would it be better?
>This new effort is Joe Touch's proposal to weaken IPsec so that it uses
>less resources and is easier to deploy. He calls the weaker version
>AnonSec. But it is not anonymous, all the parties know the addresses
>of their counterparts.
Address != identity. Agreed, if what you want to do is hide traffic,
this does not provide traffic confidentiality. But it does not tell you
whether the packets come from 128.9.x.x (ISI, e.g.) or from someone
spoofing 128.9.x.x; all you know is that whoever is using that address
is capable of having an ongoing conversation (TCP connection, e.g.) with
you.
I.e., there are two ways to be anonymous, as noted earlier:
1) don't give out your name (A. Smith, e.g.)
2) give out a name, but it doesn't necessarily mean anything
(e.g., Mickey Mouse)
Even if you use "real" names in (2), there's no difference with (1),
since you don't know whether the real Mickey Mouse is using it.
>Rather, it allows for a degree of security on
>connections between communicators who don't share any secrets or CAs.
>I don't think "anonymous" is the right word for this, and I hope the
>IETF comes up with a better one as they go forward.
>
>Hal Finney
>
>-----
>The Cryptography Mailing List
>Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
>
>- End forwarded message -
>
>
pci hardware for secure crypto storage (OpenSSL/OpenBSD)
I'm looking for (cheap, PCI/USB) hardware to store secrets (private key) and support crypto primitives (signing, cert generation). It doesn't have to be fast, but to support loading/copying of secrets in physically secure environments, and not generate nonextractable secret onboard. Environment is OpenBSD/Linux/OpenSSL/gpg. Any suggestions? -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpFez8InSggV.pgp Description: PGP signature
Re: pci hardware for secure crypto storage (OpenSSL/OpenBSD)
On Wed, Sep 15, 2004 at 04:30:54PM +0100, Ian Grigg wrote: > There is a device that is similar to those characteristics: > > http://woudt.nl/epass-pgp/ "If you loose or damage your token: you loose your private key and any data encrypted to it. Because the key is generated inside the token and cannot leave it, it is not possible to make a backup of the private key." is a knockout criterium, though. Also an interactive PIN entry for each interaction is a no-no, if the machine is in a rack at the host. H4x0rs may break in and sign a few stray blobs, but they won't be able to steal the private key itself. > http://www.financialcryptography.com/mt/archives/000201.html -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpjYj6c7OaaW.pgp Description: PGP signature
Re: public-key: the wrong model for email?
On Fri, Sep 17, 2004 at 07:35:09PM +0100, Ian Grigg wrote: > Oh, that's really easy. Each mailer (MUA) should (on > install) generate a self-signed cert. Stick the fingerprint apt-get install postfix-tls Allright, this still doesn't generate the certs, nor reference them in the main.cf. > in the headers of every mail going out. An MUA that sees > the fingerpring in an incoming mail can send a request email > to acquire the full key. Or stick the entire cert in there, > it's not as if anyone would care. I would cache the cert fingerprints, and log when those change. > Then each MUA can start encrypting to that key opportunistically. Start/TLS does encrypt my mail far more often the PGP/GPG. > Lots of variations. But the key thing is that the MUA > should simply generate the key, sign it, and send it out > on demand, or more freuqently. There's really no reason > why this can't all be automated. After all, the existing > email system is automated, and trusted well enough to > deliver email, so why can't it deliver self-signed certs? Talk to Exim/Postfix maintainers. They should ship self-signed cert Start/TLS config out of the box. Even without cert caching, that'd require a MITM. Not exactly cheap, and prone to detection, if practiced on a nonnegligible scale (fingerprint checking). -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpeT5sla0uHs.pgp Description: PGP signature
Re: Financial identity is *dangerous*? (was re: Fake companies, real money)
On Sat, Oct 23, 2004 at 06:58:26PM +1300, Aaron Whitehouse wrote: > That would seem to me a more realistic expectation on consumers who are > going to have, before too long, credit cards that fit that description > and quite possibly the readers to go with them. No, that's going to be the mobile phone. These already come with smartcards; unfortunately their security is really lousy, so a secure pathway into the secure crypto compartment for PIN entry is required. In practice, no one is going to give a damn, until PIN-harvesting Bluetooth & Co worms will result in palpable loss for the institutions. -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgp3osMYWdf71.pgp Description: PGP signature
Re: VIA PadLock reloaded (fwd from [EMAIL PROTECTED])
From: Michal Ludvig <[EMAIL PROTECTED]> Subject: Re: VIA PadLock reloaded To: James Morris <[EMAIL PROTECTED]> Cc: CryptoAPI List <[EMAIL PROTECTED]> Date: Sun, 24 Oct 2004 01:55:03 +0200 From: Michal Ludvig <[EMAIL PROTECTED]> Date: Sun, 24 Oct 2004 01:55:03 +0200 To: James Morris <[EMAIL PROTECTED]> Cc: CryptoAPI List <[EMAIL PROTECTED]> Subject: Re: VIA PadLock reloaded User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 Michal Ludvig wrote: > James Morris wrote: > >> On Sat, 23 Oct 2004, Michal Ludvig wrote: >> >>> I'm currently updating the driver for VIA PadLock cryptoengine and once >>> I'm on it I'd like to prepare it for kernel inclusion. >> >> Have you done any performance measurements with this? It would be >> interesting to see its effect on IPSec and disk encryption. > > Yes, some numbers are at http://www.logix.cz/michal/devel/padlock/bench.xp Just in case you have already looked there - few minutes ago I have added a new section with IPsec benchmark. Rough results: Plaintext throughput: 11.21 MB/s IPsec (ESP/transport) without HMAC: - PadLock AES: 11.00 MB/s (keylen independent) - AES-i586: 8.01 to 9.84 MB/s depending on the keylen - Generic C AES: 6.37 to 8.24 MB/s IPsec with HMAC-SHA256: - PadLock AES: 8.06 MB/s - Software AES slower by some 45% than without HMAC. As soon as I get VIA Esther that can do SHA1/SHA256 in hardware I'll update the padlock driver as well. Than I expect almost no slowdown even in HMAC mode (which is almost always used in ESP). Michal Ludvig ___ Subscription: http://lists.logix.cz/mailman/listinfo/cryptoapi List archive: http://lists.logix.cz/pipermail/cryptoapi -- -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgp2BDUwIHk2S.pgp Description: PGP signature
OpenSSL 0.9.7e released (fwd from [EMAIL PROTECTED])
From: Mark J Cox <[EMAIL PROTECTED]> Subject: OpenSSL 0.9.7e released To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Date: Mon, 25 Oct 2004 14:49:49 +0100 (BST) Reply-To: [EMAIL PROTECTED] From: Mark J Cox <[EMAIL PROTECTED]> Date: Mon, 25 Oct 2004 14:49:49 +0100 (BST) To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: OpenSSL 0.9.7e released Reply-To: [EMAIL PROTECTED] OpenSSL version 0.9.7e released == OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 0.9.7e of our open source toolkit for SSL/TLS. This new OpenSSL version is a bugfix release and incorporates changes and bugfixes to the toolkit (for a complete list see http://www.openssl.org/source/exp/CHANGES ). The most significant changes are: o Fix race condition in CRL checking code. o Fixes to PKCS#7 (S/MIME) code. We consider OpenSSL 0.9.7e to be the best version of OpenSSL available and we strongly recommend that users of older versions upgrade as soon as possible. OpenSSL 0.9.7e is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): o http://www.openssl.org/source/ o ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-0.9.7e.tar.gz MD5 checksum: a8777164bca38d84e5eb2b1535223474 The checksums were calculated using the following command: openssl md5 < openssl-0.9.7e.tar.gz Yours, The OpenSSL Project Team... Mark J. Cox Ben Laurie Andy Polyakov Ralf S. Engelschall Richard Levitte Geoff Thorpe Dr. Stephen Henson Bodo Möller Lutz JänickeUlf Möller __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] ------ -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpYa6NOSCgEG.pgp Description: PGP signature
Re: Financial identity is *dangerous*? (was re: Fake companies, real money)
On Thu, Oct 28, 2004 at 09:29:21AM -0700, James A. Donald wrote: > Is there a phone that is programmable enough to store secrets > on and sign and decrypt stuff? Er, it has been a while since you bought a new mobile, right? About all of them have several MBytes memory, and run Java. Some Motorolas run Linux. The better smart phones are pretty beefy PDAs. > The ideal crypto device would be programmed by burning new > proms, thus enabling easy reprogramming, while making it > resistant to trojans and viruses. The problem with modern mobiles that their security is of the cargo cult/snake oil variety. Only a question of time before the first MMS worm wipes out all Nokias, or something. -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgp0TewpfHhVX.pgp Description: PGP signature
RC4 optimized for AMD64 (+130% speedup) (fwd from [EMAIL PROTECTED])
From: Marc Bevand <[EMAIL PROTECTED]> Subject: RC4 optimized for AMD64 (+130% speedup) To: [EMAIL PROTECTED] Date: Mon, 8 Nov 2004 14:24:00 +0100 Reply-To: [EMAIL PROTECTED] Hello, I have published a paper about optimizing RC4 for AMD64. A working implementation, designed to be easily integrated into OpenSSL, is also provided: http://epita.fr/~bevand_m/papers/rc4-amd64.html I would love seeing this integrated into OpenSSL. -- Marc Bevand http://www.epita.fr/~bevand_m Computer Science School EPITA - System, Network and Security Dept. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] -- -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpNHzZXDMQy7.pgp Description: PGP signature
OCF port to linux (fwd from [EMAIL PROTECTED])
List archive: http://lists.logix.cz/pipermail/cryptoapi -- -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpZEaJx0O0JX.pgp Description: PGP signature
[PadLock] PadLock patches for linux kernel 2.6.10 (fwd from [EMAIL PROTECTED])
From: Michal Ludvig <[EMAIL PROTECTED]> Subject: [PadLock] PadLock patches for linux kernel 2.6.10 To: [EMAIL PROTECTED] Date: Fri, 7 Jan 2005 17:24:02 +0100 (CET) From: Michal Ludvig <[EMAIL PROTECTED]> Date: Fri, 7 Jan 2005 17:24:02 +0100 (CET) To: [EMAIL PROTECTED] Subject: [PadLock] PadLock patches for linux kernel 2.6.10 Hi all, Updated VIA PadLock drivers for linux kernel 2.6.10 are available at http://www.logix.cz/michal/devel/padlock/ The recently reported problem with GCC 3.4.3 is addressed there. Good news - initial PadLock support was accepted into the vanilla kernel in 2.6.10-bk1 (i.e. right after 2.6.10 was released). Official kernel 2.6.11 will have it without patching. Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal ___ PadLock mailing list [EMAIL PROTECTED] http://lists.logix.cz/mailman/listinfo/padlock -- -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpIVdKKi4vFz.pgp Description: PGP signature
Re: [PATCH 1/2] CryptoAPI: prepare for processing multiple buffers at a time (fwd from [EMAIL PROTECTED])
_mode, 1, IFACE_ECB); ops->cit_encrypt_iv = cia->cia_modesel(cit_mode, 0, IFACE_IV); ops->cit_decrypt_iv = cia->cia_modesel(cit_mode, 1, IFACE_IV); .. Alternatively, we could also add a lookup table. But I like this better, since this is much easier to read for people, and tfm's aren't alloced that often. Probably, we can add a wrapper for cia_modesel, that when cia_modesel is NULL, it falls back to the old behaviour. This way, we don't have to patch all algorithm implementations to include cia_modesel. How you like that idea? -- Fruhwirth Clemens <[EMAIL PROTECTED]> http://clemens.endorphin.org ___ Subscription: http://lists.logix.cz/mailman/listinfo/cryptoapi List archive: http://lists.logix.cz/pipermail/cryptoapi -- -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpWB3vfqgnfG.pgp Description: PGP signature
[i2p] Tunnel cryptography for I2P 0.5 (corrected typo) (fwd from [EMAIL PROTECTED])
l: * We have a message M we want to send. * We are the tunnel creator, so we have everyone's secret keys. We build M* by doing encrypt(N), encrypt(N-1), ..., encrypt(1). * We send M* to hop 1. Hops 1, 2, ..., N successively decrypt. * The outbound tunnel endpoint recovers M. [1]. http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/ tunnel.html?rev=HEAD [2]. http://dev.i2p.net/~jrandom/tunnel-alt.html [3]. A hash table or alternatively a bloom filter can be used to detect whether we have previously seen a preIV. This document has been placed in the public domain by Connelly Barnes, 2005-01-17. ___ i2p mailing list [EMAIL PROTECTED] http://i2p.dnsalias.net/mailman/listinfo/i2p -- -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgp81rWI38QAG.pgp Description: PGP signature
Students Find Hole in Car Security Systems
took each chip they were trying to clone and fed it challenges, and then tried to duplicate the response by testing all 1,099,511,627,776 possible encryption keys. Once they had the right key, they could answer future challenges correctly. Mr. Sabetti of Texas Instruments argues that grabbing the code from a key would be very difficult, because the chips have a very short broadcast range. The greatest distance that his company's engineers have managed in the laboratory is 12 inches, and then only with large antennas that require a power source. Dr. Rubin acknowledged that his team had been able to read the keys just a few inches from a reader, but said many situations could put an attacker and a target in close proximity, including crowded elevators. The researchers used several thousand dollars of off-the-shelf computer equipment to crack the code, and had to fill a back seat of Mr. Green's S.U.V. with computers and other equipment to successfully imitate a key. But the cost of equipment could be brought down to several hundred dollars, Dr. Rubin said, and Adam Stubblefield, one of the Hopkins graduate students, said, "We think the entire attack could be done with a device the size of an iPod." The Texas Instruments chips are also used in millions of the Speedpass tags that drivers use to buy gasoline at ExxonMobil stations without pulling out a credit card, and the researchers have shown that they can buy gas with a cracked code. A spokeswoman for ExxonMobil, Prem Nair, said the company used additional antifraud measures, including restrictions that only allow two gas purchases per day. "We strongly believe that the Speedpass devices and the checks that we have in place are much more secure than those using credit cards with magnetic stripes," she said. The team discussed its research with Texas Instruments before making the paper public. Matthew Buckley, a spokesman for RSA Security, said his company, which offers security consulting services and is developing radio frequency ID tags that resist unauthorized eavesdropping, had offered to work with Texas Instruments free of charge to address the security issues. Dr. Wagner said that what graduate students could do, organized crime could also do. "The white hats don't have a monopoly on cryptographic expertise," he said. Dr. Rubin said that if criminals did eventually duplicate his students' work, people could block eavesdroppers by keeping the key or Speedpass token in a tinfoil sheath when not in use. But Mr. Sabetti, the Texas Instruments executive, said such precautions were unnecessary. "It's a solution to a problem that doesn't exist," he said. Dan Bedore, a spokesman for Ford, said the company had confidence in the technology. "No security device is foolproof," he said, but "it's a very, very effective deterrent" to drive-away theft. "Flatbed trucks are a bigger threat," he said, "and a lot lower tech." -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpj9SPAPil65.pgp Description: PGP signature
Re: Dell to Add Security Chip to PCs
On Wed, Feb 02, 2005 at 05:30:33PM +0100, Erwann ABALEA wrote: > Please stop relaying FUD. You have full control over your PC, even if this Please stop relaying pro-DRM pabulum. The only reason for Nagscab is restricting the user's rights to his own files. Of course there are other reasons for having crypto compartments in your machine, but the reason Dell/IBM is rolling them out is not that. > one is equiped with a TCPA chip. See the TCPA chip as a hardware security > module integrated into your PC. An API exists to use it, and one if the > functions of this API is 'take ownership', which has the effect of > erasing it and regenerating new internal keys. Really? How interesting. Please tell us more. -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpVsHbUYu02H.pgp Description: PGP signature
[0/many] Acrypto - asynchronous crypto layer for linux kernel 2.6 (fwd from [EMAIL PROTECTED])
e data for it: ->data_ready() method - it is called each time new session is added to device's queue. Array of struct crypto_capability and it's amount - struct crypto_capability describes each operation given device can handle, and has a maximum session queue length parameter. Note: this structure can [be extended to] include "rate" parameter to show absolute speed of given operation in some units, which therefore can be used by scheduler(load balancer) for proper device selection. Actually queue length can somehow reflects device's "speed". Note2: it can be calculated using ptime parameter of the session initializer - it is time given session was processed in crypto device. Acrypto has full userspace support through ioctl and direct process' vmas and pages access. It is done using ioctl() with 2 copyings from+to userspace data. Session processing contains of 3 major parts: 1. Session creation. CRYPTO_SESSION_ALLOC ioctl. User must provide special structure which has src, dst, key and iv data sizes and crypto initializer(crypto operation, mode, type and priority). 2. Data filling. User must call several CRYPTO_FILL_DATA ioctls. Each one requires data size and data type(structure crypto_user_data) and data itself. 3. Finish. User must call CRYPTO_SESSION_ADD ioctl with pointer to the are whre crypting result must be stored. The latter ioctl will sleep while session is being processed. Second userspace communication mechanism is based on direct access to the process' vmas and pages from acrypto, pointers are transferred using special kernel connector structure. Obviously it can not be used with the most hardware, but I like the idea itself. Currently supported HIFN 7955(small load testing), via padlock driver(not tested), driver for CE-InfoSys FastCrypt PCI card equipped with a SuperCrypt CE99C003B chip(not tested). ___ Subscription: http://lists.logix.cz/mailman/listinfo/cryptoapi List archive: http://lists.logix.cz/pipermail/cryptoapi -- -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpGUAKZUpDM3.pgp Description: PGP signature
Re: [0/many] Acrypto - asynchronous crypto layer for linux kernel 2.6 (fwd from [EMAIL PROTECTED])
From: Evgeniy Polyakov <[EMAIL PROTECTED]> Subject: Re: [0/many] Acrypto - asynchronous crypto layer for linux kernel 2.6 To: Joshua Jackson <[EMAIL PROTECTED]> Cc: Fruhwirth Clemens <[EMAIL PROTECTED]>, [EMAIL PROTECTED], linux-kernel@vger.kernel.org Date: Thu, 10 Mar 2005 13:27:30 +0300 Organization: MIPT Reply-To: [EMAIL PROTECTED] On Tue, 2005-03-08 at 08:24 -0500, Joshua Jackson wrote: > On Monday 07 March 2005 4:49 pm, Evgeniy Polyakov wrote: > > > > Unfortunately acrypto patch is more than 200kb, so neither mail list > > will accept it, so I've sent it in such form :) > > > > As per the FAQ, very large patches are often best submitted as a URL. In case > you don't have a place to host it, you are welcome to email me the complete > patch and I will post a URL link. Patch on the web has quite small interest for the majority of the people, but probably it is better than 50+ e-mails... The latest sources which can be compiled as external module are available at http://tservice.net.ru/~s0mbre/archive/acrypto/acrypto_latest.tar.gz > I am very interested in your async changes and possibly porting some of the > Free/OpenBSD HW crypto drivers over to it. That would be very good. You can find HIFN, VIA, FCRYPT drivers created for acrypto at http://tservice.net.ru/~s0mbre/archive/acrypto/drivers P.S. Above site is currently down, it will be turned on asap. -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski ___ Subscription: http://lists.logix.cz/mailman/listinfo/cryptoapi List archive: http://lists.logix.cz/pipermail/cryptoapi -- -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgp0ODUl2GY8E.pgp Description: PGP signature
ocf-linux-20050315 - Asynchronous Crypto support for linux (fwd from [EMAIL PROTECTED])
From: David McCullough <[EMAIL PROTECTED]> Subject: ocf-linux-20050315 - Asynchronous Crypto support for linux To: [EMAIL PROTECTED], linux-kernel@vger.kernel.org Cc: Andrew Morton <[EMAIL PROTECTED]>, James Morris <[EMAIL PROTECTED]>, Herbert Xu <[EMAIL PROTECTED]> Date: Tue, 15 Mar 2005 23:36:44 +1000 Hi all, The latest release of ocf-linux (20050315) is available for download from the project page: http://ocf-linux.sourceforge.net/ This release includes the following changes: * Hifn PLL bug fixes * Makefile fixes for 2.6 builds * 2.6.11 and 2.4.29 patches * cleanups for x86 builds OCF-Linux is a Linux port of the OpenBSD/FreeBSD Cryptographic Framework (OCF). This port aims to bring full asynchronous HW/SW crypto acceleration to the Linux kernel and applications running under Linux. Results have shown improvements of up to 7 times that of software crypto for bulk crypto throughput using OpenSSL. At this point in time OCF-Linux provides acceleration for OpenSSL, OpenSSH (scp, ssh, ...) and also supports the BSD crypto testing applications. It can accelerate DES, 3DES, AES, MD5, SHA, and Public Key operations with plans to include Random Number generators and more. This project is being actively developed as a high performance crypto solution for embedded devices but also applies equally well to any linux based server or desktop. Cheers, Davidm -- David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org ___ Subscription: http://lists.logix.cz/mailman/listinfo/cryptoapi List archive: http://lists.logix.cz/pipermail/cryptoapi -- -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpeb3Res97Sm.pgp Description: PGP signature
DTV Content Protection (fwd from cripto@ecn.org)
ecording of protected data via Firewire, USB2, or IP. However its reliance on the much-maligned principle of security through obscurity (keeping the details secret) may in practice give it a greater degree of protection. -- -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpOymYbwYq6f.pgp Description: PGP signature
[EMAIL PROTECTED]: [IP] Intel quietly embeds DRM in it's 945 chips firmware]
- Forwarded message from David Farber <[EMAIL PROTECTED]> - From: David Farber <[EMAIL PROTECTED]> Date: Tue, 31 May 2005 08:17:59 -0400 To: Ip ip Subject: [IP] Intel quietly embeds DRM in it's 945 chips firmware X-Mailer: Apple Mail (2.730) Reply-To: [EMAIL PROTECTED] Begin forwarded message: From: Date: May 31, 2005 1:15:49 AM EDT To: [EMAIL PROTECTED] Subject: Re: [IP] Intel quietly embeds DRM in it's 945 chips firmware Dave Farber: Please remove my name and identity from this mailing, due to fear of reprisal. (I still work in the entetainment business from time to time.) I do not know all about Intel's DRM, but I do know more, perhaps, than I should. What I do know is that Intel has been working very closely with the entertainment industry on a DRM that, I've been told, seeks to satisfy EVERYONE'S wishes. Of course, such a system would mean, by definition, that it will satisfy either no one, or only the studios. But I do know that the Intel "dream" DRM system would allow content to be moved from one platform to another on a network, presumably through a check-in/check-out procedure, to make sure only a limited number of (legitimate) copies would be made and in service at any one time. Intel's system also acknowledges, for example, that a high- resolution (e.g. high definition video) copy of a film could be used to create low-res (like Quicktime, Real or Windows Media) versions that could be used in portable video players. Users might even be able to "loan" time-limited copies or be allowed to make a small number of copies, like Apple's Fair Play DRM permits. You can check out Intel's ideas for such a system, and the participation of an entertainment and consumer electronics industry panel called the Digital Home Working Group, on which Intel sits, which has been addressing such a system in this article from February, 2004: http://www.infoworld.com/article/04/02/24/HNbarrettdrm_1.html (Note: The Japanese system for hard disk and DVD recorders that Barrett alludes to is called CPRM. It is neither new nor flexible, and there has already been some consumer backlash against it in Japan, where it is used for the transmission of digital TV b'casts -- sort of their "broadcast flag.") At the root of the problem, of course, is the personal computer that's used as a media player platform. This is also, not coincidentally, Intel's cash cow. Such a DRM system, with the PC playing a pivotal role, would also mean that IBM or other chip vendors would not be allowed to play without building in the same chip-level protection. Without these important security pieces, Apple, for example, would be cut out of the picture for playing content protected by the Intel-endorsed DRM, as would (most likely) Linux-based devices. This is a GRAND PLAN that relies on it being either almost completely transparent to consumers (like Apple's Fair Play) or simple to understand. Unfortunately, almost no DRM is easily understood by consumers. Even most of the customer's for Apple's iTunes Music Store only become familiar with the terms under which they've purchased their music when they bump up against the limitations that have been set. The real nightmare scenario, in my opinion, is a world in which several such DRMs co-exist, creating a chaotic environment in which you never know whether content will play on one plaform but not another. This is a potentially really sticky mess. - You are subscribed as [EMAIL PROTECTED] To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: "Retailers Experiment With Biometric Payment" article
On Thu, Jun 09, 2005 at 12:02:20PM -0400, Adam Shostack wrote: > Has anyone ever studied the reversability of these algorithms? It > seems to me that you could make some plausible guesses and generate > fingerprints from certain representations. I don't know how likely > those guesses are to be right. The fingerprint hash (fingerprint's fingerprint) has to be resistant to rotation/translation, area size and subpattern presence, and tolerate some skin lesion noise, so it's the very opposite of a cryptographic hash. Probably quite easy to reverse. -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: Is there any future for smartcards?
On Wed, Sep 07, 2005 at 06:08:25PM -0400, Pat Farrell wrote: > Something tells me that soon is not gonna happen in what I would > call soon. Smartcards (the smart part) were moderately interesting > when there was no networking. We've been at ubiquitous networking > for many years. We also have ubiquitous networking of systems which are vulnerable and frequently compromised. Smartcard + reader is a hardened cryptographic compartment where you can still trust what you see on the reader display, and that nobody can sniff what is entered on the keypad. Such a system can be safely connected to an insecure, networked machine. > Is there a real problem that they uniquely solve, sufficient > to drive the building of the needed infrastructure? > I don't see it, and I'd love to be made smarter. -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: Is there any future for smartcards?
On Sun, Sep 11, 2005 at 10:53:34PM +1200, Peter Gutmann wrote: > The problem with this is that in 99.99% of cases the insecure networked > machine *is* the reader, rendering the smart card pretty much pointless. I've Pat Farrel spoke about the infrastructure required for smartcards to have at all a point. Inexpensive USB readers with integrated keypad (and LCD display) exist, and are a basic component of such smartcard infrastructure. Unless it's pure snakeoil, by design. > only ever seen a handful of card readers that have keypads and displays, and > none that have succeeded commercially. Everyone just gets the cheap reader- > only devices. USB smarcard readers with displays are not expensive, especially if purchased in quantities. A financial institution would probably recover the costs quite rapidly, if it gave away smartcards and such readers for free to its customers, given the amount of fraud. It is symptomatic that this is not happening, and that e.g. HBCI support hereabouts is very thin. HBCI+smartcard, especially on a non-Redmond system, is nearly impossible to set up. Zero support. (Support in fact discourages use of smartcard). Default for local online banking is PIN/TAN (TANs distributed on dead tree). -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: Is there any future for smartcards?
On Sun, Sep 11, 2005 at 06:49:58PM -0400, Scott Guthery wrote: > 1) GSM/3G handsets are networked card readers that are pretty > successful. They are I'd wager about as secure as an ATM or a POS, > particularly with respect to social attacks. The smartphones not secure at all, because anything you enter on the keypad and see on the display can be compromised, so the tamper-proof cryptographic goodness locked inside the SIM smartcard will cheerfully approve whatever the code running on the smartphone will tell it to approve, regardless of what is being displayed to the user. Virtually all new phones sold are smartphones, and for every platform there are documented vulnerabilities, exploits, and malware already in the wild. Increased use of mobile phones as means of payment are a strong motivation for malware writers. Most of smartphone users are security-naive teenagers. This indicates that we'll be getting all problems with desktop machines, and more, shortly. > 2) ISO is currently writing a standard for a secure home card reader. > The starting point is FINREAD. See JTC1/SC17/SG4/TF10. I own a secure home card reader (which happens on run on Windows, Linux and OS X, with open source drivers -- my model has a keyboard but no display, but other models from the same manufacturer do). Standars are good. I'm all for standars, as long as they describe what eventually will be a real world product. Unless financial institutions will be required by law to issue secure smartcards and smartcard readers, or suffer extreme losses through fraud they won't introduce these secure readers and smartcards. -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: Is there any future for smartcards?
On Mon, Sep 12, 2005 at 09:52:27AM -0700, James A. Donald wrote: > Typical worm installation goes like this: > > : : Receive message via bluetooth from unnamed > : : device? Y/N > : : > : : Installation Security warning: Unable to > : : verify supplier. Continue anyway? Y/N It's just a networked computer that happens to look like a mobile phone. Not particularly security-oriented. It also doesn't matter what current malware does on the current platform. FWIW, it's still in primitive shenanigan stage. It's a question what future malware on future mobile platforms will do. It's a machine for young social primates. Not suitable for a payment system, unless equipped with dedicated, hardened cryptographic compartment with dedicated display and PIN/biometrics. http://www.f-secure.com/weblog/archives/archive-052005.html Yesterday we received information on Commwarrior.B sightings on two new countries: Greece and South Africa. So it seems that the rate in which Commwarrior is spotted is quite a lot faster than with Cabir. But then again, high discovery rate might be result of increased public awareness. Also as Commwarrior is in the wild here in Finland, we have had an opportunity to follow how the worm spreads and interviewed people who have been infected with it. And it seems that we have found at least partial answer to the question why people install Symbian worms on their phones. The most common reason why people have installed Commwarrior from MMS message is the trust that they have on the sender. People are wary of messages that they receive from unknown sources, but quite willing to install whatever has been sent from a friends mobile. This is a phenomenon that we have also seen with E-Mail worms, people just are unwilling to mistrust something coming from a friend. Current count of countries with Commwarrior sightings: 1.Ireland 2.India 3.Oman 4.Italy 5.Philippines 6.Finland 7.Greece 8.South Africa > Seems to me that the phone designers have done a better > job with virus, worm, and malware resistance than > Microsoft or Linux. Teenagers are pretty sophisticated. Are we talking even about the same species? About the same teenagers which already own malware-infested PCs, and swap whatever ringtones, logos and games en vogue with their FOAFs? -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: European country forbids its citizens from smiling for passport photos
On Sat, Sep 17, 2005 at 10:52:48AM -0400, William Allen Simpson wrote: > Do you really need to click on this link to know which one it is? U.K.? http://www.iht.com/articles/2005/09/12/news/travel13.php All of them? US and Canadia as well? > http://cbs5.com/watercooler/watercooler_story_258152613.html > > I guess we should give neutral facial expressions for the photo, then > smile (or frown) while in the airport We should violet-wand the smartcard pads. Or sever the antenna for the RFID. Or just use the dead tree one, and not reapply when it expires. > Sounds like the technology (still) isn't ready for prime time. Not ready for 1984? One sure would hope so. -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: [IP] more on ARMSTRONG LECTURE on Quantum Crypto and Optical Networks (Forwarded)]]
- Forwarded message from David Farber <[EMAIL PROTECTED]> - From: David Farber <[EMAIL PROTECTED]> Date: Mon, 19 Sep 2005 20:30:36 -0400 To: Ip Ip Subject: [IP] more on ARMSTRONG LECTURE on Quantum Crypto and Optical Networks (Forwarded)] X-Mailer: Apple Mail (2.734) Reply-To: [EMAIL PROTECTED] Begin forwarded message: From: Rod Van Meter <[EMAIL PROTECTED]> Date: September 19, 2005 7:25:19 PM EDT To: Joe Touch <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], David Wagner <[EMAIL PROTECTED]> Subject: Re: [Fwd: Re: [IP] ARMSTRONG LECTURE on Quantum Crypto and Optical Networks (Forwarded)] Reply-To: [EMAIL PROTECTED] [Dave, for IP, if you wish...] I generally agree with Dave Wagner's response, but a few thoughts... The physicists are indeed working on quantum repeaters, capable of doing QKD over long distances. The trouble is, you have to trust every one of the repeaters. I wouldn't phrase the "fiber security" issue quite the same way. As others have said, what you need is access to an authenticated channel, then you're set (but that's a non-trivial problem!). It's important to note that a) QKD does NOT solve what Shor's factoring algorithm broke, and b) key exchange/distribution is not the biggest security problem we have on the net (it might not even make the top ten). The one possibly interesting use of QKD is for the super-paranoid: those who believe their traffic is being snooped today, and don't want it decrypted fifty years from now when theoretical and technological advances render all classical cryptography breakable (!?!). But in order for that to work, you have to use the QKD-generated random bit string as a one-time pad, not just a seed or key for classical encryption. That means you need very high QKD bit-generation rates, and most are still in the kilobits/second. Some experiments have been done in the low megabits/sec., but that's pre-filtering, I believe, which costs you at least one order of magnitude in performance. If you do it right, then, authentication that is good enough TODAY, plus QKD to generate a random one-time pad, can make your data secure FOREVER (modulo breakins/breakdowns at the endpoints). Even if your authentication is broken later, since it's not used in the actual data exchange, the attacker gains no data. This is covered in Paterson et al.'s paper. I arrived at the party a little late to get in on the recent thread at Dave Bacon's Quantum Pontiff blog, but I did throw in my two cents anyway: http://dabacon.org/pontiff/?p=1049#comments Dave's blog is an excellent source for current news and gossip, and is read (and commented on) by many of the best names in the biz. btw, Steve, not sure if you're aware of it or not, but Al Aho's student Krysta Svore is doing quantum stuff for her thesis. She just spent a year in Cambridge working with Ike Chuang, but is back at Columbia, I understand. She's pretty sharp. --Rod - You are subscribed as [EMAIL PROTECTED] To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Wikipedia proposal]
- Forwarded message from Jason Holt <[EMAIL PROTECTED]> -
From: Jason Holt <[EMAIL PROTECTED]>
Date: Fri, 7 Oct 2005 07:57:11 + (UTC)
To: [EMAIL PROTECTED]
Subject: Wikipedia proposal
Reply-To: [EMAIL PROTECTED]
I just posted this to wikitech-l:
There has been a lot of discussion lately on the or-talk list about
how to let tor and other anonymizing proxy users edit wikipedia without
allowing vandals free rein. Several straightforward approaches have been
proposed, such as holding edits in escrow pending approval by a trusted
user, and requiring anonymizing network users to login before posting.
The latter idea in particular could easily be abused, since abusers can
create a new account for each edit.
Roger Dingledine, tor's author, suggested creating a pseudonym service
using a cryptographic construction called blind signatures:
http://www.rsasecurity.com/rsalabs/node.asp?id=2339
Basically, Alice can generate a token, mathematically blind it
(obscuring its value), have it signed, then unblind the signature.
Anyone can verify that the signature on the token is valid, but nobody,
including the signer, can link the blinded value Alice had signed with
her unblinded token.
I implemented such a scheme which works as follows:
* Alice creates and blinds a token, then submits it to a token server
for signing. Optionally, the token server may have a list of IPs banned
from wikipedia, and refuse to sign Alice's token if her IP is on the list.
* The token server signs the blinded token, then records what IP address
Alice used so that she can't obtain multiple tokens per IP address.
Later, this will allow us to block Alice's IP address if she misbehaves,
just as Wikipedia admins currently do, except that now it'll work even
when she connects via tor. Token rationing could also be done based
on other (more or less) scarce resources, including email addresses,
captchas, CPU-intensive tasks or even money, just as I'm sure has been
proposed for the vanilla wikipedia. The advantage of blind signatures is
that tokens can be recorded and blocked without revealing the potentially
sensitive underlying resource (such as a personal email address or
IP address).
* Alice can now turn on tor and present her token to wp, without revealing
her actual IP address. This token takes the place of the IP address
record currently stored along with article edits, and can be blacklisted
just the same way that IPs are banned.
* However, I implemented an intermediary step which has several
advantages. Instead of presenting her token to wp, Alice generates an
essentially empty client certificate and presents it via the tor network
to a certificate authority (CA) for signing, along with the signed token.
The CA records that the token has been "spent" (preventing her from
receiving multiple certs per token), then signs her cert just as Verisign
would sign a server SSL certificate. Since she connects via tor, the CA
doesn't learn her real IP address.
* Alice installs the client certificate in her browser, then connects
to a special wp server running an SSL server that demands valid client
certificates from our CA. That configuration takes only 4 lines in my
apache-ssl server's httpd.conf. Apache automatically sets environment
variables which identify the client certificate, and which can be used
in place of the REMOTE_ADDR variable currently used to record users'
incoming IP addresses when marking page edits. Blocking a client cert
would then be just as easy as blocking an IP address.
All of Alice's edits will be marked with that identifier unless she
obtains a new IP address (or other scarce resource) and repeats the
process to obtain another certificate. Later, features can optionally
be added which will allow her to have separate identifiers for each edit
(protecting her in case, say, her repressive government confiscates her
computer in order to find out if she wrote a particular article they
disagree with).
I have already released code to implement this system, with the exception
of the wp-specific code. I sent the proposal to both the or-talk lists
and the cryptography list at metzdowd.com on Monday. Next I'd like your
comments, before I dive into the mediawiki code (or find someone willing
to help with this part). Once the feature is complete, we can set up a
live test wiki for people to bang on, before we consider implementation
on the live wp servers.
-J
- End forwarded message -
--
Eugen* Leitl http://leitl.org";>leitl
__
ICBM: 48.07100, 11.36820http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
signature.asc
Description: Digital signature
Re: Cisco VPN password recovery program
On Wed, Oct 19, 2005 at 09:45:38AM -0500, Alaric Dailey wrote: > Cisco seems to be doing these kinds of boneheaded things for quite sometime. Does Juniper have a better security story? -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: [p2p-hackers] P2P Authentication]
- Forwarded message from Kerry Bonin <[EMAIL PROTECTED]> - From: Kerry Bonin <[EMAIL PROTECTED]> Date: Thu, 27 Oct 2005 06:52:57 -0700 To: [EMAIL PROTECTED], "Peer-to-peer development." <[EMAIL PROTECTED]> Subject: Re: [p2p-hackers] P2P Authentication User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) Reply-To: "Peer-to-peer development." <[EMAIL PROTECTED]> There are only two good ways to provide man-in-the-middle resistant authentication with key repudiation in a distributed system - using a completely trusted out of band channel to manage everything, or use a PKI. I've used PKI for >100k node systems, it works great if you keep it simple and integrate your CRL mechanism - in a distributed system the pieces are all already there! I think some people are put off by the size and complexity of the libraries involved, which doesn't have to be the case - I've got a complete RSA/DSA X.509 compliant cert based PKI (leveraging LibTomCrypt for crypto primitives) in about 2k lines of C++, <30k object code, works great (I'll open that source as LGPL when I deploy next year...) The only hard part about integrating into a p2p network is securing the CA's, and that's more of a network security problem than a p2p problem... Kerry [EMAIL PROTECTED] wrote: >>>And if they do, then why reinvent the wheel? Traditional public key >>>signing works well for these cases. >>> >>> >... > > >> Traditional public key signing doesn't work well if you want to >>eliminate the central authority / trusted third party. If you like >>keeping those around, then yes, absolutely, traditional PKI works >>swimmingly. >> >> > >Where is the evidence of this bit about "traditional PKI working"? As far >as >I've observed, traditional PKI works barely for small, highly centralized, >hierarchical organizations and not at all for anything else. Am I missing >some >case studies of PKI actually working as intended? > >Regards, > >Zooko >___ >p2p-hackers mailing list >[EMAIL PROTECTED] >http://zgp.org/mailman/listinfo/p2p-hackers >___ >Here is a web page listing P2P Conferences: >http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > > > ___ p2p-hackers mailing list [EMAIL PROTECTED] http://zgp.org/mailman/listinfo/p2p-hackers ___ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: [Clips] Banks Seek Better Online-Security Tools
On Sun, Dec 04, 2005 at 05:51:11PM -0500, [EMAIL PROTECTED] wrote: > | To start the ball rolling, I have not and won't. > Until a couple of months ago, I avoided doing anything of this sort at all. > Simple reasoning: If I know I never do any financial stuff on-line, I can > safely delete any message from a bank or other financial institution. I've been using online banking for many years, both US and Germany. 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). It is of course not immune to phishing (PIN/TAN harvesting), which has become quite rampant recently. I'm about to setup HBCI with my business account (both GnuCash and openhbci/aqbanking from the command line), which can in principle cooperate with a smartcard. It is a major pain to set up, however, especially on an unsupported platform. 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. -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: automatic toll collection, was Japan Puts Its Money on E-Cash
On Thu, Dec 15, 2005 at 04:31:36AM -, John Levine wrote: > An article in Wikipedia says that congestion tolls in London (UK) are > also collected automatically by taking pictures of license plates. The German TollCollect system (used on the national highway system) reads license plates of every vehicle (currently, only trucks are charged) by OCR. The police is purportely very interested to obtain realtime access to the logs. Don't we all feel much safer, already? -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: [IP] more on AP Story Justice Dept. Probing Domestic Spyin]
- Forwarded message from coderman <[EMAIL PROTECTED]> - From: coderman <[EMAIL PROTECTED]> Date: Sat, 31 Dec 2005 18:32:33 -0800 To: Tyler Durden <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [EMAIL PROTECTED]: [IP] more on AP Story Justice Dept. Probing Domestic Spyin On 12/31/05, Tyler Durden <[EMAIL PROTECTED]> wrote: > ... > Of course, NSA will likely grab&store the hidden piece as well i would count on it, as it's a good bet the answer is yes rather than no. > but I submit > one might be able to make this a fairly intractable problem, particularly if > information about -where- the appropriate piece is stored is itself > destroyed. (ie, they may have the piece, but they dont know which message it > belongs). i'm working on a one time pad based IPsec key daemon with a similar purpose to what you describe. i'll be posting here for feedback when it's ready but the basic premise is that it provides strong ephemeral IPsec keying using one time pads previously exchanged between peers. as long as the pads are generated and secured properly[1] you don't need to care if $TLA has kept your IPsec traffic archives in their acres of computing machinery. likewise, if large qubit quantum computers suddenly become feasible or multi ring GCF gets really fast, you don't need to worry about past key exchanges (also archived) being compromised, as with pub key based ISAKMP implementations. last, such a mode needs no open ports[2], so the attack surface for remote exploitation is limited to the IP level - only authenticated traffic is passed up the stack, everything else is dropped. as long as your OTP's are truly random and never compromised, the key exchange will be secure and the only way to attack your traffic remotely will be brute force of AES256. [1]. securing pads is really the crux of the issue here. i'm using modified linux distributions for key generation (a host with no networking capability - kernel omits all network functionality) and IPsec termination (boot from CD/DVD, require USB fob / hardware token + passphrase for auth to access pads stored in encrypted volume). [2]. this is true with an explanation: for the initial session ICMP payloads are sent in the clear (not IPsec) to perform the encrypted key exchange using OTP's. once IPsec is initialized, ICMP is also directed through IPsec via the SPD and future rekeying uses OTP's on top of the existing IPsec SA. i'll have more details later but in short all traffic is authenticated or dropped, most of it authenticated via IPsec, and the only exception being key exchange via ICMP which is authenticated via OTP only until the first SA is established. the advantage of using OTP's in addition to security is simplicity: all buffers are fixed size, key material is small (per instance) and the operations fast (no montgomery multiplication on very large numbers). even at a 1Hz rekey interval you could fit a years worth of key exchange OTP in 100MBytes of storage. the disadvantage is you probably need hardware entropy generation to produce the pads in a reasonable time. i'm using the VIA C5XL and C5P processors for testing / runtime and these can produce more than enough entropy for large pads without sucking /dev/random dry. last but not least, the implicit out of band pad exchange with trusted peers is reasonable for private group networking and other smaller networks but would be very difficult to scale to a large organization. this is a feature in my eyes, as private group networks are what this is intended for and meatspace pad exchange a desired requirement to ensure trust is properly placed. - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Tor-stored Pads]
- Forwarded message from Tyler Durden <[EMAIL PROTECTED]> - From: Tyler Durden <[EMAIL PROTECTED]> Date: Sun, 01 Jan 2006 21:41:35 -0500 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Tor-stored Pads Alif the Terrible wrote... >(3) Since all off the pieces have been stored - including both the >encrypted messagetexts and the decryptors, what is to prevent a >time-faking attack against this message? After all, if you have all the >parts, you can just "reinstantiate" the network as it was was the messages >were originally sent. Yes, agreed, but I think this a MUCH bigger pain in the ass. To wit: If they grab and deencrypt the "message" (ie the piece sent to the receiver) prior to the expiration time, then they will have the message and be able to read it. This is an improvement in that they have to do it prior to the expiration time of the hidden piece. They can not grab and store this piece alone because the other piece will not be there later. If they do not deencrypt the message in time, then they have to grab a core dump of the entire network (as well as the transmitted message), because they do not know where the piece is located. Seems to me that's a much harder thing to do then merely grabbing a sole message and de-encrypting it at their leisure. Seems to me too that a Tor network that was sufficiently dynamic could require network core dumps that could actually tax even NSA facilities, given large Tor networks of the future. It should also be pointed out that if the encryption on the "message" piece is done extremely carefully, one can afford to be lax on the Tor piece, and yet have a very difficult problem to crack (particularly if wrong guesses set off boobytraps that kill the hidden message piece). Again, it can be countered that an attack might merely require N instantiations of the network, but now we are talking some very significant resources. We've multiplied the originall cracking problem by N. Perhaps. -TD PS: I believe this is very close to having a one-time stored pad, but the difference with traditional Pads is that this one is tored in an anonymous location.(See Coderman's post.) - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: [IP] more on AP Story Justice Dept. Probing Domestic Spyin]
- Forwarded message from coderman <[EMAIL PROTECTED]> - From: coderman <[EMAIL PROTECTED]> Date: Sun, 1 Jan 2006 18:53:13 -0800 To: "J.A. Terranson" <[EMAIL PROTECTED]> Cc: Tyler Durden <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [EMAIL PROTECTED]: [IP] more on AP Story Justice Dept. Probing Domestic Spyin On 1/1/06, J.A. Terranson <[EMAIL PROTECTED]> wrote: > (1) We are describing encryptedmessage sent over the public internet - > granted, it's in "pieces", yet it's still sent into the public cloud; yeah, follow tcp stream in ethereal is a good example of how trivial it is to recreate a session of communication given an archive of its component datagrams. > (2) These various pieces are all "record" communications as far as > NSA/Echelon is concerned, and therefore we should expect that they will > draw significant attention - and end up in permanent archives; right. hence my fetish for one time pads for key exchange and previous comment about quantum computers / fast GNFS / etc. they are up to 8 qubits, only a few thousand more to go. ;) > (3) Since all off the pieces have been stored - including both the > encrypted messagetexts and the decryptors, what is to prevent a > time-faking attack against this message? After all, if you have all the > parts, you can just "reinstantiate" the network as it was was the messages > were originally sent. this is particular to the method TD mentioned i think... i am assuming the following: - the operating system is installed on a loop-aes volume so that integrity of the kernel, libraries and utilities is protected via passphrase. - the one time pads are stored encrypted in a similar manner so that access to them requires external keys (like the gpg encrypted keys used for loop-aes volumes) - the passphrase used to authenticate a user for access to the pads is coupled with external storage (usb) of the keys used to access the pads. to recover the plaintext communication from the encrypted datagrams the attacker would need to obtain the encrypted pad, the keys on external storage (usb), and the passphrase to access the keys. > (4) For any form of time-destruction messaging to really work, the keying > information would have to be tied to a physical that cannot be > reclaimed, and which decays at a fixed, known, and closely approximatable > rate (a radiodecay probably doesn't meet this criteria); > > Every time-sensitive auto-destructing system Ive seen discussed here fails > these weaknesses. this doesn't provide time destruction so i assume this is in reference to Tyler's description. you could couple the user authentication with a physically hardened token of some sort for access to the pads but even this would require manual destruction. do they make physically hardened authentication tokens with timed self destruction built in? - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Tor security advisory: hidden services can be located quickly]
- Forwarded message from Roger Dingledine <[EMAIL PROTECTED]> - From: Roger Dingledine <[EMAIL PROTECTED]> Date: Thu, 12 Jan 2006 18:03:40 -0500 To: [EMAIL PROTECTED] Subject: Tor security advisory: hidden services can be located quickly User-Agent: Mutt/1.5.9i Reply-To: [EMAIL PROTECTED] Versions affected: all stable versions, and all experimental versions up through 0.1.1.10-alpha. Impact: If you offer a Tor hidden service, an adversary who can run a fast Tor server and who knows some basic statistics can find the location of your hidden service in a matter of minutes to hours. Solution: You have three options: 1) Upgrade to Tor 0.1.1.12-alpha from the Tor download page [1]. You're all set, though be aware that this is an alpha release so there may be other bugs. You may also want to look through the release notes [2]. 2) Turn off your hidden service until the final 0.1.1.x release is out. It may be several months. 3) Stick with Tor 0.1.0.16 and manually configure a half dozen EntryNodes. See the FAQ entry [3] for some hints about how to do this. The details: Tor researchers Lasse ?verlier and Paul Syverson have confirmed that a previously theoretical attack on Tor works very well in practice. Specifically, they found that a malicious Tor server can locate a hidden service more quickly than was previously believed. The attack is simple: access the hidden service repeatedly, and keep track of who builds circuits through you shortly after each access. Because you can induce your victim to build a new circuit on demand, eventually one of his circuits will start at your node. To slow this attack, our latest experimental release implements a new feature called "guard nodes": it automatically chooses a handful of entry nodes and sticks with them for all circuits. This idea is adapted from the "helper node" concept published by Wright et al [4], but with improved reliability: rather than picking a set of entry nodes and refusing to access the Tor network if they all become unreachable, Tor's design dynamically picks new guards as needed, yet switches back to the old ones when they become reachable again. Therefore Tor users still have the same level of robustness as before, but the chance of a successful attack by a limited adversary is greatly reduced. More details will be presented on January 14 at Shmoocon [5] and January 26 at Black Hat Federal [6]. --Roger [1] http://tor.eff.org/download [2] http://archives.seul.org/or/talk/Jan-2006/msg00024.html http://archives.seul.org/or/talk/Jan-2006/msg00026.html [3] http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit [4] http://freehaven.net/anonbib/#wright03 [5] http://www.shmoocon.org/speakers.html#overlier [6] http://www.blackhat.com/html/bh-federal-06/bh-fed-06-speakers.html#Syverson ----- End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: FIPS 140-2 Validation Revoked]
- Forwarded message from Richard Salz <[EMAIL PROTECTED]> - From: Richard Salz <[EMAIL PROTECTED]> Date: Wed, 19 Jul 2006 01:09:12 -0400 To: openssl-dev@openssl.org Cc: [EMAIL PROTECTED] Subject: Re: FIPS 140-2 Validation Revoked X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 Reply-To: openssl-dev@openssl.org I wish to make it very clear that in this message I am speaking solely as an individual, and do not represent my employer or its views in any way at all. > We don't know the full story behind this yet, and perhaps never will. As > John Weathersby noted in the article, "This is not about technology". This is baloney. The "boundary" around the formerly-validated code was completely wrong -- a simple analysis showed that code within the "FIPS container" called code outside the container. A sample program showed how this led to trivial breaks in security. I have seen a document that had this analysis, and included a sample program that printed all private keys to the screen and when asked for random numbers always returned the same value. I know this document was given to the module authors and the validation lab. The authors ignored this and also convinced the validation lab to ignore it. The lab (I'm really glad they're not a subsidiary of my employer any more) trusted the vendor; had they performed the most basic due diligence -- compile the program! -- they would have seen that the code should not have passed. Hell, 'nm fipscanister.o | fgrep U' would have shown it! There were other problems as well. For example, the DES/3DES self-test did not test encryption. Even worse, the implementation tested isn't the one used by the public API's. (OpenSSL includes multiple DES/3DES implementations.) Open source is not magic pixie dust that allows you to ignore basic reality. The certified code had serious flaws that were known to the parties involved in certification, yet they went ahead anyway. CMVP did the right thing. Can you imagine the damage that could have been done if either critical systems were built using that code, or if a true enemy of the open source movement published the sample code after it had widespread use? It greatly saddens me to say this, but unless there are significant changes in the process and/or participants, I will continue to advise anyone who wants to rely on a FIPS-ccertified OpenSSL that it is not safe to do so. /r$ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: FIPS 140-2 Validation Revoked]
other problems as well. For example, the DES/3DES self-test did > not test encryption. Even worse, the implementation tested isn't the one > used by the public Ape's. (OpenSSL includes multiple DES/3DES > implementations.) Tim misread the DES self-test implementation look at the fourth argument to the DES_ebb_encrypt() function which is used for both encryption and decryption. FIPS 140-2 does not require that the APIs of the validated module be used directly by all applications. All these allegations were covered in detailed correspondence between myself, the OpenSSL team, and the CMVP. > Open source is not magic pixie dust that allows you to ignore basic > reality. The certified code had serious flaws that were known to the > parties involved in certification, yet they went ahead anyway. CMVP did > the right thing. Can you imagine the damage that could have been done if > either critical systems were built using that code, or if a true enemy of > the open source movement published the sample code after it had widespread > use? > > It greatly saddens me to say this, but unless there are significant > changes in the process and/or participants, I will continue to advise > anyone who wants to rely on a FIPS-certified OpenSSL that it is not safe > to do so. Well, you're waxing poetic here and I think you're being a little harsh. The CMVP is doing the right thing, performing careful analysis and allowing us to correct the one flaw they identified from the many allegations. This validation effort, some four years in the running, has been a learning experience for all of the participants, CMVP included. I give them credit for their commitment and effort in breaking new ground, when a less dedicated bureaucracy would have found excuses to punt. The understanding of the complexities in applying FIPS 140-2 to source based portable code, and the corresponding guidance from the CMVP, has changed and matured considerably since we started. BTW the correct term is validation, not certification. Also, OpenSSL was not validated, the validated product is the OpenSSL FIPS Object Module, a separate software component designed for use with OpenSSL. Both common slips; it took me a year to break that habit :-) -Steve M. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
C7, Jetway, performance
Anyone here running a recent Jetway or similiar product with a C7? Care to share your benchmarks, as to IPsec & Co throughput? I'm thinking about picking up a J7F2WE1G5D, or similiar, and a triple-GBit Ethernet (Realtek RTL81108, or similiar), and am interested in how that thing performs at 100..1000 MBit/s speed, with IPsec or OpenVPN (FreeBSD 6.2 or pfsense data would be great). -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
ad hoc IPsec or similiar
There's a rather ominous EU legislation to be passed soon, which requires any party acting as a provider (you run anonymous proxy, or mix cascade, you are a provider) to log all connection info (when, who, with whom). What's the status of ad hoc IPsec or any other TCP/IP-tunneling VPN for random endpoints? -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
On Thu, Jun 21, 2007 at 06:00:48PM +0100, Richard Clayton wrote: > (a) the EU legislation was actually passed well over a year ago > > http://europa.eu.int/eur-lex/lex/LexUriServ/site/en/oj/2006/l_105/l_10520060413en00540063.pdf It is not national law yet. I'm only concerned about when I have to deal with it personally. > and applies to "service providers" so "random endpoints" will be The pending legislation is stated broadly enough to include anyone with a proxy or a mix cascade, company or private body, for-profit or non-profit. It threatens up to half a megaeuro penalty and up to two years in jail. > unlikely to be caught by its requirements. Any random endpoints will be passing through the ISP, and hence subject to retention. An ad hoc IPsec or VPN tunnel setup will make data analysis more difficult, especially if there's traffic background (P2P, etc). So what's the state in ad hoc IPsec/VPN setup for any end points? > (b) what the Directive exactly means is anyone's guess (the wording > shows a deep failure to understand how the Internet works), and it is > entirely clear that it will in practice mean different things in > different EU countries. I've been told this legislation will be used by several persons within BKA etc. to harass Tor operators. This is not a guess; I'm not sure how reliable that source is, however. > In the UK it's likely to only apply to large public ISPs -- and > retention will be restricted to records of who used which IP address, > email server records, and possibly web cache logs (possibly not, since > web caches may not be economic if the logs have to be retained)... The financial burden is completely on the side of the providers. > ... the wikipedia page on the topic > > http://en.wikipedia.org/wiki/Data_retention > > ... has information for other countries that looks fairly plausible from > what I know about their plans. Unfortunately, I know more about the plans than I ever wished. > Note that the Directive also applies to phone calls ... and the It also applies to mobile phone location in the cell. > transposition of that into national laws is supposed to be completed by > October 2007; most countries have until March 2009 for Internet logs Apparently, Germany will implement Internet connection retention by end of the year/beginning of 2008 latest. -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Quantum Cryptography
On Thu, Jun 21, 2007 at 01:20:35PM -0400, Victor Duchovni wrote:
> Quantum Cryptography or Quantum Computing (i.e. cryptanysis)?
>
> - Quantum Cryptography is "fiction" (strictly claims that it solves
> an applied problem are fiction, indisputably interesting Physics).
>
> - Quantum Computing is "science fiction". Some science fiction
> eventually becomes reality.
A nice blog to follow here is Shtetl-Optimized:
http://www.scottaaronson.com/blog/
--
Eugen* Leitl http://leitl.org";>leitl http://leitl.org
__
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [Cryptography] Gilmore response to NSA mathematician's "make rules for NSA" appeal
On Tue, Sep 24, 2013 at 12:30:40PM -0400, Kelly John Rose wrote: > If Google, or other similar businesses want to convince people to store > data in the cloud, they need to set up methods where the data is > encrypted or secured before it is even provided to them using keys which That would completely undermine their "free" (selling their customers as a service) model. For privacy-minded, the centralist cloud model seems to be irreversibly dead. P2P clouds are currently too unreliable unfortunately. What we need is end to end reachability (IPv6) and sufficient upstream for residential connections, all running on low-power no-movable-part systems (embedded/SoCs). Most of that is still in our future. > are not related or signed by a central authority key. This way, even if > Google's entire system was proven to be insecure and riddled with leaks, > the data would still be secure. You cannot share data that you can never > have access to. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [cryptography] Asynchronous forward secrecy encryption
- Forwarded message from zooko - Date: Fri, 27 Sep 2013 00:08:32 +0400 From: zooko To: Michael Rogers Cc: Randombit List Subject: Re: [cryptography] Asynchronous forward secrecy encryption User-Agent: Mutt/1.5.21 (2010-09-15) Let me just mention that this conversation is AWESOME. I only wish the folks over at Perry's Crypto List (http://www.metzdowd.com/pipermail/cryptography/) knew that we were having such a great conversation over here. On Thu, Sep 19, 2013 at 09:20:04PM +0100, Michael Rogers wrote: > > The key reuse issue isn't related to the choice between time-based and > message-based updates. It's caused by keys and IVs in the current design > being derived deterministically from the shared secret and the sequence > number. If an endpoint crashes and restarts, it may reuse a key and IV with > new plaintext. Not good. Another defense against this is to generate the IV from the plaintext, possibly from the plaintext in addition to other stuff. There are three things that you might want to throw into your IV generator: 1. the plaintext, 2. a persistent secret key used only for this purpose and known only to this client, 3. a random nonce read from the operating system. I would suggest including 1 and 2 but not 3. This *could* be seen as an alternative to the defense you described: > In the new design, the temporary keys are still derived deterministically > from the shared secret, but the IVs and ephemeral keys are random. Or it could be used as an added, redundant defense. I guess if it is an added, redundant defense then this is the same as including the random nonce -- number 3 from the list above. Regards, Zooko ___ cryptography mailing list cryptogra...@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 signature.asc Description: Digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] prism-proof email in the degenerate case
On Thu, Oct 10, 2013 at 03:54:26PM -0400, John Kelsey wrote: > Having a public bulletin board of posted emails, plus a protocol for > anonymously finding the ones your key can decrypt, seems like a pretty decent > architecture for prism-proof email. The tricky bit of crypto is in making > access to the bulletin board both efficient and private. This is what Bitmessage attempts to achieve, but it has issues. Assuming these can be solved (a rather large if), and glue like https://bitmessage.ch/ is available to be run by end users it could be quite useful. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PGP Key Signing parties
On Thu, Oct 10, 2013 at 04:24:19PM -0700, Glenn Willen wrote: > I am going to be interested to hear what the rest of the list says about > this, because this definitely contradicts what has been presented to me as > 'standard practice' for PGP use -- verifying identity using government issued > ID, and completely ignoring personal knowledge. This obviously ignores the threat model of official fake IDs. This is not just academic for some users. Plus, if you're e.g. linking up with known friends in RetroShare (which implements identities via PGP keys, and degrees of trust (none/marginal/full) by signatures, and allows you to tune your co-operative variables (Anonymous routing/discovery/ forums/channels/use a direct source, if available) depending on the degree of trust. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] funding Tor development
Guys, in order to minimize Tor Project's dependance on federal funding and/or increase what they can do it would be great to have some additional funding ~10 kUSD/month. If anyone is aware of anyone who can provide funding at that level or higher, please contact exec...@torproject.org ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Beowulf] Re: "hobbyists"
From: Kilian CAVALOTTI <[EMAIL PROTECTED]> Subject: Re: [Beowulf] Re: "hobbyists" To: Tim Cutts <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Date: Fri, 20 Jun 2008 10:55:38 -0700 Organization: Bio-X / Clark Center - Stanford University On Friday 20 June 2008 06:51:51 am Tim Cutts wrote: > That'll be why we don't allow Skype, except on one network which, > from a security perspective, is considered to be outside the > Institute, and just as untrusted as the rest of the Internet. I think that's a wise decision. Skype is a giant black box. Fabrice Desclaux published a fair amount of cryptanalysis papers about Skype, each one more frightening than the previous ([1], [2] and [3]) [1]http://www.secdev.org/conf/skype_BHEU06.handout.pdf [2]http://recon.cx/en/f/vskype-part1.pdf [3]http://recon.cx/en/f/vskype-part2.pdf In 2005, an official recommendation has been issued by the French authorities to prohibit usage of Skype in the National Center for Scientific Research (CNRS)'s networks (see [4], and [5] for the machine-translated version) [4]http://www.urec.cnrs.fr/rubrique216.html [5]http://translate.google.com/translate?u=http%3A%2F%2Fwww.urec.cnrs.fr%2Frubrique216.html&hl=en&ie=UTF8&sl=fr&tl=en -- Kilian ___ Beowulf mailing list, [EMAIL PROTECTED] To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf -- -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
how bad is IPETEE?
In case somebody missed it, http://www.tfr.org/wiki/index.php?title=Technical_Proposal_(IPETEE) I'm not sure what the status of http://postel.org/anonsec/ is, the mailing list traffic dried up a while back. -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: road toll transponder hacked
On Wed, Aug 27, 2008 at 12:16:23PM -0400, Steven M. Bellovin wrote: > Finally, the transponders may not matter much longer; OCR on license > plates is getting that good. As has already been mentioned, the 407 > ETR road in Toronto already relies on this to some extent; it won't be > too much longer before the human assist is all but unneeded. http://en.wikipedia.org/wiki/Toll_Collect is in operation in entire Germany. It does OCR on all license plates (also used for police purposes in realtime, despite initial vigorous denial) but currently is only used for truck toll. -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: road toll transponder hacked
On Thu, Aug 28, 2008 at 06:03:14PM +0200, Stefan Kelm wrote: > We've been helping the German "Toll Collect" system (as > discussed in this thread as well) setting up and implementing > their data privacy concept. This concept requires Toll Collect > to delete almost any data after a certain (quite short, actually) They (not Toll Collect, though) do a realtime query against a reasonably long list of license plates in some German states, I recall reading. http://www.heise.de/newsticker/Hessische-Polizei-hat-seit-Maerz-eine-Million-Kfz-Kennzeichen-gescannt--/meldung/99197 > amount of time. Even with disk prices falling they save lots > and lots of money (even compared to what we charged them for > telling them... :-) ). Given where things are headed in Germany, I guarantee you Toll Collect will be required by law to do data retention for at least a year or two in less than 5 years. http://www.heise.de/newsticker/Debatte-um-Zugriff-auf-LKW-Mautdaten-fuer-Fahndungen-geht-weiter--/meldung/76321 -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
26 historic Enigmas found in Spain
http://www.theregister.co.uk/2008/10/24/spanish_enigmas/ Spanish discover cache of 26 Enigma machines Franco's 'secret weapon' tracked to army HQ By Lester Haines Posted in Science, 24th October 2008 10:03 GMT Spanish newspaper El Pa�s last week tracked down 26 examples of Franco's "secret weapon" against Republican forces in the country's civil war - a cache of perfectly-preserved Enigma machines hidden for years in a "gloomy office" in the army's main headquarters in Madrid. Nationalist forces led by Franco acquired their first ten Enigma machines from Germany in 1936. While Hitler "had already decided to offer Franco his full support" in the Spanish civil war, this didn't actually extend to the full-fat military versions of Enigma, and his Iberian ally had to make do with the "vastly inferior" commercial "D" model. The German High Command was apparently concerned that careless Spaniards might let the Republicans get their hands on an Enigma. Indeed, even Germany's Condor Legion - dispatched to Spain to aid the Nationalist cause - also reportedly used commercial Enigmas in the field. Nonetheless, the Republicans were never able to decipher Enigma communications between Franco and his top brass, and the machines' success led to further acquisitions. Commander Antonio Sarmiento, charged with training operators in Franco's Salamanca headquarters, enthusiastically reported in 1936: ?To give some idea of the level of security these machines offer, it's suffice to say that the number of possible combinations is an astounding 1,252,962,387,456.? The total number of machines eventually bought by Spain is unknown, although estimates vary from 30 to 50. They were not withdrawn from service until the early 1950s, which offers the rather agreeable possibility that the British were able to read the Spanish dictatorship's military communications while Franco remained blissfully unaware that his Nazi sponsors' device had been laid bare by Bletchley Park years before. Bootnote El Reg is, of course, supporting Bletchley Park and the National Museum of Computing with our splendid Enigma t-shirt. Get it before Cash'n'Carrion's free shipping offer ends on 31 October. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
the skein hash function
http://www.schneier.com/blog/archives/2008/10/the_skein_hash.html?1 October 29, 2008 The Skein Hash Function NIST is holding a competition to replace the SHA family of hash functions, which have been increasingly under attack. (I wrote about an early NIST hash workshop here.) Skein is our submission (myself and seven others: Niels Ferguson, Stefan Lucks, Doug Whiting, Mihir Bellare, Tadayoshi Kohno, Jon Callas, and Jesse Walker). Here's the paper: Executive Summary Skein is a new family of cryptographic hash functions. Its design combines speed, security, simplicity, and a great deal of flexibility in a modular package that is easy to analyze. Skein is fast. Skein-512 -- our primary proposal -- hashes data at 6.1 clock cycles per byte on a 64-bit CPU. This means that on a 3.1 GHz x64 Core 2 Duo CPU, Skein hashes data at 500 MBytes/second per core -- almost twice as fast as SHA-512 and three times faster than SHA-256. An optional hash-tree mode speeds up parallelizable implementations even more. Skein is fast for short messages, too; Skein-512 hashes short messages in about 1000 clock cycles. Skein is secure. Its conservative design is based on the Threefish block cipher. Our current best attack on Threefish-512 is on 25 of 72 rounds, for a safety factor of 2.9. For comparison, at a similar stage in the standardization process, the AES encryption algorithm had an attack on 6 of 10 rounds, for a safety factor of only 1.7. Additionally, Skein has a number of provably secure properties, greatly increasing confidence in the algorithm. Skein is simple. Using only three primitive operations, the Skein compression function can be easily understood and remembered. The rest of the algorithm is a straightforward iteration of this function. Skein is flexible. Skein is defined for three different internal state sizes -- 256 bits, 512 bits, and 1024 bits -- and any output size. This allows Skein to be a drop-in replacement for the entire SHA family of hash functions. A completely optional and extendable argument system makes Skein an efficient tool to use for a very large number of functions: a PRNG, a stream cipher, a key derivation function, authentication without the overhead of HMAC, and a personalization capability. All these features can be implemented with very low overhead. Together with the Threefish large-block cipher at Skein core, this design provides a full set of symmetric cryptographic primitives suitable for most modern applications. Skein is efficient on a variety of platforms, both hardware and software. Skein-512 can be implemented in about 200 bytes of state. Small devices, such as 8-bit smart cards, can implement Skein-256 using about 100 bytes of memory. Larger devices can implement the larger versions of Skein to achieve faster speeds. Skein was designed by a team of highly experienced cryptographic experts from academia and industry, with expertise in cryptography, security analysis, software, chip design, and implementation of real-world cryptographic systems. This breadth of knowledge allowed them to create a balanced design that works well in all environments. Here's source code, text vectors, and the like for Skein. Watch the Skein website for any updates -- new code, new results, new implementations, the proofs. NIST's deadline is Friday. It seems as if everyone -- including many amateurs -- is working on a hash function, and I predict that NIST will receive at least 80 submissions. (Compare this to the 21 submissions NIST received -- five were rejected as not being complete -- for the AES competition in 1998.) I expect people to start posting their submissions over the weekend. (Ron Rivest already presented MD6 at Crypto in August.) Probably the best place to watch for new hash functions is here; I'll try to keep a listing of the submissions myself. The selection process will take around four years. I've previously called this sort of thing a cryptographic demolition derby -- last one left standing wins -- but that's only half true. Certainly all the groups will spend the next couple of years trying to cryptanalyze each other, but in the end there will be a bunch of unbroken algorithms; NIST will select one based on performance and features. NIST has stated that the goal of this process is not to choose the best standard but to choose a good standard. I think that's smart of them; in this process, "best" is the enemy of "good." My advice is this: immediately sort them based on performance and features. Ask the cryptographic community to focus its attention on the top dozen, rather than spread its attention across all 80 -- although I also expect that most of the amateur submissions will be rejected by NIST for not being "complete and proper." Otherwise, people will break the easy ones and the better ones will go unanalyzed. Posted on October 29, 2008 at 4:35 AM ? 22 Comments ? View Blog Reactions To receive these entries once a month by e-m
Quantum direct communication: secrecy without key distribution
From: the physics arXiv blog <[EMAIL PROTECTED]> Subject: the physics arXiv blog To: [EMAIL PROTECTED] Date: Fri, 05 Dec 2008 13:10:50 + [1]the physics arXiv blog [2]Quantum direct communication: secrecy without key distribution Posted: 04 Dec 2008 09:13 PM PST [3]quantum-direct-communication.jpg An interesting development in the world of quantum encryption. In the last couple of years, we've seen a number of quantum key distribution systems being set up that boast close-to-perfect security ([4]although they're not as secure as the marketing might imply). These systems rely on two-part security. The first is the quantum part which reveals whether a message has been intercepted or not. Obviously this is no use when it comes to sending secret message because it can only uncover eavesdroppers after the fact. So Alice sends a one time pad over this quantum channel that she and Bob can later use to encrypt and send a message classically. If this key is compromised, Alice sends another. What guarantees the security is not quantum mechanics but the second part of the system: the one time pad. Today, Seth Lloyd and colleagues at the Massachusetts Institute of Technology in Cambridge, publish a way of guaranteeing security over a quantum channel without having to fall back on a one time pad. Their idea is to send a message over a standard quantum channel without bothering with a one time pad. The security, they say, can be monitored by randomly checking the channel to see whether any of the qubits are being lost (potentially to Eve). The security of the channel then depends on how much loss of information Alice and Bob are willing to accept, but can always be improved by checking more often for eavesdroppers. Quantum direct communication, as the team call it, looks interesting. But it will be demanding to implement, not least because any noise in the channel will look like an eavesdropper. So it looks as if this idea will have to be limited to short range applications where noise can be kept to a minimum. Nevertheless, a cool idea. Ref: [5]arxiv.org/abs/0802.0656: Quantum Direct Communication with Continuous Variables [6][ISMAP:i] [7][arXivblog?d=41] [8][arXivblog?d=43] [9][arXivblog?i=FkCcdrzA] [10][arXivblog?d=50] [11][arXivblog?i=AA6d3u4X] [12][arXivblog?d=54] [13][arXivblog?i=gWxiPcYK] [14][arXivblog?d=52] You are subscribed to email updates from [15]the physics arXiv blog To stop receiving these emails, you may [16]unsubscribe now. Email delivery powered by Google Inbox too full? [17](feed) [18]Subscribe to the feed version of the physics arXiv blog in a feed reader. If you prefer to unsubscribe via postal mail, write to: the physics arXiv blog, c/o Google, 20 W Kinzie, Chicago IL USA 60610 References 1. http://arxivblog.com/ 2. http://feedproxy.google.com/~r/arXivblog/~3/L2dvPUasU7A/ 3. http://arxivblog.com/wp-content/uploads/2008/12/quantum-direct-communication.jpg 4. http://arxivblog.com/?p=637 5. http://arxiv.org/abs/0802.0656 6. https://feedads.googleadservices.com/~a/i7RRFcowUHJnq_spRFzOodIFPIY/a 7. http://feedproxy.google.com/~f/arXivblog?a=HIgKcQ0O 8. http://feedproxy.google.com/~f/arXivblog?a=bO8lGfma 9. http://feedproxy.google.com/~f/arXivblog?a=FkCcdrzA 10. http://feedproxy.google.com/~f/arXivblog?a=ybFs1PaM 11. http://feedproxy.google.com/~f/arXivblog?a=AA6d3u4X 12. http://feedproxy.google.com/~f/arXivblog?a=sdxB9J6P 13. http://feedproxy.google.com/~f/arXivblog?a=gWxiPcYK 14. http://feedproxy.google.com/~f/arXivblog?a=rqQMNiZh 15. http://arxivblog.com/ 16. http://feedburner.google.com/fb/a/mailunsubscribe?k=118r9-S4Z0vJg-AkQPASPmDmlGQ 17. http://feedproxy.google.com/arXivblog 18. http://feedproxy.google.com/arXivblog ------ -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [Opensim-dev] Technical assessment of Cable Beach asset server
From: Toni Alatalo Subject: Re: [Opensim-dev] Technical assessment of Cable Beach asset server To: opensim-...@lists.berlios.de Date: Thu, 15 Jan 2009 18:47:00 +0200 Reply-To: opensim-...@lists.berlios.de Eugen Leitl kirjoitti: > On Thu, Jan 15, 2009 at 02:10:13PM +0900, Mike Mazur wrote: > As an aside from the peanut gallery, it would be nice to have asset > storage in a distributed cryptographic filestore like Tahoe > http://allmydata.org/~warner/pycon-tahoe.html > that has been my understanding as well. basically after worked a bit with the guys who pushed it in the Fenfire project (in 2002). i've understood that basically by using URIs as references to assets we get that: URLs for current http stuff and location independent URNs with distributed things like p2p networks. seems that Tahoe also uses "short URI-like strings" - dunno why 'URI-like' and not just URIs but anyway :) .. also as SL and OpenSim already uses UUIDs i guess some things are basically kind of ready for this. http://www.ht03.org/papers/pdfs/24.pdf is about the work in that area i was interested back long ago, dunno about the current implementations whether Tapestry, that Tahoe or something I haven't heard of is the thing, but i guess the basic idea is the same. in that Fenfire Storm the idea was to use content based hashes as IDs of files (like images), similar to Freenode -- the goal not being anonymous publishing in a secure p2p net, but instead having a nice storage system for both local own files and publishing them on the net. goals included the secure storage via redundancy, that seems to be emphasized in Tahoe and is indeed a great motivation for these things. looking forward to learning more, perhaps by testing Tahoe ~~Toni ___ Opensim-dev mailing list opensim-...@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
[tahoe-dev] SHA-1 broken! (was: Request for hash-dependency in Tahoe security.)
case of Merkel Trees, are any security guarantees > preserved in the face of hash collision attacks? Sure -- a Merkle Tree has collision-resistance if the underlying hash has collision-resistance, and a Merkle Tree has second-preimage- resistance if the underlying hash has second-preimage resistance. So if the underlying has doesn't have collision-resistance but does have second-preimage-resistance (as we currently suspect that SHA-1 might), then your Merkle Tree would stil have second-preimage- resistance. Also a Merkle Tree might be stronger than its underlying hash function in a few ways, even if the underlying hash is somewhat weak. > d. For an existing grid how feasible is an upgrade to a new hash > format which preserves all data? It is certainly possible to preserve all the data. The obvious way is to download your files and re-upload them in the new format. I suspect that will probably end up being the best way, too. I would like to emphasize that it is extremely unlikely that anyone will need to do this due to a weakness in the hashing algorithm in Tahoe in a hurry. The people who are suffering from the collisions in MD5 and SHA-1 are suffering, not because MD5 or SHA-1 were suddenly revealed to be insecure, but because they ignored the warning messages from cryptographers for many years. (I'm a tad irritated about this, since "I tried to tell them" [5] and "They wouldn't listen!" [6].) By the time that SHA-256 (plus our tagging and salting) is vulnerable to collisions, which could be anywhere from five years to a hundred years from now, we will have already upgraded Tahoe to use a stronger hash function (SHA-3 or a SHA-3 candidate) and gracefully upgraded pre-existing files. Now the actual details of securely upgrading extant files to new integrity check mechanisms could be interesting. We've thought a bit about how to facilitate future graceful upgrades and this will no doubt prompt us to think about it some more. The stickiest bits are in the capability itself. Let's put it this way: suppose you upload a file to a Tahoe grid today and get an immutable read cap in return. Then suppose a few years from now someone does some unspecified operation which adds stronger hashes to the file as it exists out there on the servers. Now, how do you as the holder of the original immutable read cap know that those new stronger hashes are correct? You don't, because your read-cap wasn't generated from those new stronger hashes. This isn't a weakness in the Tahoe capability-oriented design, it's more of a fundamental problem which is just thrown into sharper light by the cap design. You can, of course, choose to delegate your decision about whether or not the file is correct to someone else (using Tahoe as well as using any other scheme), but if you want to actually have certainty *yourself* that the file is correct using the new hashes, then you're going to have to do some sort of download and computation on the file yourself, using the new hash algorithm. Regards, Zooko [1] http://www.toad.com/gnu [2] http://en.wikipedia.org/wiki/Custom_hardware_attack [3] http://en.wikipedia.org/wiki/List_of_distributed_computing_projects [4] http://en.wikipedia.org/wiki/Bot_nets [5] http://www.gelato.unsw.edu.au/archives/git/0506/5273.html [6] http://www.gelato.unsw.edu.au/archives/git/0506/5299.html _______ tahoe-dev mailing list tahoe-...@allmydata.org http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev -- -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Mission Impossible: The Code Even the CIA Can't Crack
http://www.wired.com/print/science/discoveries/magazine/17-05/ff_kryptos Mission Impossible: The Code Even the CIA Can't Crack By Steven Levy Email 04.20.09 The sculpture named Kryptos at CIA headquarters contains a secret message ? but not even the agency's brightest can crack its code. Photo: Adrian Gaut The most celebrated inscription at the Central Intelligence Agency's headquarters in Langley, Virginia, used to be the biblical phrase chiseled into marble in the main lobby: "And ye shall know the truth, and the truth shall make you free." But in recent years, another text has been the subject of intense scrutiny inside the Company and out: 865 characters of seeming gibberish, punched out of half-inch-thick copper in a courtyard. It's part of a sculpture called Kryptos, created by DC artist James Sanborn. He got the commission in 1988, when the CIA was constructing a new building behind its original headquarters. The agency wanted an outdoor installation for the area between the two buildings, so a solicitation went out for a piece of public art that the general public would never see. Sanborn named his proposal after the Greek word for hidden. The work is a meditation on the nature of secrecy and the elusiveness of truth, its message written entirely in code. Almost 20 years after its dedication, the text has yet to be fully deciphered. A bleary-eyed global community of self-styled cryptanalysts?along with some of the agency's own staffers?has seen three of its four sections solved, revealing evocative prose that only makes the puzzle more confusing. Still uncracked are the 97 characters of the fourth part (known as K4 in Kryptos-speak). And the longer the deadlock continues, the crazier people get. Whether or not our top spooks intended it, the persistent opaqueness of Kryptos subversively embodies the nature of the CIA itself?and serves as a reminder of why secrecy and subterfuge so fascinate us. "The whole thing is about the power of secrecy," Sanborn tells me when I visit his studio, a barnlike structure on Jimmy Island in Chesapeake Bay (population: 2). He is 6'7", bearded, and looks a bit younger than his 63 years. Looming behind him is his latest work in progress, a 28-foot-high re-creation of the world's first particle accelerator, surrounded by some of the original hardware from the Manhattan Project. The atomic gear fits nicely with the thrust of Sanborn's oeuvre, which centers on what he calls invisible forces. With Kryptos, Sanborn has made his strongest statement about what we don't see and can't know. "He designed a piece that would resonate with this workforce in particular," says Toni Hiley, who curates the employees-only CIA museum. Sanborn's ambitious work includes the 9-foot 11-inch-high main sculpture?an S-shaped wave of copper with cut-out letters, anchored by an 11-foot column of petrified wood?and huge pieces of granite abutting a low fountain. And although most of the installation resides in a space near the CIA cafeteria, where analysts and spies can enjoy it when they eat outside, Kryptos extends beyond the courtyard to the other side of the new building. There, copper plates near the entrance bear snippets of Morse code, and a naturally magnetized lodestone sits by a compass rose etched in granite. "People call me an agent of Satan," says artist Sanborn, "because I won't tell my secret." Photo: Adrian Gaut The heart of the piece, though, is the encrypted text, scrambled, Sanborn says, by "a coding system that would unravel itself slowly over a period of time." When he began the work, Sanborn knew very little about cryptography, so he reluctantly accepted the CIA's offer to work with Ed Scheidt, who had just retired as head of Langley's Cryptographic Center. Scheidt himself was serving two masters. "I was reminded of my need to preserve the agency's secrets," Scheidt says. "You know, don't tell him the current way of doing business. And don't create something that you cannot break?but at the same time, make it something that will last a while." Scheidt schooled Sanborn in cryptographic techniques employed from the late 19th century until World War II, when field agents had to use pencil and paper to encode and decode their messages. (These days, of course, cryptography is all about rugged computer algorithms using long mathematical keys.) After experimenting with a range of techniques, including poly-alphabetic substitution, shifting matrices, and transposition, the two arrived at a form of old-school, artisanal cryptography that they felt would hold off code breakers long enough to generate some suspense. The solutions, however, were Sanborn's alone, and he did not share them with Scheidt. "I assumed the first three sections would be deciphered in a matter of weeks, perhaps months," Sanborn says. Scheidt figured the whole puzzle would be solved in less than seven years. During the two years of construction, there were moments of intrigue and paranoia, in keep
Tellitec Tellinet Sat Spy manual leaked
http://wikileaks.org/wiki/Tellitec_Tellinet_Sat_Spy_manual%2C_6_Mar_2006 Tellitec Tellinet Sat Spy manual, 6 Mar 2006 May 24, 2009 Summary Tellinet is an accelerator for satellite communications made by Tellitec GmbH of Berlin. It supports encrypted TCP (ETCP), but as this confidential manual shows, it also supports covert remote interception of communications data. DOWNLOAD/VIEW FULL FILE FROM fast site, current site, Sweden, US, Latvia, Slovakia, UK, Finland, Netherlands, Poland, Tonga, Europe, SSL, Tor Context Germany Primary language English File size in bytes 2170498 File type information PDF document, version 1.3 Cryptographic identity SHA256 c1ac645e16624815e9ef75dd3d959b1b681e82b68a5261a4cea3c7a6f251370b - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: [btns] IETF75
I can has contributions, please?
From: Michael Richardson
Subject: Re: [btns] IETF75
To: Eugen Leitl
cc: b...@ietf.org
Date: Wed, 24 Jun 2009 15:03:33 -0400
>>>>> "Eugen" == Eugen Leitl writes:
Eugen> On Wed, Jun 24, 2009 at 03:15:59PM +0200, Julien Laganier
Eugen> wrote:
>> We're currently progressing connexion latching thru IESG.
>>
>> What remains to be done for the WG is to complete the API work
>> item. Since those haven't been discussed much on the mailing
>> list we felt that a meeting wouldn't be productive.
Eugen> How far is the proposed standard from being able to hit the
Eugen> road? I realize "it's done when it's done" but are we
Eugen> looking at months, years, half a decade until there's a first
Eugen> implementation available to beta testers?
Read the document and comment.
The API documents are stuck for lack of contributions.
--
] Y'avait une poule de jammé dans l'muffler!| firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
]h("Just another Debian GNU/Linux using, kernel hacking,ruby guy"); [
--
--
Eugen* Leitl http://leitl.org";>leitl http://leitl.org
__
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Serpent close to AES speed thanks to SSE2
http://www.randombit.net/bitbashing/programming/serpent_in_simd.html Wed, 09 Sep 2009 Speeding up Serpent: SIMD Edition The Serpent block cipher was one of the 5 finalists in the AES competition, and is widely thought to be the most secure of them due to its conservative design. It was also considered the slowest candidate, which is one major reason it did not win the AES contest. However, it turns out that on modern machines one can use SIMD operations to implement Serpent at speeds quite close to AES. Serpent uses an interesting bitsliced design with eight 4 bit sboxes which are computed in parallel using boolean operations on registers. Rather than splitting up the 32 bit words into nibbles and passing them through table lookups, a special instruction sequence is used which performs the same operation using only instructions like AND, OR, XOR, and NOT. Typically these are done using 32 bit register operations, but it was recently suggested that SIMD operations such as those available in SSE2 or AltiVec could be used to encrypt 4 blocks in parallel. Most cipher modes, such as CBC and OFB, are iterative; after splitting the plaintext into blocks, the input to the second block depends on the previously computed ciphertexts. This data dependency means it is impossible to use a block-parallel implementation in these modes. However some other modes, including CTR, EAX, and XTS, do not exhibit this data dependency, and allow for many blocks to be encrypted in parallel. So being able to compute many encryptions in parallel is only useful for these modes. Fortunately, CTR, EAX, and XTS are very useful, unpatented, and (in the case of CTR and XTS) widely standardized modes. Recently I implemented Serpent using SSE2 intrinsics in the botan cryptography library. While not quite as fast as AES, it easily boosts Serpents performance by a factor of over 2.5 on an Intel Core2 processor. Up until now, botan has used a rather conventional block cipher interface where only a single block of data (typically 64 or 128 bits) would be encrypted at a time; processing multiple blocks required calling the function multiple times, one for each block. However this completely hides any parallelism from the block cipher implementation. So in the upcoming development release (1.9.0), botan offers two new interfaces for block ciphers: void encrypt_n(const byte in[], byte out[], u32bit blocks) const; void decrypt_n(const byte in[], byte out[], u32bit blocks) const; which will process many blocks in a single call. In addition some mode implementations (at this time, ECB and CTR) will batch their inputs into larger groups. This will not only allow for parallel encryption using SIMD techniques, it also improves instruction and data cache utilization for all ciphers. Right now, the modes will batch 8 blocks of data together; it is unclear if this is sufficient for the best performance, but in any case is easy to modify by changing a macro value in build.h. On a 2.4 GHz Intel Core2 with GNU C++ 4.3.3, I got these results: Algorithm 1.8.6 (MiB/s) 1.9.0 (MiB/s) Speedup Serpent/ECB 42.1113.5 2.7 Serpent/CTR 39.7100.8 2.5 AES-128/ECB 112.7 134.4 1.2 AES-128/CTR 99.1114.1 1.15 The AES speedups nicely demonstrate that even without any explicit SIMD operations, the improved cache utilization can make a pretty big difference. I also experimented with performing 8 Serpent block operations in parallel, by interleaving two 4-wide SIMD encryptions. This reduced the number of key variable loads, as well as offering the processor much more in the way of independent computations for hot hot superscalar action. On my Core2, this pushed Serpent's performance north of 160 MiB/s in CTR mode, which is pretty impressive considering that is right about the speed of OpenSSL's AES-128 implementation on the same platform. However this variant seems slower on anything but a Core2; tests on an Opteron showed it to be somewhat slower than 4-way SIMD, and it is highly likely that it would also be much slower on 32-bit x86 processors due to excessive register pressure. AltiVec looks to be an even more promising platform for multiblock Serpent encryption, as it includes native rotation instructions, which in SSE2 must be emulated using two shifts and an OR. It is very likely the Cell processors SIMD units could also implement Serpent in a SIMD mode. Considering the Cell SPE contains 128 SIMD registers, it might even be feasible to implement a variant suggested by Wei Dai of encrypting 128 blocks in parallel without suffering an excessive number of register spills. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Old Trick Threatens the Newest Weapons
http://www.nytimes.com/2009/10/27/science/27trojan.html?8dpc=&pagewanted=all Old Trick Threatens the Newest Weapons By JOHN MARKOFF Published: October 26, 2009 Despite a six-year effort to build trusted computer chips for military systems, the Pentagon now manufactures in secure facilities run by American companies only about 2 percent of the more than $3.5 billion of integrated circuits bought annually for use in military gear. That shortfall is viewed with concern by current and former United States military and intelligence agency executives who argue that the menace of so-called Trojan horses hidden in equipment circuitry is among the most severe threats the nation faces in the event of a war in which communications and weaponry rely on computer technology. As advanced systems like aircraft, missiles and radars have become dependent on their computing capabilities, the specter of subversion causing weapons to fail in times of crisis, or secretly corrupting crucial data, has come to haunt military planners. The problem has grown more severe as most American semiconductor manufacturing plants have moved offshore. Only one-fifth of all computer chips are now made in the United States, and just one-quarter of the chips based on the most advanced technologies are built here, I.B.M. executives say. That has led the Pentagon and the National Security Agency to expand significantly the number of American plants authorized to manufacture chips for the Pentagon s Trusted Foundry program. Despite the increases, semiconductor industry executives and Pentagon officials say, the United States lacks the ability to fulfill the capacity requirements needed to manufacture computer chips for classified systems. The department is aware that there are risks to using commercial technology in general and that there are greater risks to using globally sourced technology, said Robert Lentz, who before his retirement last month was in charge of the Trusted Foundry program as the deputy assistant defense secretary for cyber, identity and information assurance. Counterfeit computer hardware, largely manufactured in Asian factories, is viewed as a significant problem by private corporations and military planners. A recent White House review noted that there had been several unambiguous, deliberate subversions of computer hardware. These are not hypothetical threats, the report s author, Melissa Hathaway, said in an e-mail message. We have witnessed countless intrusions that have allowed criminals to steal hundreds of millions of dollars and allowed nation-states and others to steal intellectual property and sensitive military information. Ms. Hathaway declined to offer specifics. Cyberwarfare analysts argue that while most computer security efforts have until now been focused on software, tampering with hardware circuitry may ultimately be an equally dangerous threat. That is because modern computer chips routinely comprise hundreds of millions, or even billions, of transistors. The increasing complexity means that subtle modifications in manufacturing or in the design of chips will be virtually impossible to detect. Compromised hardware is, almost literally, a time bomb, because the corruption occurs well before the attack, Wesley K. Clark, a retired Army general, wrote in an article in Foreign Affairs magazine that warns of the risks the nation faces from insecure computer hardware. Maliciously tampered integrated circuits cannot be patched, General Clark wrote. They are the ultimate sleeper cell. Indeed, in cyberwarfare, the most ancient strategy is also the most modern. Internet software programs known as Trojan horses have become a tool of choice for computer criminals who sneak malicious software into computers by putting it in seemingly innocuous programs. They then pilfer information and transform Internet-connected PCs into slave machines. With hardware, the strategy is an even more subtle form of sabotage, building a chip with a hidden flaw or a means for adversaries to make it crash when wanted. Pentagon executives defend the manufacturing strategy, which is largely based on a 10-year contract with a secure I.B.M. chipmaking plant in Burlington, Vt., reported to be valued as high as $600 million, and a certification process that has been extended to 28 American chipmakers and related technology firms. The department has a comprehensive risk-management strategy that addresses a variety of risks in different ways, said Mitchell Komaroff, the director of a Pentagon program intended to develop a strategy to minimize national security risks in the face of the computer industry s globalization. Mr. Komaroff pointed to advanced chip technologies that made it possible to buy standard hardware components that could be securely programmed after they were acquired. But as military planners have come to view cyberspace as an impending battlefield, American intelligence agency experts said, all
AES-CBC + Elephant diffuser
"We discuss why no existing cipher satisfies the requirements of this application". Uh-oh. http://www.microsoft.com/downloads/details.aspx?FamilyID=131dae03-39ae-48be-a8d6-8b0034c92555&DisplayLang=en AES-CBC + Elephant diffuser Brief Description A Disk Encryption Algorithm for Windows Vista The specifications of the AES-CBC + diffuser algorithm used in BitLocker Drive Encryption Overview The Bitlocker Drive Encryption feature of Windows Vista poses an interesting set of security and performance requirements on the encryption algorithm used for the disk data. We discuss why no existing cipher satisfies the requirements of this application and document our solution which consists of using AES in CBC mode with a dedicated diffuser to improve the security against manipulation attacks. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: AES-CBC + Elephant diffuser
On Thu, Oct 29, 2009 at 07:15:53AM -0700, Paul Hoffman wrote: > At 2:24 PM +0100 10/29/09, Eugen Leitl wrote: > >"We discuss why no existing cipher satisfies the requirements of this > >application". Uh-oh. > > Yeah, we all know what a light-weight and careless person Neils Ferguson is. > Who would listen to him? Ah, should have spent a few seconds looking him up http://en.wikipedia.org/wiki/Niels_Ferguson http://www.macfergus.com/ -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Fault-Based Attack of RSA Authentication
From: basile Date: Thu, 04 Mar 2010 19:20:36 -0500 To: or-t...@freehaven.net Subject: Fault-Based Attack of RSA Authentication User-Agent: Thunderbird 2.0.0.23 (X11/20090817) Reply-To: or-t...@freehaven.net Hi everyone, I thought this might be of interest to the list. Pellegrini, Bertacco and Austin at U of Michigan have found an interesting way to deduce the secret key by fluctuating a device's power supply. Its a minimal threat against servers, but against hand held devices its more practical. The openssl people say there's an easy fix by salting. Here's some referneces: http://www.theregister.co.uk/2010/03/04/severe_openssl_vulnerability/ http://www.eecs.umich.edu/~valeria/research/publications/DATE10RSA.pdf -- Anthony G. Basile, Ph.D. Chair of Information Technology D'Youville College Buffalo, NY 14201 USA (716) 829-8197 ------ -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: [vserver] Bought an entropykey - very happy
From: coderman Date: Wed, 24 Mar 2010 10:50:33 -0700 To: Morlock Elloi Cc: cypherpu...@al-qaeda.net Subject: Re: [vserver] Bought an entropykey - very happy On Wed, Mar 24, 2010 at 8:43 AM, Morlock Elloi wrote: > While avalanche noise (hoping it doesn't start to tunnel - that current must be actively controlled as each junction is different) is a good source of randomness (up to megabits / sec / junction), "encrypting" it just means masking possible low entropy. I'd prefer to see raw conditoned stream than "encrypted" one (even web content looks high-entropy to Diehard when encrypted). >... i have loved the padlock engines on via cores since they hit the market in C5XL form with a single hw generator available via XSTORE. unlike many designs this free wheeling resource can provide a torrent of entropy sufficient to sate even the most gregarious consumption. as mentioned above, you need a fast user space entropy daemon sanity checking the raw, (probably) biased stream coming from hardware but it is still good practice to digest this entropy to obscure any potential generator state/bias heading into the host entropy pool. that is to say, of the two common modes for utilizing hw entropy: a. conservatively sample from a whitened, string filtered entropy source for a low rate of high quality output (see xstore config words) b. ramp un-whitened, un-filtered source(s) to maximum rate and AES/SHA mix for high throughput, high quality output while irreversibly masking generator bias/state present in the raw source stream. the latter is more effective in practice and capable of generation rates > 20Mbps with full FIPS sanity checks. the former tops out around 1Mbps or less with more transient latency spikes on read (when successive attempts to read fail to pass whiten+strfilter). note that padlock engine supports SHA and AES on die as well making these easy and fast to apply to generator output. if you are still concerned a more conservative configuration would estimate entropy density while feeding from raw input stream and add encrypted/digested product to the host entropy pool with the specified entropy density estimate adjusted downward to your requirements. (most OS'es support this) -- -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Quantum Key Distribution: the bad idea that won't die...
On Thu, Apr 22, 2010 at 09:46:18AM -0400, John Lowry wrote: > My own speculation is that the security community and its interests are > perhaps a bit broader than than some members wish it were. > > If you want to see some interesting physics that represents unexpected > results relevant to communications (and comes from entangled QKD research) > then take a look at: http://pra.aps.org/abstract/PRA/v81/i2/e023835 This is interesting. However, even if you can use LoS up to LEO, the question is of what the added value of a (supposedly, trend in QC state cloning attacks is there) tamperproof exchange is over traditional cryptography. I agree with Perry that it solves a non-problem. > There is a human-readable summary at: http://focus.aps.org/story/v25/st7 -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Intel to also add RNG
http://www.technologyreview.com/printer_friendly_article.aspx?id=25670&channel=Briefings§ion=Microprocessors Tuesday, June 29, 2010 Nanoscale Random Number Circuit to Secure Future Chips Intel unveils a circuit that can pump out truly random numbers at high speed. By Tom Simonite It might sound like the last thing you need in a precise piece of hardware, but engineers at Intel are pretty pleased to have found a way to build a circuit capable of random behavior into computer processors. Generating randomness--an unpredictable stream of numbers--is much harder than you might think. It's also crucial to creating the secure cryptographic keys needed to keep data safe. Building a random-number-generating ability into the Central Processing Unit (CPU) at a computer's heart is ideal, says Ram Krishnamurthy, an engineer at Intel's Microprocessor Technology Labs, in Hillsboro, OR. It should speed up any process that requires the generation of an encrypted key, for example securing sensitive data on a hard drive, and make it harder for an attacker to compromise that encryption. Building circuitry capable of producing random numbers into a CPU has proved difficult. "Today random numbers are either generated in software, or in the chip set outside the microprocessor," explains Krishnamurthy, one of the Intel researchers on the project. Neither solution is ideal. Software produces only pseudo random numbers (given enough computing power, patterns can be found within that randomness). "If the random numbers are not truly random, for example, if they are biased in some way, then an adversary has a better chance of guessing/determining the value," explains mathematician Elaine Barker, at the National Institute for Standards and Technology (NIST), in Gaithersburg, MD. "In the case of cryptographic keys, if the adversary can determine the key without an excessive amount of computing power, then he can breach the confidentiality of that data." Installing a source of random numbers outside of a computer's core microprocessor provides another avenue of opportunity to attackers, says Krishnamurthy. "You are vulnerable to side channel attacks," he explains, "there are many ways by which the key can be directly read off of the bus, or attacks that look at how the power supply varies and look for signatures that indicate what the key looks like." Building the circuit into the main processor shuts off that possibility, says Krishnamurthy, although the barrier to doing that has been practicality. The best-established methods of generating random numbers use analog circuits that rely on thermal noise as a source of randomness, and those circuits are not easily fabricated with the techniques used to make the digital circuits of a microprocessor. Nor are they easily scaled down to the size of components on modern chips. Intel's new circuit has a fully-digital design, making it possible to incorporate it into the microprocessor die. At the heart of the new design is a cross-coupled inverter, a combination of two basic circuit components that is essentially a memory capable of storing a single 1 or 0. This memory, though, is designed to be unreliable; it can be tipped between its two possible outputs by the influence of thermal noise from the surrounding silicon. Since that thermal noise is random, the circuit's output should be, too. In reality, though, the influence of fluctuations in voltage and temperature normal inside a chip could bias that output to be less-than-random, requiring Krishnamurthy and colleagues to develop additional measures to counteract their influence. Benchmarks for "true" randomness maintained by NIST were used to confirm they had been successful. "We exceeded all of those thresholds," he says. The speed at which the new circuit cranks out numbers--2.4 billion a second or 2.4Gbps--is also around 200 times faster than anything before, Krishnamurthy adds. Having built the circuit with a smallest feature size of 45 nanometers, he and colleagues are now working toward proving it can be built using 32 and 22 nanometer manufacturing processes with minimal design tweaks. Passing existing benchmarks of randomness, though, does not mean the new circuit is perfect. Current techniques do not make it possible to be certain that any source of randomness is truly random, says Barker. "We just don't know enough to design tests that catch all the problems, and tests may not always catch the point at which a noise source starts to go bad if the change is subtle." Research by groups like that at NIST will generate smarter tests that help industry engineers raise the bar further. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: GSM eavesdropping
On Mon, Aug 02, 2010 at 03:46:24PM -0500, Nicolas Williams wrote: > > "The default mode for any internet communication is encrypted" > > That's... extreme. There are many things that will not be encrypted, Extreme? I don't see why my ISP should be able to inspect and monetize my data stream. > starting with the DNS itself, and also most public contents (because Encryption is cheap enough (especially if you cache keys from previous sessions). Why not encrypt everything? > their purveyors won't want to pay for the crypto; sad but true). -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Former Stasi Cryptographers Now Develop Technology for NATO
http://www.spiegel.de/international/germany/0,1518,druck-719726,00.html 09/27/2010 11:23 AM Recruited by West Germany Former Stasi Cryptographers Now Develop Technology for NATO By Marcel Rosenbach and Holger Stark After the fall of the Berlin Wall, the West Germans were desperate to prevent the Stasi's top codebreakers from falling into the wrong hands. from falling into the wrong hands and set up a company to hire the East German cryptographers. Now the former Stasi scientists develop technology used by Angela Merkel and NATO. Every morning, while going to his office in Berlin's Adlershof district, Ralph W. passes a reminder of his own past, a small museum that occupies a room on the ground floor of the building. The museum could easily double as a command center run by the class enemy in an old James Bond film. A display of coding devices from various decades includes the T-310, a green metal machine roughly the size of a huge refrigerator, which East German officials used to encode their telex messages. The device was the pride of the Stasi, the feared East German secret police, which was W.'s former employer. Today he works as a cryptologist with Rohde & Schwarz SIT GmbH (SIT), a subsidiary of Rohde & Schwarz, a Munich-based company specializing in testing equipment, broadcasting and secure communications. W. and his colleagues encode sensitive information to ensure that it can only be read or heard by authorized individuals. Their most important customers are NATO and the German government. Rohde & Schwarz is something of an unofficial supplier of choice to the German government. Among other things, the company develops bugproof mobile phones for official use. Since 2004, its Berlin-based subsidiary SIT, which specializes in encryption solutions, has been classified as a "security partner" to the German Interior Ministry, which recently ordered a few thousand encoding devices for mobile phones, at about €1,250 ($1,675) apiece. Even German Chancellor Angela Merkel has used phones equipped with SIT's encryption technology. In other words, the Stasi's former cryptographers are now Merkel's cryptographers. Secret Operation The transfer of Ralph W. and other cryptologists from the East German Ministry for State Security, as the Stasi was officially known, to West Germany was handled both seamlessly and discreetly. West German officials were determined to make sure that no one would find out about the integration of East Germany's top cryptologists into the west. The operation was so secret, in fact, that it has remained unknown to this day. Only a handful of officials were involved in the operation, which was planned at the West German Interior Ministry in Bonn. In January 1991, Rohde & Schwarz SIT GmbH was founded. The company was established primarily to provide employment for particularly talented Stasi cryptologists that the Bonn government wanted to keep in key positions. Ralph W. is one of those specialists. W., who holds a doctorate in mathematics, signed a declaration of commitment to the Stasi on Sept. 1, 1982. By the end of his time with the Stasi, he was making 22,550 East German marks a year -- an excellent salary by East German standards. And when he was promoted to the rank of captain in June 1987, his superior characterized W. as one of the "most capable comrades in the collective." While with the Stasi, W. worked in Department XI, which also boasted the name "Central Cryptology Agency" (ZCO). Looking for the Top Performers The story begins during the heady days of the East German revolution in 1990. Officially, the East German government, under its last communist premier, Hans Modrow, had established a government committee to dissolve the Ministry for State Security which reported to the new East German interior minister, Peter-Michael Diestel. In reality, the West German government was already playing a key role in particularly sensitive matters. Then-West German Interior Minister Wolfgang Schäuble (who is the current German finance minister) had instructed two senior Interior Ministry officials, Hans Neusel and Eckart Werthebach, to take care of the most politically sensitive remnants of the 40-year intelligence war between the two Germanys. The government of then-Chancellor Helmut Kohl was interested in more than just the politically explosive material contained in some of the Stasi's files. It also had its eye on the top performers in the former East German spy agency. The cryptologists were of particular interest to the Kohl government, which recognized that experts capable of developing good codes would also be adept at breaking them. The Stasi cryptologists were proven experts in both fields. Documents from the Stasi records department indicate that the one of the Stasi cryptologists' achievements was to break Vericrypt and Cryptophon standards that had been used until the 1980s. This meant that they were capable of decoding encrypted radio transmissions by the two
[tt] Random numbers created out of nothing
Right from the snake-oil-security-dept. - Forwarded message from Arlind Boshnjaku - From: Arlind Boshnjaku Date: Thu, 30 Sep 2010 14:48:44 +0200 To: transhumanist news Subject: [tt] Random numbers created out of nothing http://www.newscientist.com/article/dn19520-random-numbers-created-out-of-nothing.html Random numbers created out of nothing 12:36 30 September 2010 by Kate McAlpine It's something from nothing. A random number generator that harnesses the quantum fluctuations in empty space could soon sit inside your computer. A device that creates truly random numbers is vital for a number of applications, including cryptography. Algorithms can generate numbers that pass statistical tests for randomness, but they're useless for secure cryptography if the algorithm falls into the wrong hands. Other methods using entangled ions to generate random numbers are more reliable, but tend to be slower and more expensive. Now Christian Gabriel's team at the Max Planck Institute for the Science of Light in Erlangen, Germany, has built a prototype that draws on a vacuum's random quantum fluctuations. These impart random noise to laser beams in the device, which converts it into numbers. "It's an easy method, and it's good value," says Gabriel. The team sent a laser into a beam splitter, sheltered from external light sources. Without influence from the vacuum, the two emerging beams would have been identical. However, the lowest energy state of the electromagnetic field carries just enough energy to interact with the laser as it passes through the beam splitter. "The beams carry this quantum noise," says Gabriel. The exiting beams were captured in two detectors which turned the light into electronic signals, and the signals were subtracted from one another, leaving only the noise from the vacuum and electronics. The team used a mathematical function to tease out the truly random signal of the vacuum. Because they could calculate the total disorder in the system and the portion which comes from the vacuum, they were able to reduce the set of numbers so that the electronic contribution was eliminated and only a fully random string remained. Though reduced, the stream of bits comes at speedy 6.5 million per second. This is already in line with the speed of commercially available quantum random number generators, say the researchers, but they hope to achieve rates more than 30 times higher. Collaborator Christoph Marquardt says the generator's optimised speed will be "faster than anything you could buy or that is available in other comparable systems nowadays". The lab set-up costs about €1000, and the researchers estimate that the cost could fall to about €100. As the device functions at room temperature and could be made to fit in the palm of your hand, it may one day be integrated into a desktop computer. Antonio Acín of the Institute for Photonic Sciences in Barcelona, Spain, points out that although the quantum noise of the vacuum is tamper-proof, most users won't be able to verify the workings of their random number generators – meaning they'll find it impossible to tell whether they are receiving a unique random stream from the generator or a pre-programmed, statistically random set from elsewhere. Journal source: Nature Photonics, DOI: 10.1038/nphoton.2010.197 ___ tt mailing list t...@postbiota.org http://postbiota.org/mailman/listinfo/tt - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: [tt] Random numbers created out of nothing
On Thu, Sep 30, 2010 at 11:23:39PM -0400, Jerry Leichter wrote: > On Sep 30, 2010, at 9:24 AM, Eugen Leitl wrote: >> Right from the snake-oil-security-dept. > Really? Just what about it is snake oil? Quantum vacuum fluctuations That QM RNGs are special in comparison to other RNGs, which have been shipping in mainstream systems (both chipsets and CPUs) for many years. > are real, they're random in as strong a sense as anything we have access > to. True random numbers are a fundamental primitive. They're talking > 200 Mb/second for 100 Euros. That's not bad, if they can get there. How about GBit/s, for free? http://spectrum.ieee.org/computing/hardware/intel-makes-a-digital-coin-tosser-for-future-processors > What in the claims here is false, misleading, solves a problem for which The claim that QM RNGs produce qualitatively different entropy than dozens of existing, deployed hardware RNGs. > there are better proven solutions, or in any other way deserves to be > dismissed? (OK, the headline is a bit over the top - but that's not the > fault of the researchers) -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
FY;) Stick Figure Guide to AES
Not new, but some probably have missed it. http://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
[Cryptography] [cryptography] OT: RSA's Pwnie Award
- Forwarded message from Jeffrey Walton - From: Jeffrey Walton Date: Mon, 8 Aug 2011 20:00:56 -0400 To: Randombit List Subject: [cryptography] OT: RSA's Pwnie Award Reply-To: noloa...@gmail.com, Crypto discussion list In case anyone is interested, RSA won a Pwnie for lamest vendor response for its RSA SecurID token compromise: http://pwnies.com/winners/ ___ cryptography mailing list cryptogra...@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] crypto breakage in SALT
Comments? https://github.com/saltstack/salt/commit/5dd304276ba5745ec21fc1e6686a0b28da29e6fc ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Email and IM are ideal candidates for mix networks
On Mon, Aug 26, 2013 at 02:44:32PM -0400, Perry E. Metzger wrote: > > My main issue with this proposal is that somebody identifiable is > > going to manufacture these boxes. Maybe several somebodies, but > > IMO, that's an identifiable central point of control/failure. Recently there's a trend for at least somewhat open hardware (Raspberry Pi, other ARM systems, Parallella Epiphany) some of which contain enough FPGA real estate (sure, we know there are FPGA backdoors, but) so that you could boot up an open core soft CPU, and even bootstrap your own toolchain from scratch. > One can use a commercial PC if one wants to install on one's own, or > any one of many manufacturers of small boxes. It is certainly the case In principle an FPGA die is regular, and hence more easily inspectable, but even SoCs can be sampled by reverse-engineering them from the metal layers. > that the hardware layer can be attacked, all is lost. On the other > hand, if we presume supply chain attacks, all is lost anyway -- once > you control the computer, the protocols it is running don't matter. > Even keyboards can be suborned -- see Gaurav Shah's work on that, for > example. We need open, fully inspectable systems. If proving code, or at least, auto-generating code from state machines catches on in open source the number of exploitable vulnerabilities can be greatly diminished. > I would prefer not to try to solve that problem right now -- it is > too broad and too general. If others can solve it, that's of course a > great thing. :) ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Keeping backups (was Re: Separating concerns
On Thu, Aug 29, 2013 at 01:30:35PM -0400, Perry E. Metzger wrote: > On Wed, 28 Aug 2013 20:04:34 +0200 Faré wrote: > > One thing that irks me, though, is the problem of the robust, secure > > terminal: if everything is encrypted, how does one survive the > > loss/theft/destruction of a computer or harddrive? > > So, as has been discussed, I envision people having small cheap > machines at home that act as their "cloud", and the system prompting > them to pick a friend to share encrypted backups with. This is precisely the use case for Freedombox running Tahoe LAFS. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN"
On Thu, Sep 05, 2013 at 04:11:57PM -0400, Phillip Hallam-Baker wrote: > If a person at Snowden's level in the NSA had any access to information Snowden didn't have clearance for that information. He's being described as 'brilliant' and purportedly was able to access documents far beyond his level by impersonating (using stolen/falsified secrets) higher level officials. Culling admins and adding the two-eyes rule will cripple the TLAs more than it will accomplish anything. We're still missing the information which cyphers are now legacy, and which are still considered useful. I keep seeing PFS being touted, but there is no evidence yet we can trust PFS to be yet unbroken though it appears plausible. Others are suggesting that public key encryption methods are suspect, while symmetric encryption has a better story. I'm personally becoming quite interested in a reliable way to produce secure one-time pads, using physical entropy sources which have been validated. It would be interesting to physically/securely exchanging large one-time pads in one's social network, and reaching farther recipients in a Retroshare-like (turtle router) model. It might be useful to combine one-time pads with symmetric encryption, automatically rekeying every large block of data for high-volume transfers (e.g. mesh routers) to stretch a one-time pad without completely losing its properties. The question is how large a block can be before it leaks enough information about the key. > that indicated the existence of any program which involved the successful > cryptanalysis of any cipher regarded as 'strong' by this community then the > Director of National Intelligence, the Director of the NSA and everyone > involved in those decisions should be fired immediately and lose their > pensions. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Bruce Schneier has gotten seriously spooked
On Fri, Sep 06, 2013 at 04:25:12PM -0400, Jerry Leichter wrote: > A response he wrote as part of a discussion at > http://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html: > > Q: "Could the NSA be intercepting downloads of open-source encryption > software and silently replacing these with their own versions?" > > A: (Schneier) Yes, I believe so. This is why I've been verifying Tor downloads using out of band fingerprints of signing key. Just because active attacks are more expensive than passive attacks and are fundamentally detectable, don't assume they're not being used in highly targeted cases. If you have ever been under telco surveillance, that's enough effort already spent to warrant slipping you some custom malware with no added bill of materials. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN"
On Fri, Sep 06, 2013 at 09:19:07PM -0400, Derrell Piper wrote: > ...and to add to all that, how about the fact that IPsec was dropped as a > 'must implement' from IPv6 sometime after 2002? Apropos IPsec, I've tried searching for any BTNS (opportunistic encryption mode for IPsec) implementations, and even the authors of the RFC are not aware of any. Obviously, having a working OE BTNS implementation in Linux/*BSD would be a very valuable thing, as an added, transparent protection layer against passive attacks. There are many IPsec old hands here, it is probably just a few man-days worth of work. It should be even possible to raise some funding for such a project. Any takers? signature.asc Description: Digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [liberationtech] Random number generation being influenced - rumors
- Forwarded message from Andy Isaacson - Date: Fri, 6 Sep 2013 22:24:00 -0700 From: Andy Isaacson To: liberationtech Subject: Re: [liberationtech] Random number generation being influenced - rumors User-Agent: Mutt/1.5.20 (2009-06-14) Reply-To: liberationtech On Sat, Sep 07, 2013 at 12:51:19AM +0300, Maxim Kammerer wrote: > On Fri, Sep 6, 2013 at 10:34 PM, Andy Isaacson wrote: > > This is not to say that RdRand is completely unusable. Putting RdRand > > entropy into a software pool implementation like /dev/urandom (or > > preferably, a higher-assurance multipool design like Fortuna) is a cheap > > way to prevent a putative backdoor from compromising your system state. > > Nearly nothing from what you wrote is relevant to RDRAND, which is not > a pure HWRNG, but implements CTR_DRBG with AES (unclear whether > 128/192/256) from NIST SP 800-90A [1,2]. That's the claimed design, yes. I see no particular reason to believe that the hardware in my server implements the design. I can't even test that the AES whitening does what it is documented to do, because Intel refused to provide access to the prewhitened input. Providing accessible "test points" (software interfaces to the innards of the implementation, with documentation of expected behavior between the components) would be the absolute minimum to provide believable assurance of the absence of a backdoor. Better would be documents from Intel of how the chip is designed at the mask level, and a third party mill-and-microphotograph of a retail chip showing that the shipped implementation matches the design. Intel will never go for that, of course, since their chip masks are their jealously guarded IP. Since they can't provide evidence of a lack of a backdoor, any reasonably cautious user should avoid depending on Intel's implementation. -andy -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [tor-talk] NIST approved crypto in Tor?
; ECRYPT and ECRYPT II produced some exceptionally worthwhile results; I hope that whoever makes funding decisions funds a nice targeted ECRYPT III some time. As I said on another mail, I've got a mind to move a lot of our crypto for other reasons, as well. The elephant in the room here is TLS itself. Frankly, I'm starting to think we should cut the Gordian Knot here and start a little independent protocol group of our own if the TLS working group can't get its act together and have one really good ciphersuite some time soon. > The NSA likes playing around. [2][3] (found while searching) > > Oh and I'm not trying fear-mongering here or try to conspire whenever or > not the NSA has subverted cryptographic functions (in one way or another). Yeah, I know how it is. I'm seeing conspiracies under every protocol and in every patch these days. Gotta stay focused, write the best protocols and designs and software I can, and maintain. (And with that in mind I should really start on my weekend soon.) peace, -- Nick -- tor-talk mailing list - tor-t...@lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [cryptography] Random number generation influenced, HW RNG
- Forwarded message from Thor Lancelot Simon - Date: Sat, 7 Sep 2013 15:36:33 -0400 From: Thor Lancelot Simon To: Eugen Leitl Cc: cryptogra...@randombit.net Subject: Re: [cryptography] Random number generation influenced, HW RNG User-Agent: Mutt/1.5.20 (2009-06-14) On Sat, Sep 07, 2013 at 09:05:33PM +0200, Eugen Leitl wrote: > > This pretty much rules out CPU-integral RNGs. It has to be > a third-party add-on (USB or PCIe), and it has to be open hardware. I think you take this more than a little too far. I see CPU-integral RNGs as very valuable source to be mixed with other sources in a software pool of entropy. Why should we reject them, unless we think the mixing functions themselves are useless? The lesson here seems to me to be that we should be far more assiduous in seeking out additional sources of entropy and in always ensuring software RNGs mix input from multiple such sources into all output. We should abandon sacred cows like the notion of information-theoretic randomness (that we don't actually know how to measure, but in pursuit of which we hamstring our software RNGs by arranging that they refuse to produce any output unless, by some questionable criterion, there is enough of it) and pursue engineering goals we can actually achieve, like mixing enough other-source input, of whatever quality, with the output of fast generators we can no longer trust that the adversary must actually attack the mixing function, rather than iteratively guessing the few state bits he does not already know. Secondarily -- and sadly! -- we must now be very suspicious of devices that integrate random number generation and encryption. Can we even trust raw hardware RNG output for the generation of IVs? I would argue not, because the same device's AES engine could be leaking key bits into our explicit IVs, etc, and we couldn't ever know. Devices that offload packet processing in its entirety (SSL accellerators, IPsec accellerators, etc.) have even more opportunity to do this sort of thing. Hardware crypto offload may still be very useful -- random number generation perhaps in particular -- but we will have to apply it with extreme care, and with a deliberate eye towards eliminating covert channels put in place by people at least as smart as we are, and with far more time and experience thinking about the problem from the offensive point of view. Finally, we have to accept that the game might just be over, period. So you use a pure software RNG, mixing in RdRand output or not as you may prefer. How hard do you think it is to identify the datastructures used by that RNG if you can execute code on a coprocessor with access to host RAM? Almost every modern server has such a coprocessor built in (its management processor) and you won't find the source code to its firmware floating around. Intel even puts this functionality directly on its CPUs (Intel AMT). Rather than beating up on the guy who put a lovely RNG instruction into every processor we're likely to use any time soon, it seems to me we ought to be beating up on ourselves for ignoring far simpler and more obvious risks like this one for well over a decade. Seriously, show of hands, who here has ever really put his or her foot down and insisted that a product they were purchasing _omit_ such functionality? Not chosen not to pay for it, refused to buy server X or mainboard Y simply on the basis that management processor functionality was onboard? Now, compare to the number of people complaining about backdoored RNGs here and elsewhere on the Internet. Go figure. To me the interesting question, but one to which I don't expect to ever know the answer, is whether the adversary -- having, we can assume, identified high value devices to systematically compromise, and lower value devices to defer for later or simply ignore entirely -- went at those devices sniper-style, or shotgun-style. Were a few key opportunities for tampering identified, and one or two attempted against each targeted device? Or were a wide variety of avenues explored, and every single one that seemed relevant attempted everywhere, or at least against certain particularly high value devices? If we knew that, in a way we might know, when we did finally see concrete evidence of a particular kind of tampering, how long to keep looking for more. But we aren't going to know that, no matter how much we might want to. Attacks on crypto hardware, attacks on management processors, attacks on supervisory or trusted execution modes seldom exercised in normal system operation, attacks on flash modules holding boot code, so that under the right circumstances they replace page P with evil page P', attacks on elements of IC vendors' standard cell libraries (DMA engines would seem promising); assume the adversaries are smart, and good at their jobs, and the sky would seem to be the limit. The sky will fall, of course, when va
Re: [Cryptography] Washington Post: Google racing to encrypt links between data centers
On Sat, Sep 07, 2013 at 01:53:13PM -0700, Tony Arcieri wrote: > On Fri, Sep 6, 2013 at 4:53 PM, Marcus D. Leech wrote: > > > One wonders why they weren't already using link encryption systems? > > > > Probably line rate and the cost of encrypting every single fiber link. > There are few vendors who sell line rate encryption for 10Gbps+ Nanog and denog had a discussion about this, and in general nobody believes the products you can buy, especially the export version, have no backdoor. Doing it in software is only feasible at network edge, not core. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Washington Post: Google racing to encrypt links between data centers
On Sat, Sep 07, 2013 at 04:41:04PM -0400, Richard Outerbridge wrote: > Surely not Canada? After all, we're one of the five eyes! ;) Six. Sweden (FRA) is part of it. http://www.heise.de/tp/blogs/8/154917 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [cryptography] Random number generation influenced, HW RNG
- Forwarded message from "James A. Donald" - Date: Sun, 08 Sep 2013 08:34:53 +1000 From: "James A. Donald" To: cryptogra...@randombit.net Subject: Re: [cryptography] Random number generation influenced, HW RNG User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 Reply-To: jam...@echeque.com On 2013-09-08 3:48 AM, David Johnston wrote: > Claiming the NSA colluded with intel to backdoor RdRand is also to > accuse me personally of having colluded with the NSA in producing a > subverted design. I did not. Well, since you personally did this, would you care to explain the very strange design decision to whiten the numbers on chip, and not provide direct access to the raw unwhitened output. A decision that even assuming the utmost virtue on the part of the designers, leaves open the possibility of malfunctions going undetected. That is a question a great many people have asked, and we have not received any answers. Access to the raw output would have made it possible to determine that the random numbers were in fact generated by the physical process described, since it is hard and would cost a lot of silicon to simulate the various subtle offwhite characteristics of a well described actual physical process. ___ cryptography mailing list cryptogra...@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [tor-talk] NIST approved crypto in Tor?
- Forwarded message from Gregory Maxwell - Date: Sun, 8 Sep 2013 06:44:57 -0700 From: Gregory Maxwell To: "This mailing list is for all discussion about theory, design, and development of Onion Routing." Subject: Re: [tor-talk] NIST approved crypto in Tor? Reply-To: tor-t...@lists.torproject.org On Sat, Sep 7, 2013 at 8:09 PM, Gregory Maxwell wrote: > On Sat, Sep 7, 2013 at 4:08 PM, anonymous coward > wrote: >> Bruce Schneier recommends *not* to use ECC. It is safe to assume he >> knows what he says. > > I believe Schneier was being careless there. The ECC parameter sets > commonly used on the internet (the NIST P-xxxr ones) were chosen using > a published deterministically randomized procedure. I think the > notion that these parameters could have been maliciously selected is a > remarkable claim which demands remarkable evidence. Okay, I need to eat my words here. I went to review the deterministic procedure because I wanted to see if I could repoduce the SECP256k1 curve we use in Bitcoin. They don't give a procedure for the Koblitz curves, but they have far less design freedom than the non-koblitz so I thought perhaps I'd stumble into it with the "most obvious" procedure. The deterministic procedure basically computes SHA1 on some seed and uses it to assign the parameters then checks the curve order, etc.. wash rinse repeat. Then I looked at the random seed values for the P-xxxr curves. For example, P-256r's seed is c49d360886e704936a6678e1139d26b7819f7e90. _No_ justification is given for that value. The stated purpose of the "veritably random" procedure "ensures that the parameters cannot be predetermined. The parameters are therefore extremely unlikely to be susceptible to future special-purpose attacks, and no trapdoors can have been placed in the parameters during their generation". Considering the stated purpose I would have expected the seed to be some small value like ... "6F" and for all smaller values to fail the test. Anything else would have suggested that they tested a large number of values, and thus the parameters could embody any undisclosed mathematical characteristic whos rareness is only bounded by how many times they could run sha1 and test. I now personally consider this to be smoking evidence that the parameters are cooked. Maybe they were only cooked in ways that make them stronger? Maybe SECG also makes a somewhat curious remark: "The elliptic curve domain parameters over (primes) supplied at each security level typically consist of examples of two different types of parameters — one type being parameters associated with a Koblitz curve and the other type being parameters chosen verifiably at random — although only verifiably random parameters are supplied at export strength and at extremely high strength." The fact that only "verifiably random" are given for export strength would seem to make more sense if you cynically read "verifiably random" as backdoored to all heck. (though it could be more innocently explained that the performance improvements of Koblitz wasn't so important there, and/or they considered those curves weak enough to not bother with the extra effort required to produce the Koblitz curves). -- tor-talk mailing list - tor-t...@lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] MITM source patching [was Schneier got spooked]
On Sat, Sep 07, 2013 at 07:42:33PM -1000, Tim Newsham wrote: > Jumping in to this a little late, but: > > > Q: "Could the NSA be intercepting downloads of open-source > > encryption software and silently replacing these with their own versions?" > > A: (Schneier) Yes, I believe so. > > perhaps, but they would risk being noticed. Some people check file hashes > when downloading code. FreeBSD's port system even does it for you and > I'm sure other package systems do, too. If this was going on en masse, There is a specific unit within NSA that attempts to obtain keys not in the key cache. Obviously, package-signing secrets are extremely valuable, since they're likely to work for hardened (or so they think) targets. For convenience reasons the signing secrets are typically not secured. If something is online you don't even need physical access to obtain it. The workaround for this is to build packages from source, especially if there's deterministic build available so that you can check whether the published binary for public consumption is kosher, and verify signatures with information obtained out of band. Checking key fingeprints on dead tree given in person is inconvenient, and does not give you complete trust, but it is much better than just blindly install something from online depositories. > it would get picked up pretty quickly... If targeted, on the other hand, it > would work well enough... signature.asc Description: Digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Opening Discussion: Speculation on "BULLRUN"
Forwarded with permission. So there *is* a BTNS implementation, after all. Albeit only for OpenBSD -- but this means FreeBSD is next, and Linux to follow. - Forwarded message from Andreas Davour - Date: Sun, 8 Sep 2013 09:10:44 -0700 (PDT) From: Andreas Davour To: Eugen Leitl Subject: [Cryptography] Opening Discussion: Speculation on "BULLRUN" X-Mailer: YahooMailWebService/0.8.156.576 Reply-To: Andreas Davour > Apropos IPsec, I've tried searching for any BTNS (opportunistic encryption > mode for > IPsec) implementations, and even the authors of the RFC are not aware of any. > Obviously, having a working OE BTNS implementation in Linux/*BSD would be a > very valuable thing, as an added, transparent protection layer against > passive attacks. There are many IPsec old hands here, it is probably just a > few man-days > worth of work. It should be even possible to raise some funding for such a > project. Any takers? Hi. I saw this message in the archive, and have not figured out how to reply to that one. But I felt this knowledge needed to be spread. Maybe you can post it to the list? My friend "MC" have in fact implemented BTNS! Check this out: http://hack.org/mc/projects/btns/ I think I can speak for him and say that he would love to have that implementation be known to the others on the list, and would love others to add to his work, so we can get real network security without those spooks spoiling things. /andreas -- "My son has spoken the truth, and he has sacrificed more than either the president of the United States or Peter King have ever in their political careers or their American lives. So how they choose to characterize him really doesn't carry that much weight with me." -- Edward Snowden's Father - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 signature.asc Description: Digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] very little is missing for working BTNS in Openswan
Just got word from an Openswan developer: " To my knowledge, we never finished implementing the BTNS mode. It wouldn't be hard to do --- it's mostly just conditionally commenting out code. " There's obviously a large potential deployment base for BTNS for home users, just think of Openswan/OpenWRT. signature.asc Description: Digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] IETF: Security and Pervasive Monitoring
http://www.ietf.org/blog/2013/09/security-and-pervasive-monitoring/ Security and Pervasive Monitoring The Internet community and the IETF care deeply about how much we can trust commonly used Internet services and the protocols that these services use. So the reports about large-scale monitoring of Internet traffic and users disturbs us greatly. We knew of interception of targeted individuals and other monitoring activities, but the scale of recently reported monitoring is surprising. Such scale was not envisaged during the design of many Internet protocols, but we are considering the consequence of these kinds of attacks. Of course, it is hard to know for sure from current reports what attack techniques may be in use. As such, it is not so easy to comment on the specifics from an IETF perspective. Still, the IETF has some long standing general principles that we can talk about, and we can also talk about some of the actions we are taking. In 1996, RFC 1984 articulated the view that encryption is an important tool to protect privacy of communications, and that as such it should be encouraged and available to all. In 2002, we decided that IETF standard protocols must include appropriate strong security mechanisms, and established this doctrine as a best current practice, documented in RFC 3365. Earlier, in 2000 the IETF decided not to consider requirements for wiretapping when creating and maintaining IETF standards, for reasons stated in RFC 2804. Note that IETF participants exist with positions at all points of the privacy/surveillance continuum, as seen in the discussions that lead to RFC 2804. As privacy has become increasingly important, the Internet Architecture Board (IAB) developed guidance for handling privacy considerations in protocol specifications, and documented that in RFC 6973. And there are ongoing developments in security and privacy happening within the IETF all the time, for example work has just started on version 1.3 of the Transport Layer Security (TLS, RFC 5246) protocol which aims to provide better confidentiality during the early phases of the cryptographic handshake that underlies much secure Internet traffic. Recent days have also seen an extended and welcome discussion triggered by calls for the IETF to build better protections against wide-spread monitoring. As that discussion makes clear, IETF participants want to build secure and deployable systems for all Internet users. Indeed, addressing security and new vulnerabilities has been a topic in the IETF for as long as the organisation has existed. Technology alone is, however, not the only factor. Operational practices, laws, and other similar factors also matter. First of all, existing IETF security technologies, if used more widely, can definitely help. But technical issues outside the IETF’s control, for example endpoint security, or the properties of specific products or implementations also affect the end result in major ways. So at the end of the day, no amount of communication security helps you if you do not trust the party you are communicating with or the devices you are using. Nonetheless, we’re confident the IETF can and will do more to make our protocols work more securely and offer better privacy features that can be used by implementations of all kinds. So with the understanding of limitations of technology-only solutions, the IETF is continuing its mission to improve security in the Internet. The recent revelations provide additional motivation for doing this, as well as highlighting the need to consider new threat models. We should seize this opportunity to take a hard look at what we can do better. Again, it is important to understand the limitations of technology alone. But here are some examples of things that are already ongoing: We’re having a discussion as part of the development of HTTP/2.0 as to how to make more and better use of TLS, for example to perhaps enable clients to require the use of security and not just have to react to the HTTP or HTTPS URLs chosen by servers. We’re having discussions as to how to handle the potentially new threat model demonstrated by the recent revelations so that future protocol designs can take into account potential pervasive monitoring as a known threat model. We’re considering ways in which better use can be made of existing protocol features, for example, better guidance as to how to deploy TLS with Perfect Forward Secrecy, which makes applications running over TLS more robust if server private keys later leak out. We’re constantly updating specifications to deprecate older, weaker cryptographic algorithms and allocate code points for currently strong algorithm choices so those can be used with Internet protocols. And we are confident that discussions on this topic will motivate IETF participants to do more work on these and further related topics. But don’t think about all this just in terms of the recent revelations. The security and priv
