[Cryptography] funding Tor development

2013-10-14 Thread Eugen Leitl

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: [Cryptography] prism-proof email in the degenerate case

2013-10-11 Thread Eugen Leitl
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

2013-10-11 Thread Eugen Leitl
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


Re: [Cryptography] [cryptography] Asynchronous forward secrecy encryption

2013-09-28 Thread Eugen Leitl
- Forwarded message from zooko zo...@zooko.com -

Date: Fri, 27 Sep 2013 00:08:32 +0400
From: zooko zo...@zooko.com
To: Michael Rogers mich...@briarproject.org
Cc: Randombit List cryptogra...@randombit.net
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 a href=http://leitl.org;leitl/a 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] Gilmore response to NSA mathematician's make rules for NSA appeal

2013-09-25 Thread Eugen Leitl
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


[Cryptography] Stealthy Dopant-Level Hardware Trojans

2013-09-13 Thread Eugen Leitl

http://people.umass.edu/gbecker/BeckerChes13.pdf

Stealthy Dopant-Level Hardware Trojans ?

Georg T. Becker1

, Francesco Regazzoni2

, Christof Paar1,3 , and Wayne P. Burleson1

1University of Massachusetts Amherst, USA

2TU Delft, The Netherlands and ALaRI - University of Lugano, Switzerland

3Horst ortz Institut for IT-Security, Ruhr-Universiat Bochum, Germany

Abstract. 

In recent years, hardware Trojans have drawn the attention of governments and
industry as well as the scientific community. One of the main concerns is
that integrated circuits, e.g., for military or critical infrastructure
applications, could be maliciously manipulated during the manufacturing
process, which often takes place abroad. However, since there have been no
reported hardware Trojans in practice yet, little is known about how such a
Trojan would look like, and how dicult it would be in practice to implement
one.

In this paper we propose an extremely stealthy approach for implementing
hardware Trojans below the gate level, and we evaluate their impact on the
security of the target device. Instead of adding additional circuitry to the
target design, we insert our hardware Trojans by changing the dopant polarity
of existing transistors. Since the modified circuit appears legitimate on all
wiring layers (including all metal and polysilicon), our family of Trojans is
resistant to most detection techniques, including fine-grain optical
inspection and checking against golden chips.  We demonstrate the
ectiveness of our approach by inserting Trojans into two designs | a digital
post-processing derived from Intel's cryptographically secure RNG design used
in the Ivy Bridge processors and a side-channel resistant SBox implementation
and by exploring their detectability and their ects on security.

Keywords: Hardware Trojans, malicious hardware, layout modifications, Trojan
side-channel


signature.asc
Description: Digital signature
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] Radioactive random numbers

2013-09-13 Thread Eugen Leitl
On Thu, Sep 12, 2013 at 08:47:16AM +1000, Dave Horsfall wrote:
 Another whacky idea...
 
 Given that there is One True Source of randomness to wit radioactive 

What makes you think that e.g. breakdown oin a reverse biased
Zener diode is any less true random? Or thermal noise in a
crappy CMOS circuit?

In fact, 
http://en.wikipedia.org/wiki/Hardware_random_number_generator#Physical_phenomena_with_quantum-random_properties
listens a lot of potential sources, some with a higher
rate and more private than others.

 emission, has anyone considered playing with old smoke detectors?
 
 The ionising types are being phased out in favour of optical (at least in 
 Australia) so there must be heaps of them lying around.
 
 I know - legislative requirements, HAZMAT etc, but it ought to make for a 
 good thought experiment.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] Perfection versus Forward Secrecy

2013-09-13 Thread Eugen Leitl
On Thu, Sep 12, 2013 at 09:33:34AM -0700, Tony Arcieri wrote:

 What's really bothered me about the phrase perfect forward secrecy is
 it's being applied to public key algorithms we know will be broken as soon
 as a large quantum computer has been built (in e.g. a decade or two).

I do not think that the spooks are too far away from open research in
QC hardware. It does not seem likely that we'll be getting real QC
any time soon, if ever.

The paranoid nuclear option remains: one time pads. There is obviously
a continuum for XORing with output very large state PRNGs and
XORing with one time pads. It should be possible to build families
of such which resist reverse-engineering the state. While
juggling around several MByte or GByte keys is inconvenient, some
applications are well worth it.

Why e.g. SWIFT is not running on one time pads is beyond me.

 Meanwhile people seem to think that it's some sort of technique that will
 render messages unbreakable forever.


signature.asc
Description: Digital signature
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] Introducing strangers. Was: Thoughts about keys

2013-09-13 Thread Eugen Leitl
On Wed, Sep 11, 2013 at 07:32:04PM +0200, Guido Witmond wrote:

  With a FOAF routing scheme with just 3 degrees of separation there
  are not that many strangers left.
 
 How do you meet people outside your circle of friends?

You don't. The message is routed through the social network, until
it reaches your destination.
 
 How do you stay anonymous? With FOAF, you have a single identity for it

By running onion routers like Tor on top of that routed network.
With FOAF I don't mean a specific system, but a generic small-world
social network, where each member is reachable in a small number
of hops.

 to work. I offer people many different identities. But all of them are
 protected, and all communication encrypted.
 
 That's what my protocol addresses. To introduce new people to one
 another, securely. You might not know the person but you are sure that
 your private message is encrypted and can only be read by that person.
 
 Of course, as it's a stranger, you don't trust them with your secrets.
 
 For example, to let people from this mailing list send encrypted mail to
 each other, without worrying about the keys. The protocol has already
 taken care of that. No fingerprint checking. No web of trust validation.
 
 
  If you add opportunistic encryption at a low transport layer, plus
  additional layers on top of you've protected the bulk of traffic.
 
 I don't just want to encrypt the bulk, I want to encrypt everything, all

With multilayer transport protection, you'll get multiple layers
of encryption for your typical connection.

 the time. It makes Tor traffic much more hidden.
 
 
 There is more
 
 The local CA (one for each website) signs both the server and client
 certificates. The client only identifies itself to the server after it
 has recognized the server certificate. This blocks phishing attempts to
 web sites (only a small TOFU risk remains). And that can be mitigated
 with a proper dose of Certificate Transparency.
 
 Kind regards, Guido Witmond,
 
 
 Please see the site for more details:
   http://eccentric-authentication.org/


signature.asc
Description: Digital signature
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] Thoughts about keys

2013-09-11 Thread Eugen Leitl
On Tue, Sep 10, 2013 at 09:01:49PM +0200, Guido Witmond wrote:

 My scheme does the opposite. It allows *total strangers* to exchange
 keys securely over the internet.

With a FOAF routing scheme with just 3 degrees of separation
there are not that many strangers left.

If you add opportunistic encryption at a low transport
layer, plus additional layers on top of you've protected
the bulk of traffic.


signature.asc
Description: Digital signature
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

[Cryptography] SPDZ, a practical protocol for Multi-Party Computation

2013-09-11 Thread Eugen Leitl

http://www.mathbulletin.com/research/Breakthrough_in_cryptography_could_result_in_more_secure_computing.asp

Breakthrough in cryptography could result in more secure computing
(9/10/2013)

Tags: computer science, research, security, cryptography

Nigel Smart, Professor of Cryptology 

New research to be presented at the 18th European Symposium on Research in
Computer Security (ESORICS 2013) this week could result in a sea change in
how to secure computations.

The collaborative work between the University of Bristol and Aarhus
University (Denmark) will be presented by Bristol PhD student Peter Scholl
from the Department of Computer Science.

The paper, entitled 'Practical covertly secure MPC for dishonest majority -
or: Breaking the SPDZ limits', builds upon earlier joint work between Bristol
and Aarhus and fills in the missing pieces of the jigsaw from the groups
prior work that was presented at the CRYPTO conference in Santa Barbara last
year.

The SPDZ protocol (pronounced Speedz) is a co-development between Bristol
and Aarhus and provides the fastest protocol known to implement a theoretical
idea called Multi-Party Computation.

The idea behind Multi-Party Computation is that it should enable two or more
people to compute any function of their choosing on their secret inputs,
without revealing their inputs to either party. One example is an election,
voters want their vote to be counted but they do not want their vote made
public.

The protocol developed by the universities turns Multi-Party Computation from
a theoretical tool into a practical reality. Using the SPDZ protocol the team
can now compute complex functions in a secure manner, enabling possible
applications in the finance, drugs and chemical industries where computation
often needs to be performed on secret data.

Nigel Smart, Professor of Cryptology in the University of Bristol's
Department of Computer Science and leader on the project, said: We have
demonstrated our protocol to various groups and organisations across the
world, and everyone is impressed by how fast we can actually perform secure
computations.

Only a few years ago such a theoretical idea becoming reality was considered
Alice in Wonderland style over ambitious hope. However, we in Bristol
realised around five years ago that a number of advances in different areas
would enable the pipe dream to be achieved. It is great that we have been
able to demonstrate our foresight was correct.

The University of Bristol is now starting to consider commercialising the
protocol via a company Dyadic Security Limited, co-founded by Professor Smart
and Professor Yehuda Lindell from Bar-Ilan University in Israel.

Note: This story has been adapted from a news release issued by the
University of Bristol


signature.asc
Description: Digital signature
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

[Cryptography] NIST reopens RNG public comment period

2013-09-11 Thread Eugen Leitl

http://csrc.nist.gov/publications/PubsDrafts.html

Sep. 9, 2013

SP 800-90 A Rev 1 B and C

DRAFT Draft SP 800-90 Series: Random Bit Generators 
800-90 A Rev. 1: Recommendation for Random Number Generation Using 
Deterministic Random Bit Generators 
800-90 B: Recommendation for the Entropy Sources Used for Random Bit Generation 
800-90 C: Recommendation for Random Bit Generator (RBG) Constructions

In light of recent reports, NIST is reopening the public comment period for 
Special Publication 800-90A and draft Special Publications 800-90B and 800-90C.
NIST is interested in public review and comment to ensure that the 
recommendations are accurate and provide the strongest cryptographic 
recommendations possible.
The public comments will close on November 6, 2013. Comments should be sent to 
rbg_comme...@nist.gov. 
 
In addition, the Computer Security Division has released a supplemental ITL 
Security Bulletin titled NIST Opens Draft Special Publication 800-90A, 
Recommendation for Random Number Generation Using Deterministic Random Bit 
Generators, For Review and Comment (Supplemental ITL Bulletin for September 
2013) to support the draft revision effort.

Draft SP 800-90 A Rev. 1 (721 KB) 
Draft SP 800-90 B (800 KB) 
Draft SP 800-90 C (1.1 MB)


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

2013-09-09 Thread Eugen Leitl

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

2013-09-09 Thread Eugen Leitl

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 

[Cryptography] SSH uses secp256/384r1 which has the same parameters as what's in SEC2 which are the same the parameters as specified in SP800-90 for Dual EC DRBG!

2013-09-09 Thread Eugen Leitl

Forwarded without permission, hence anonymized:


Hey, I had a look at SEC2 and the TLS/SSH RFCs. SSH uses secp256/384r1
which has the same parameters as what's in SEC2 which are the same the
parameters as specified in SP800-90 for Dual EC DRBG!
TLS specifies you can use those two curves as well...
 Surely that's not coincidence..




signature.asc
Description: Digital signature
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

[Cryptography] Scott Aaaronson: NSA: Possibly breaking US laws, but still bound by laws of computational complexity

2013-09-09 Thread Eugen Leitl

http://www.scottaaronson.com/blog/?p=1517

NSA: Possibly breaking US laws, but still bound by laws of computational
complexity

Last week, I got an email from a journalist with the following inquiry.  The
recent Snowden revelations, which made public for the first time the US
government’s “black budget,” contained the following enigmatic line from the
Director of National Intelligence: “We are investing in groundbreaking
cryptanalytic capabilities to defeat adversarial cryptography and exploit
internet traffic.”  So, the journalist wanted to know, what could these
“groundbreaking” capabilities be?  And in particular, was it possible that
the NSA was buying quantum computers from D-Wave, and using them to run
Shor’s algorithm to break the RSA cryptosystem?

I replied that, yes, that’s “possible,” but only in the same sense that it’s
“possible” that the NSA is using the Easter Bunny for the same purpose.  (For
one thing, D-Wave themselves have said repeatedly that they have no interest
in Shor’s algorithm or factoring.  Admittedly, I guess that’s what D-Wave
would say, were they making deals with NSA on the sly!  But it’s also what
the Easter Bunny would say.)  More generally, I said that if the open
scientific world’s understanding is anywhere close to correct, then quantum
computing might someday become a practical threat to cryptographic security,
but it isn’t one yet.

That, of course, raised the extremely interesting question of what
“groundbreaking capabilities” the Director of National Intelligence was
referring to.  I said my personal guess was that, with ~99% probability, he
meant various implementation vulnerabilities and side-channel attacks—the
sort of thing that we know has compromised deployed cryptosystems many times
in the past, but where it’s very easy to believe that the NSA is ahead of the
open world.  With ~1% probability, I guessed, the NSA made some sort of big
improvement in classical algorithms for factoring, discrete log, or other
number-theoretic problems.  (I would’ve guessed even less than 1% probability
for the latter, before the recent breakthrough by Joux solving discrete log
in fields of small characteristic in quasipolynomial time.)

Then, on Thursday, a big New York Times article appeared, based on 50,000 or
so documents that Snowden leaked to the Guardian and that still aren’t
public.  (See also an important Guardian piece by security expert Bruce
Schneier, and accompanying QA.)  While a lot remains vague, there might be
more public information right now about current NSA cryptanalytic
capabilities than there’s ever been.

So, how did my uninformed, armchair guesses fare?  It’s only halfway into the
NYT article that we start getting some hints:

The files show that the agency is still stymied by some encryption, as Mr.
Snowden suggested in a question-and-answer session on The Guardian’s Web site
in June.

“Properly implemented strong crypto systems are one of the few things that
you can rely on,” he said, though cautioning that the N.S.A. often bypasses
the encryption altogether by targeting the computers at one end or the other
and grabbing text before it is encrypted or after it is decrypted…

Because strong encryption can be so effective, classified N.S.A. documents
make clear, the agency’s success depends on working with Internet companies —
by getting their voluntary collaboration, forcing their cooperation with
court orders or surreptitiously stealing their encryption keys or altering
their software or hardware…

Simultaneously, the N.S.A. has been deliberately weakening the international
encryption standards adopted by developers. One goal in the agency’s 2013
budget request was to “influence policies, standards and specifications for
commercial public key technologies,” the most common encryption method.

Cryptographers have long suspected that the agency planted vulnerabilities in
a standard adopted in 2006 by the National Institute of Standards and
Technology and later by the International Organization for Standardization,
which has 163 countries as members.

Classified N.S.A. memos appear to confirm that the fatal weakness, discovered
by two Microsoft cryptographers in 2007, was engineered by the agency. The
N.S.A. wrote the standard and aggressively pushed it on the international
group, privately calling the effort “a challenge in finesse.”

So, in pointing to implementation vulnerabilities as the most likely
possibility for an NSA “breakthrough,” I might have actually erred a bit too
far on the side of technological interestingness.  It seems that a large part
of what the NSA has been doing has simply been strong-arming Internet
companies and standards bodies into giving it backdoors.  To put it bluntly:
sure, if it wants to, the NSA can probably read your email.  But that isn’t
mathematical cryptography’s fault—any more than it would be mathematical
crypto’s fault if goons broke into your house and carted away your laptop.
On the contrary, 

Re: [Cryptography] [cryptography] Random number generation influenced, HW RNG

2013-09-08 Thread Eugen Leitl
- Forwarded message from James A. Donald jam...@echeque.com -

Date: Sun, 08 Sep 2013 08:34:53 +1000
From: James A. Donald jam...@echeque.com
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 a href=http://leitl.org;leitl/a 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?

2013-09-08 Thread Eugen Leitl
- Forwarded message from Gregory Maxwell gmaxw...@gmail.com -

Date: Sun, 8 Sep 2013 06:44:57 -0700
From: Gregory Maxwell gmaxw...@gmail.com
To: This mailing list is for all discussion about theory, design, and 
development of Onion Routing.
tor-t...@lists.torproject.org
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 gmaxw...@gmail.com wrote:
 On Sat, Sep 7, 2013 at 4:08 PM, anonymous coward
 anonymous.cow...@posteo.de 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 a href=http://leitl.org;leitl/a 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]

2013-09-08 Thread Eugen Leitl
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

2013-09-08 Thread Eugen Leitl

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 ko...@yahoo.com -

Date: Sun, 8 Sep 2013 09:10:44 -0700 (PDT)
From: Andreas Davour ko...@yahoo.com
To: Eugen Leitl eu...@leitl.org
Subject: [Cryptography] Opening Discussion: Speculation on BULLRUN
X-Mailer: YahooMailWebService/0.8.156.576
Reply-To: Andreas Davour ko...@yahoo.com

 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 a href=http://leitl.org;leitl/a 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] Opening Discussion: Speculation on BULLRUN

2013-09-07 Thread Eugen Leitl
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

2013-09-07 Thread Eugen Leitl
- Forwarded message from Andy Isaacson a...@hexapodia.org -

Date: Fri, 6 Sep 2013 22:24:00 -0700
From: Andy Isaacson a...@hexapodia.org
To: liberationtech liberationt...@lists.stanford.edu
Subject: Re: [liberationtech] Random number generation being influenced - rumors
User-Agent: Mutt/1.5.20 (2009-06-14)
Reply-To: liberationtech liberationt...@lists.stanford.edu

On Sat, Sep 07, 2013 at 12:51:19AM +0300, Maxim Kammerer wrote:
 On Fri, Sep 6, 2013 at 10:34 PM, Andy Isaacson a...@hexapodia.org 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 a href=http://leitl.org;leitl/a 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?

2013-09-07 Thread Eugen Leitl
 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 a href=http://leitl.org;leitl/a 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

2013-09-07 Thread Eugen Leitl
- Forwarded message from Thor Lancelot Simon t...@panix.com -

Date: Sat, 7 Sep 2013 15:36:33 -0400
From: Thor Lancelot Simon t...@panix.com
To: Eugen Leitl eu...@leitl.org
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 various nation

Re: [Cryptography] Washington Post: Google racing to encrypt links between data centers

2013-09-07 Thread Eugen Leitl
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 mle...@ripnet.com 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

2013-09-07 Thread Eugen Leitl
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] Opening Discussion: Speculation on BULLRUN

2013-09-06 Thread Eugen Leitl
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

2013-09-06 Thread Eugen Leitl
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] Keeping backups (was Re: Separating concerns

2013-08-30 Thread Eugen Leitl
On Thu, Aug 29, 2013 at 01:30:35PM -0400, Perry E. Metzger wrote:
 On Wed, 28 Aug 2013 20:04:34 +0200 Faré fah...@gmail.com 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] Email and IM are ideal candidates for mix networks

2013-08-26 Thread Eugen Leitl
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


[Cryptography] crypto breakage in SALT

2013-07-04 Thread Eugen Leitl

Comments?

https://github.com/saltstack/salt/commit/5dd304276ba5745ec21fc1e6686a0b28da29e6fc
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


[Cryptography] [cryptography] OT: RSA's Pwnie Award

2011-08-09 Thread Eugen Leitl
- Forwarded message from Jeffrey Walton noloa...@gmail.com -

From: Jeffrey Walton noloa...@gmail.com
Date: Mon, 8 Aug 2011 20:00:56 -0400
To: Randombit List cryptogra...@randombit.net
Subject: [cryptography] OT: RSA's Pwnie Award
Reply-To: noloa...@gmail.com,
Crypto discussion list cryptogra...@randombit.net

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 a href=http://leitl.org;leitl/a 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


FY;) Stick Figure Guide to AES

2010-10-06 Thread Eugen Leitl

Not new, but some probably have missed it. 

http://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html 

-- 
Eugen* Leitl a href=http://leitl.org;leitl/a 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


[tt] Random numbers created out of nothing

2010-09-30 Thread Eugen Leitl

Right from the snake-oil-security-dept.

- Forwarded message from Arlind Boshnjaku arlindboshnj...@yahoo.com -

From: Arlind Boshnjaku arlindboshnj...@yahoo.com
Date: Thu, 30 Sep 2010 14:48:44 +0200
To: transhumanist news t...@postbiota.org
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 a href=http://leitl.org;leitl/a 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

2010-09-27 Thread Eugen Leitl

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 main 

Re: GSM eavesdropping

2010-08-03 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a 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

2010-07-09 Thread Eugen Leitl

http://www.technologyreview.com/printer_friendly_article.aspx?id=25670channel=Briefingssection=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: Quantum Key Distribution: the bad idea that won't die...

2010-04-22 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a 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

2010-03-25 Thread Eugen Leitl

From: coderman coder...@gmail.com
Date: Wed, 24 Mar 2010 10:50:33 -0700
To: Morlock Elloi morlockel...@yahoo.com
Cc: cypherpu...@al-qaeda.net
Subject: Re: [vserver] Bought an entropykey - very happy

On Wed, Mar 24, 2010 at 8:43 AM, Morlock Elloi morlockel...@yahoo.com
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 a href=http://leitl.org;leitl/a 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

2010-03-16 Thread Eugen Leitl

From: basile bas...@opensource.dyc.edu
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 a href=http://leitl.org;leitl/a 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: AES-CBC + Elephant diffuser

2009-11-01 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a 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


AES-CBC + Elephant diffuser

2009-10-29 Thread Eugen Leitl

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-8b0034c92555DisplayLang=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


Old Trick Threatens the Newest Weapons

2009-10-27 Thread Eugen Leitl

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 

Serpent close to AES speed thanks to SSE2

2009-09-10 Thread Eugen Leitl

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


Re: [btns] IETF75

2009-06-25 Thread Eugen Leitl

I can has contributions, please?

From: Michael Richardson m...@sandelman.ottawa.on.ca
Subject: Re: [btns] IETF75 
To: Eugen Leitl eu...@leitl.org
cc: b...@ietf.org
Date: Wed, 24 Jun 2009 15:03:33 -0400


 Eugen == Eugen Leitl eu...@leitl.org 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 a href=http://leitl.org;leitl/a 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


Tellitec Tellinet Sat Spy manual leaked

2009-06-05 Thread Eugen Leitl

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


[tahoe-dev] SHA-1 broken! (was: Request for hash-dependency in Tahoe security.)

2009-04-30 Thread Eugen Leitl
 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 a href=http://leitl.org;leitl/a 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

2009-04-30 Thread Eugen Leitl

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 keeping with the 

Re: [Opensim-dev] Technical assessment of Cable Beach asset server

2009-01-17 Thread Eugen Leitl
From: Toni Alatalo ant...@kyperjokki.fi
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 a href=http://leitl.org;leitl/a 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


Quantum direct communication: secrecy without key distribution

2008-12-05 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a 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

2008-10-24 Thread Eugen Leitl

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]


Re: road toll transponder hacked

2008-08-28 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a 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

2008-08-28 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a 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: [Beowulf] Re: hobbyists

2008-06-21 Thread Eugen Leitl
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.htmlhl=enie=UTF8sl=frtl=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 a href=http://leitl.org;leitl/a 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

2007-06-22 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a 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

2007-06-22 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a 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

2007-06-21 Thread Eugen Leitl

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 a href=http://leitl.org;leitl/a 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]


C7, Jetway, performance

2007-04-30 Thread Eugen Leitl

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 a href=http://leitl.org;leitl/a 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]


[EMAIL PROTECTED]: Re: FIPS 140-2 Validation Revoked]

2006-07-20 Thread Eugen Leitl
- 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 a href=http://leitl.org;leitl/a 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]

2006-07-20 Thread Eugen Leitl
. (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 a href=http://leitl.org;leitl/a 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]

2006-01-13 Thread Eugen Leitl
- 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 a href=http://leitl.org;leitl/a 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]

2006-01-03 Thread Eugen Leitl
- 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 grabstore 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 a href=http://leitl.org;leitl/a 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]

2006-01-03 Thread Eugen Leitl
- 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 something 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 a href=http://leitl.org;leitl/a 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

2005-12-16 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a 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: [p2p-hackers] P2P Authentication]

2005-10-31 Thread Eugen Leitl
- 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 a href=http://leitl.org;leitl/a
__
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

2005-10-19 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a
__
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]

2005-10-07 Thread Eugen Leitl
- 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 a href=http://leitl.org;leitl/a
__
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)]]

2005-09-20 Thread Eugen Leitl
- Forwarded message from David Farber [EMAIL PROTECTED] -

From: David Farber [EMAIL PROTECTED]
Date: Mon, 19 Sep 2005 20:30:36 -0400
To: Ip Ip ip@v2.listbox.com
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 a href=http://leitl.org;leitl/a
__
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

2005-09-17 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a
__
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?

2005-09-13 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a
__
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?

2005-09-12 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a
__
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?

2005-09-11 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a
__
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?

2005-09-10 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a
__
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

2005-06-09 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a
__
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] Intel quietly embeds DRM in it's 945 chips firmware]

2005-05-31 Thread Eugen Leitl
- Forwarded message from David Farber [EMAIL PROTECTED] -

From: David Farber [EMAIL PROTECTED]
Date: Tue, 31 May 2005 08:17:59 -0400
To: Ip ip ip@v2.listbox.com
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 a href=http://leitl.org;leitl/a
__
ICBM: 48.07100, 11.36820http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE


signature.asc
Description: Digital signature


DTV Content Protection (fwd from cripto@ecn.org)

2005-05-20 Thread Eugen Leitl
 degree of protection.

--

-- 
Eugen* Leitl a href=http://leitl.org;leitl/a
__
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


ocf-linux-20050315 - Asynchronous Crypto support for linux (fwd from [EMAIL PROTECTED])

2005-03-15 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a
__
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


Re: Dell to Add Security Chip to PCs

2005-02-04 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a
__
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


[i2p] Tunnel cryptography for I2P 0.5 (corrected typo) (fwd from [EMAIL PROTECTED])

2005-01-26 Thread Eugen Leitl
 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 a href=http://leitl.org;leitl/a
__
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


[PadLock] PadLock patches for linux kernel 2.6.10 (fwd from [EMAIL PROTECTED])

2005-01-07 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a
__
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


OCF port to linux (fwd from [EMAIL PROTECTED])

2004-11-18 Thread Eugen Leitl

--

-- 
Eugen* Leitl a href=http://leitl.org;leitl/a
__
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


Re: VIA PadLock reloaded (fwd from [EMAIL PROTECTED])

2004-10-25 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a
__
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])

2004-10-25 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a
__
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


pci hardware for secure crypto storage (OpenSSL/OpenBSD)

2004-09-14 Thread Eugen Leitl

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 a href=http://leitl.org;leitl/a
__
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: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from hal@finney.org) (fwd from touch@ISI.EDU)

2004-09-11 Thread Eugen Leitl
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 -




___



___


--

-- 
Eugen* Leitl a href=http://leitl.org;leitl/a
__
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


pgphSDUxjY0Or.pgp

[wearables] CFP: Workshop on Pervasive Computing and Communication Security (fwd from [EMAIL PROTECTED])

2004-09-06 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a
__
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: EZ Pass and the fast lane ....

2004-07-12 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a
__
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


Interview with Glenn Henry, founder of VIA processor subsidiary Centaur (fwd from [EMAIL PROTECTED])

2004-06-16 Thread Eugen Leitl
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 encrypted, because half the
PCs these days have some, I don't know what the right word is, some spy
built into it, through a virus or worm, that can steal data and pass it back.
You'll

Re: Article on passwords in Wired News

2004-06-03 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a
__
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


Re: The future of security

2004-06-01 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a
__
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: The future of security

2004-05-31 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a
__
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

2004-05-28 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a
__
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

2004-05-28 Thread Eugen Leitl
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 a href=http://leitl.org;leitl/a
__
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


XML-proof UIDs

2003-11-16 Thread Eugen Leitl

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 a href=http://leitl.org;leitl/a
__
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