### Re: [Cryptography] The paranoid approach to crypto-plumbing

On Mon, Sep 16, 2013 at 12:44 PM, Bill Frantz fra...@pwpconsult.com wrote:

Symmetric encryption:

Two algorithms give security equal to the best of them. Three
protect against meet-in-the-middle attacks. Performing the
multiple encryption at the block level allows block cyphers to
be combined with stream cyphers. RC4 may have problems, but
adding it to the mix isn't very expensive.

A paper of mine on combining a stream cipher with a block
cipher: http://eprint.iacr.org/2008/473

AES-256 uses 14 rounds vs. 10 for AES-128, so it is about
40% slower. Given 256 bits of key and a stream cipher that
is 5x faster than AES, you can use AES-128 and have 128
bits to key the stream cipher. AES-128 plus whitening that
changes for every block (two 128-bit blocks of stream
cipher output) has roughly the same cost as AES-256.

There are several ways to reduce the cost and/or increase
the security from there; see the paper for details.

I am still working on this notion and will have a new and
much improved version of that paper sometime this year.
Anyone I know moderately well who wants to review it
can contact me off-list for the current draft.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

### Re: [Cryptography] real random numbers

Let me a try a different way of stating (what I think is) Denker's point.

From docs for my RNG, at:
ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/

Discussing Denker's Turbid, found at:
http://www.av8n.com/turbid/paper/turbid.htm

(Quoting)
The unique advantage of Turbid is that it provably delivers almost
perfectly random numbers. Most other generators – including mine,
random(4), and the others discussed in this section – estimate the
randomness of their inputs. Sensible ones attempt to measure the
entropy, and are very careful that their estimates are sufficiently
conservative. They then demonstrate that, provided that the estimate
is good, the output will be adequately random. This is a reasonable
approach, but hardly optimal.

Turbid does something quite different. It measures properties of the
sound device and uses arguments from physics to derive a lower bound
on the Johnson-Nyquist noise [3] which must exist in the circuit. From
that, and some mild assumptions about properties of the hash used, it
gets a provable lower bound on the output entropy. Parameters are
chosen to make that bound 159.something bits per 160-bit SHA context.
The documentation talks of “smashing it up against the asymptote”.
{End quote)

The difference is real and it seems quite clear that an RNG with a
provable bound is preferable to one where analysis must rely on
assumptions about or estimates of input entropy. For a rather large
subset of servers -- basically any that have an unused sound card
equivalent or can easily add one -- Turbid should be the first thing
considered for use as an RNG. It is open source, so auditable, and
uses hardware that appears unlikely to be subject to fiddling by
three-letter agencies of any government.

The basic design of RDRAND looks like it could be proven secure in
much the same way, but with the Snowden revelations   plus this paper
http://hardware.slashdot.org/story/13/09/13/1228216/stealthy-dopant-level-hardware-trojans
it becomes harder to trust.

All that said, I still want to use something like Linux random(4) with
a large pool and multiple entropy sources.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

### Re: [Cryptography] Thoughts on hardware randomness sources

On Tue, Sep 10, 2013 at 10:59 AM, Marcus D. Leech mle...@ripnet.com wrote:
I wonder what people's opinions are on things like the randomsound daemon
that is available for Linux.

I have not looked at that. A well thought out  well documented
RNG based on a sound card is:
http://www.av8n.com/turbid/paper/turbid.htm

I wrote a very simple one (perhaps not yet trustworthy because
it has not had much analysis) based on timer calls. Its documentation
discusses a few others:
ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

### Re: [Cryptography] Using Raspberry Pis

On Mon, Aug 26, 2013 at 4:12 PM, Phillip Hallam-Baker hal...@gmail.com wrote:
I really like RPis as a cryptographic tool. The only thing that would make
them better is a second Ethernet interface so they could be used as a
firewall type device.

Two things to look at. Onion Pi turns one into a WiFi hotspot  Tor input node:

Freedom Box is working on low-power home servers with goals
overlapping yours. They use a different machine as their
reference server, but it should work on Pi. There is some
discussion in their mailing list archive:
http://freedomboxfoundation.org/
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

### Re: Intel to also add RNG

On 7/13/10, Perry E. Metzger pe...@piermont.com wrote:

It is disturbing to me that people oppose this so much.

Yes. A hardware RNG seems an obvious Good Thing. Not
a complete solution, but a very useful component.

For a lot of applications -- servers run in isolation, networking
equipment, etc. -- having hardware RNGs available is a really big win,
because there is no good local source of randomness. (We had a long
discussion of ways to mitigate this some time ago.) Plugging in an
external unit is not going to happen in practice. If it isn't nearly
free and built in, it won't be used.

IPsec gateways and web servers doing a lot of SSL are obvious
cases. Neither has much mouse or keyboard activity, they may
have solid state drives or smart RAID so disk timings are not
random. Packet timings might be somewhat random, but they
may also be knowable by an enemy.

I would suggest that in most cases, you are better off with a very
very mildly untrusted but ubiquitous hardware RNG than with the kinds
of kludges to get random numbers on unattended hardware we end up with
in the real world.

In some cases, a non-kludge alternative is Turbid:
http://www.av8n.com/turbid/paper/turbid.htm
That uses a sound card or on-board equivalent. Some boards
will have this, or it is cheap  easy to stick in a slot.

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

### What is required for trust?

India recently forbade some Chinese companies from bidding on some
cell phone infrastructure projects, citing national security concerns:

http://www.chinatechnews.com/2010/05/25/12102-indias-bsnl-excludes-chinas-huawei-zte-from-gsm-bidding

Of course, the Chinese gov't and companies are by no means the only
ones one might worry about. ATT and other US telcos have given
customer data to the NSA. What about fear of NSA trickery in Lucent
products? Or French intelligence in Alcatel? Or Israeli or Taiwan or
whoever? In all cases, you can argue about how plausible such threats
are, but it seems clear they are not utterly implausible.

Nor are the companies the only threat. Cisco and many other firms have
factories in China; if you are worried about Huawei colluding with
government here to spy on or sabotage other nations, then you likely
have to worry about that government slipping a team into Cisco staff
to subvert those products. I don't think this threat is realistic, but
I could be wrong.

The main devices to worry about are big infrastructure pieces --
telephone switches, big routers and the like. However, those are by no
means the only potential targets. Small home routers and various
embedded systems are others.

So, if one is building some sort of hardware that people may be
reluctant to buy because of security concerns, what does it take to
reassure them? Obviously, this is going to vary with both the
application and the people involved, but can we say anything useful in
general?

Standard components help. If you use IPsec, or AES, or a commodity
processor, I can have some confidence in those parts, though I'll
algorithm and I definitely won't trust it without publication and a
lot of analysis. Put big lumps of your own VLSI on the board and I'll
worry about what might be hidden in them.

Openness helps. Put an open source OS on the thing and give me the
application code in source for auditing. If you must use some VLSI or
FPGA parts, publish source for those.

Auditing helps. Intel got outsiders to audit their random number
generator. This is probably needed for some critical components, but
which?

All of those help, but are they enough? If not, what else is needed?
Or is this an impossible task?

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

### Re: hedging our bets -- in case SHA-256 turns out to be insecure

On 11/12/09, David-Sarah Hopwood david-sa...@jacaranda.org wrote:
Sandy Harris wrote:
On 11/8/09, Zooko Wilcox-O'Hearn zo...@zooko.com wrote:

Therefore I've been thinking about how to make Tahoe-LAFS robust against
the possibility that SHA-256 will turn out to be insecure.

[...]

Since you are encrypting the files anyway, I wonder if you could
use one of the modes developed for IPsec where a single pass
with a block cipher gives both encrypted text and a hash-like
authentication output.  That gives you a free value to use as
H3 in my scheme or H2 in yours, and its security depends on
the block cipher, not on any hash.

Tahoe is intended to provide resistance to collision attacks by the
creator of an immutable file: the creator should not be able to generate
files with different contents, that can be read and verified by the same

An authenticated encryption mode won't provide that -- unless, perhaps,
it relies on a collision-resistant hash.

I was suggesting using the authentication data in the construction:

C(x) = H1(H2(x)||A(x))

where H1 is a hash with he required output size, H2 a hash with
a large block size and A the authentication data from your
encryption.

This is likely a very bad idea if you already use that data in some
other way, e.g. for authenticating stored data. However, if C is
going to be your authentication mechanism, then this might be
a cheap way to get one input to it.

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

### Re: hedging our bets -- in case SHA-256 turns out to be insecure

On 11/8/09, Zooko Wilcox-O'Hearn zo...@zooko.com wrote:

Therefore I've been thinking about how to make Tahoe-LAFS robust against
the possibility that SHA-256 will turn out to be insecure.

NIST are dealing with that via the AHS process. Shouldn't you just use
their results?

We could use a different hash function ...
There are fourteen candidates left in the SHA-3
contest at the moment.  Several of them have conservative designs and good
performance, but there is always the risk that they will be found to have
catastrophic design flaws or that a great advance in hash function
cryptanalysis will suddenly show how to crack them.

Yes, but there's also a risk that whatever you come up with will turn
out to be flawed.

I propose the following combined hash function C, built out of two hash
functions H1 and H2:

C(x) = H1(H1(x) || H2(x))

This requires two hash(x) operations. A naive implementation needs
two passes through the data and avoiding that does not appear to
be trivial. This is not ideal since you seem very concerned about

C(x) = H1(H2(x) || H3(x))

H1 is something that gives the output size you require. Use SHA-256 or
choose an AHS candidate conservatively. This only hashes a few blocks

H2 is the 512-bit variant of a different AHS candidate, or Whirlpool, or
even Skein-1024. Here speed is a criterion, though of course not the
only one.

H3 might be some really cheap fast function invented for the situation.
As I recall, the GOST hash just used a sum of input blocks, and that's
enough to defeat the multi-block attacks. If it is simple enough, you
can code it into your implementation of H2 so you only need one
pass.

Since you are encrypting the files anyway, I wonder if you could
use one of the modes developed for IPsec where a single pass
with a block cipher gives both encrypted text and a hash-like
authentication output.  That gives you a free value to use as
H3 in my scheme or H2 in yours, and its security depends on
the block cipher, not on any hash.

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

### Re: TLS man in the middle

On 11/6/09, mhey...@gmail.com mhey...@gmail.com wrote:
From http://www.ietf.org/mail-archive/web/tls/current/msg03928.html
and http://extendedsubset.com/?p=8

From what I gather, when TLS client certificates are used, an attacker
can post a command to a victim server and have it authenticated by a
legitimate client.

I'm in China and use SSL/TLS for quite a few things. Proxy connections,
Gmail set to always use https and so on. This is the main defense for
me and many others against the Great Firewall.

Should I be worrying about man-in-the-middle attacks from the Great
Firewall servers?

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

### Re: Factoring attack against RSA based on Pollard's Rho

On Mon, Jun 8, 2009 at 11:51 AM, Victor Duchovni
victor.ducho...@morganstanley.com wrote:
On Sun, Jun 07, 2009 at 05:41:00PM -0700, Greg Perry wrote:

The significance of this method is the ability to determine any
properties of p and q from a simple operation to n.

To be blunt, I see no significance of any kind...

You have observed that unless N is divisible by 3, p and q are both also
not divisible by 3. This is not new, and ...

I do not have it to hand, but at one point I had a solution for

N = pq = (a-b)(a+b) = a^2 - b^2

where I could find unique values for a^2 and b^2 mod 9, mod 16,
or by combining those mod 144. Mod 25, mod 49 et cetera gave
constraints but not unique solutions.

After playing with this a while,  I concluded that it was not
actually useful,

--
Sandy Harris,
Quanzhou, Fujian, China

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

### Fwd: 80-bit security? (Was: Re: SHA-1 collisions now at 2^{52}?)

On Fri, May 8, 2009 at 10:28 AM, Brandon Enright bmenr...@ucsd.edu wrote:

Steven M. Bellovin s...@cs.columbia.edu wrote:

On Thu, 30 Apr 2009 17:44:53 -0700
Jon Callas j...@callas.org wrote:

The accepted wisdom
on 80-bit security (which includes SHA-1, 1024-bit RSA and DSA keys,
and other things) is that it is to be retired by the end of 2010.

That's an interesting statement from a historical perspective -- is it
true?  And what does that say about our ability to predict the future,
and hence to make reasonable decisions on key length?

See, for example, the 1996 report on key lengths, by Blaze, Diffie,
Rivest, Schneier, Shimomura, Thompson, and Wiener, available at
http://www.schneier.com/paper-keylength.html -- was it right?

It was a best guess by a group of clever and well-informed people.
There's no way to tell if it was precisely right, but there's no way
to get a better estimate either, short of getting a similar group to
re-do the work today.

A back-of-the envelope approximation to today's requirements
can be had by saying Moore's Law gives twice the computer
speed every 18 months, so ciphers needs one more key bit
every 18months to keep up. They said minimum 75 bits to
keep an existing cipher in service, minimum 90 for any new
ones, as of 1996. Add 10 bits to each for a rough estimate
as of 2011.

Now, even assuming 64 bits is within reach of modern
computing power, ...

I'd have thought that was obvious, and had been for a
decade or so. EFF broke DES in a few days for
\$200,000 ten years ago. A 64-bit cipher is only
256 times harder, easily within reach on an
intelligence agency budget.

Copacobana break DES in a week for 9,000 euro.
256 of them would break a 64-bit cipher in a
week. This is within reach for a high-stakes
industrial espionage situation, say Boeing
and Airbus competing for big orders.

--
Sandy Harris,
Quanzhou, Fujian, China

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

### Re: [tahoe-dev] SHA-1 broken!

On Sat, May 2, 2009 at 12:33 PM, Perry E. Metzger pe...@piermont.com wrote:

As just one obvious example of a realistic threat, consider that there
are CAs that will happily sell you certificates that use SHA-1.

Various clever forgery attacks have been used against certs that use
MD5, see:

http://www.win.tue.nl/hashclash/rogue-ca/

Those attacks can now be extended to SHA-1 pretty easily. It might
require a bit of compute infrastructure -- say a lot of FPGAs and a
bunch of cleverness -- to turn out certs quickly, but it can be
done. Given that there are lots of high value certs out there of this
form, this is rather dangerous.

Off-the-shelf FPGA-based device that breaks DES by brute force in
about a week, costs 9,000 euros: http://www.copacobana.org/

These are commercially available and programmable. Setting a
few of them up to break SHA-1 certainly would not be trivial,
but it looks feasible.

--
Sandy Harris,
Quanzhou, Fujian, China

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

### Re: Destroying confidential information from database

On Mon, Mar 9, 2009 at 10:32 PM, Mads m...@lsitec.org.br wrote:

I know of procedures and programs to erase files securely from disks,
Guttman did a paper on that

Yes, but that paper is over ten years old. In the meanwhile, disk
designs and perhaps encoding schemes have changed, journaling
file systems have become much more common and, for all I
know the attack technology may have changed too.

Is there a more recent analysis or is Guttman still the
best reference?

--
Sandy Harris,
Quanzhou, Fujian, China

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

### Re: CSPRNG algorithms

On Sat, Mar 14, 2009 at 3:16 AM, Travis
travis+ml-cryptogra...@subspacefield.org wrote:
I have never seen a good catalog of computationally-strong
pseudo-random number generators.  It seems that everyone tries to roll
their own in whatever application they are using, and I bet there's a
lot of waste and inefficiency and re-inventing the wheel involved.

If this true, or is there a survey somewhere?  If not, would people
like to help me create one by emailing me references to extant PRNG
definitions?

Not complete, but this encyclopedia article has some links:
http://en.citizendium.org/wiki/Random_number#Random_sequences_from_physical_phenomena
It is a wiki so if you can improve it, please do.

No doubt Wikipedia has a list as well. All the usual
crypto texts have chapters on it, too.

--
Sandy Harris,
Quanzhou, Fujian, China

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

### Re: CPRNGs are still an issue.

Bill Frantz fra...@pwpconsult.com wrote:

Short of building special random number generation hardware, does
anyone have any suggestions for additional sources?

Any unused input device with noise can be used. Examples:
Soundcard: http://www.av8n.com/turbid/
Camera: http://www.lavarnd.org/

If anything in the system changes a lot, like processes starting
and stopping or files opening  closing, periodically hashing
the tables that describe that state is useful.

Is your threat model one-sided? e.g. for a home router, attacks
from the Internet side might be more of a worry than attacks
from the LAN. In that case, things like packet timing on the
LAN side are unknown to the feared attacker. Also, if you are
doing NAT, the port numbers on the LAN side since those are
not sent outside.

If the device does any crypto, mixing ciphertext into the pool
is nowhere near ideal since you would not be encrypting
unless some enemy might get the text and using things an
an enemy can get is exactly what you do not want here.
However, it is cheap and random-looking, and the volume
is proportional to the amount of crypto done, so it might
help in some cases.

--
Sandy Harris,
Quanzhou, Fujian, China

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

### Hybrid cipher paper

A paper of mine just went up on http://eprint.iacr.org/  It has some ideas
that I hope are new, I think are good, and I know are unorthodox. I'm well
aware of the usual fate of such innovations, especially from amateurs.

If anyone would like a break from looking at new hashes, perhaps they
could have a look.

Number2008/473
Title  Exploring Cipherspace: Combining stream ciphers and block ciphers

Abstract:

This paper looks at the possibility of combining a block cipher and a stream
cipher to get a strong hybrid cipher. It includes two specific proposals for
combining AES-128 and RC4-128 to get a cipher that takes a 256-bit key
and is significantly faster than AES-256, and arguably more secure. One is
immune to algebraic attacks.

--
Sandy Harris,
Quanzhou, Fujian, China

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

### Re: combining entropy

John Denker [EMAIL PROTECTED] wrote:

To say the same thing in more detail:  Suppose we start
with N generators, each of which puts out a 160 bit word
containing 80 bits of _trusted_ entropy.  That's a 50%
entropy density.

So you need a 2:1 or heavier compression that won't lose
entropy. If you just need one 160 word out per N in, then
hashing them is the obvious way to do that.

We next consider the case where N-1 of the generators have
failed, or can no longer be trusted, ...

XOR is provably correct because it is _reversible_ in the
thermodynamic sense.  That means it cannot increase or
decrease the entropy.

Yes, but the proof holds for any reversible mapping. XOR
makes each output bit depend on exactly two inputs bits.
Sometimes you want a mapping that mixes them better.

If one input is entirely random, XOR is fine; random ^ x is
random for any x. It is also fine in the case above, where
only one generator works.

If   1 inputs have some entropy but none have enough,
which seems to me the commonest case, XOR is not
the best choice; it does not mix well enough.

Nyberg's perfect s-boxes are in some ways the ideal
mixer. 2n bits in, n out, all columns and all linear
combinations of columns are bent functions. Big
S-boxes are expensive though, and building even
small Nyberg S-boxes is going to take significant
effort. Designing something that uses a bunch of say
8 by 4 S-boxes to do good mixing on 160-bit chunks
is not trivial either.

You could use IDEA multiplication in mixing. Two 16-bit
words in, one out, and every output bit depends on all
input bits.

If every 16-bit input word has 50% entropy density
(not the same as every 160-bit word does, but perhaps
close enough) then the output should have 100%.

For N  1, you need to combine those and worry about
overall mixing. If entropy density is known to be ~50%,
you can combine pairs with IDEA to get ~100%, then
use cheaper operations for any other mixing needed.
but gives slightly better mixing because of carries.

For N  2 and density  50%, you could use a cascade
of IDEA operations 8-4-2-1 or whatever. Or do
something like: combine two 160-bit chunks with 10
IDEA multiplications, circular shift the result 8 bits,
combine with next 160-bit input, ...

At some point, you may find yourself designing a hash.
If that happens, just give up and use a standard hash.

--
Sandy Harris,
Quanzhou, Fujian, China

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

### Re: Cruising the stacks and finding stuff

Jack Lloyd [EMAIL PROTECTED] wrote:

Making a cipher that uses an N bit key but is only secure to 2^M
operations with MN is, firstly, considered broken in many circles, as
well as being inefficient (why generate/transmit/store 512 bit keys
when it only provides the security of a ~300 bit (or whatever) key
used with a perfect algorithm aka ideal cipher - why not use the
better cipher and save the bits).

Saving bits may not matter, or may not be possible. For example,
if you are ealing with a hybrid system -- say, using RSA to transmit
the symmetric cipher key or Diffie-Hellamn to construct it -- then for
any symmetric cipher key size less than the public key size, your

--
Sandy Harris,
Nanjing, China

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

### Re: Cruising the stacks and finding stuff

Perry E. Metzger [EMAIL PROTECTED] wrote:

Now, it is entirely possible that someone will come up with a much
smarter attack against AES than brute force. I'm just speaking of how
bad brute force is. The fact that brute force is so bad is why people
go for better attacks, and even the A5/1 attackers do not use brute
force.

I'd suggest that Allen should be a bit more careful when doing back of
the envelope calculations...

Another back-of-the-envelope estimate would be to look at the EFF
machine that could brute force s 56-bit DES key in a few days and
cost \$200-odd thousand. That was 10 years ago and Moore's Law
applies, so it should be about 100 times faster or cheaper now.

Round numbers are nice. Overestimating the attacker a bit is
better than underestimating. So assume an attacker can brute
force a a 64-bit key (256 times harder than DES) in a second
(a few 100 thousand times faster).

Brute force against a 96-bit key should take 2^32 times as long.
Since pi seconds is a nano-century, that's somewhat over a
century. For a 128-bit key, over 2^32 centuries. If brute force
is the best attack, this is obviously secure.

--
Sandy Harris,
Nanjing, China

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

### Re: Gutmann Soundwave Therapy

What I don't understand is why you think tinc is necessary,
or even worth the trouble.

IPsec is readily available -- built into Windows, Mac OS
and various routers, and with implementations for Linux
and all the *BSDs -- has had quite a bit of expert
security analysis, and handles VPNs just fine.

Does tinc do something that IPsec cannot?

--
Sandy Harris,
Nanjing, China

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

### Re: Death of antivirus software imminent

On Jan 12, 2008 9:32 AM, Alex Alten [EMAIL PROTECTED] wrote:

Generally any standard encrypted protocols will probably eventually have
to support some sort of CALEA capability. ...

That's a rather large and distinctly dangerous assumption. Here's the
IETF's official line on the question, the abstract section of RFC 2084:

The Internet Engineering Task Force (IETF) has been asked to take a
position on the inclusion into IETF standards-track documents of
functionality designed to facilitate wiretapping.

This memo explains what the IETF thinks the question means, why its

http://www.faqs.org/rfcs/rfc2804.html

The whole question was extensively discussed on an IETF mailing
list set up for the purpose before that RFC was written:
http://www1.ietf.org/mail-archive/web/raven/current/index.html

The aptly named RFC 1984 is also relevant.

Among the more obvious problems are the fact that complexity
is bad for security, that the US government has some history
of abusing wiretaps, and that other governments who would

--
Sandy Harris,
Nanjing, China

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

### Re: Password vs data entropy

On 10/26/07, Alex Pankratov [EMAIL PROTECTED] wrote:

Or, rephrasing, what should the entropy of the password be
compared to the entropy of the value being protected (under
whatever keying/encryption scheme) ?

The entropy of the data is irrelevant. The question is its
value; that affects both the resources an attacker might
use to get it and the cost to you if it is lost.

If there is no attack on the crypto algorithm better than brute
force (a huge if!, but there are available algorithms for which
we can at least say no such attack has been published) and
you can estimate attacker's resources, then you can estimate
key size required for safety.

Te EFF's DES cracker (many custom-built chips in parallel)
broke 56-bit DES in a few days. Assume our brute force
enemy can search a 64-bit space (256 times larger) in a
second (a few million times faster). Then searching a
96-bit space takes him 2**32 seconds, well over a century.
For a 128-bit space, multiply that by another 2**32, so
something over 400 billion years.

You really don't care about minor variation here, e.g.if our
estimates are off by a million and he can do it in 400

So, if your crypto is sound,128 bits should theorectically
be enough for any data and any human time scale.

Practice and theory can differ, though, and you cannot
be utterly certain there's not some unpublished attack
that does awful things to the crypto. I'd use 256 bits
and a well-analyzed algorithm.

--
Sandy Harris,
Nanjing, China

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

### Re: ad hoc IPsec or similiar

On 6/23/07, Eugen Leitl [EMAIL PROTECTED] wrote:

The general idea is that if you use keys in DNS to authenticate gateways

Aye, that's the rub. Most hosts are in dynamic address space,
and anything involving DNS will not fly.

It is certainly a problem, but you can get around it partially even if your IP

http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/quickstart.html#opp.client

You do need to use a dynamic DNS server to handle your keys, but there
are lots of those, and many do provide that service.

Also, this is limited to initiate-only IPsec; it does not handle incoming
connections. However, that may be enough for many client machines that live

--
Sandy Harris
Quanzhou, Fujian, China

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

### Re: ad hoc IPsec or similiar

On 6/22/07, Eugen Leitl [EMAIL PROTECTED] wrote:

So what's the state in ad hoc IPsec/VPN setup for any end points?

The Linux FreeS/WAN project was working on opportunistic encryption.

The general idea is that if you use keys in DNS to authenticate gateways
and IPsec for secure tunnels then any two machines can communicate
securely without their administrators needing to talk to each other or to
set up specific pre-arranged tunnels.

http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/glossary.html#carpediem
http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/quickstart.html

There is an RFC based on that work:
ftp://ftp.rfc-editor.org/in-notes/rfc4322.txt

The FreeS/WAN project has ended. I do no know if the follow-on projects,
openswan.org and strongswan.org, support OE.

--
Sandy Harris
Quanzhou, Fujian, China

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

### Re: Entropy of other languages

Travis H. [EMAIL PROTECTED] wrote:

On Wed, Feb 07, 2007 at 05:42:49AM -0800, Sandy Harris wrote:
He starts from information theory and an assumption that
there needs to be some constant upper bound on the
receiver's per-symbol processing time. From there, with
nothing else, he gets to a proof that the optimal frequency
distribution of symbols is always some member of a
parameterized set of curves.

Do you remember how he got from the upper bound on processing time
to anything other than a completely uniform distribution of symbols?

No. There was some pretty heavy math in the paper. With it in my hand,
I understood enough to follow the argument. 20 years later with no paper
to hand, I haven't a clue.

http://www.math.yale.edu/mandelbrot/

Seems to me a flat distribution has the minimal upper bound on
information content per symbol for a given amount of information!

Probably, but he did have a proof that the skewed distribution is
more efficient in some ways.

--
Sandy Harris
Quanzhou, Fujian, China

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

### Re: Entropy of other languages

Allen [EMAIL PROTECTED] wrote:

An idle question. English has a relatively low entropy as a
language. Don't recall the exact figure, but if you look at words

What about other languages? Does anyone know the relative entropy
of other alphabetic languages? What about the entropy of
ideographic languages? Pictographic? Hieroglyphic?

The most general answer is in a very old paper of Mandelbrot's.
Sorry, I don't recall the exact reference or have it to hand.

He starts from information theory and an assumption that
there needs to be some constant upper bound on the
receiver's per-symbol processing time. From there, with
nothing else, he gets to a proof that the optimal frequency
distribution of symbols is always some member of a
parameterized set of curves.

Pick the right parameters and Mandelbrot's equation
simplifies to Zipf's Law, the well-known rule about
word, letter or sound frequencies in linguistics.
I'm not sure if you can also get Pareto's Law which
covers income  wealth distributions in economics.

--
Sandy Harris
Quanzhou, Fujian, China

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

### Re: Entropy Definition (was Re: passphrases with more than 160 bits of entropy)

Aram Perez [EMAIL PROTECTED] wrote:

So, if you folks care to educate me, I have several questions related
to entropy and information security (apologies to any physicists):

I'll answer the easier questions. I'll leave the harder ones for someone
with a better grounding in information theory.

* What is the relationship between randomness and entropy?

Roughly, they both measure unpredictability. Something that is hard
to predict is random, or has high entropy. There are mathematical
formulations that make this a lot more precise, but that's the basic
idea.

* Does processing an 8 character password with a process similar to
PKCS#5 increase the entropy of the password?

Absolutely not!

At best, you preserve the original entropy, just distributing it
differently. If you get the processing wrong, you can reduce or
even entirely destroy it, but no amount of any kind of processing
can increase it.

* Can you add or increase entropy?

You can add more entropy, either from another source or more
from the same source. That is the only way to increase it.

--
Sandy Harris
Zhuhai, Guangdong, China

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

### Re: 3DES performance

Lee Parkes wrote:
Hi,
I'm working on a project for a company that involves the use of 3DES. They have

Some info at:
http://www.freeswan.org/freeswan_trees/freeswan-2.06/doc/performance.html
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

### Re: potential new IETF WG on anonymous IPSec

Zooko O'Whielcronx wrote:
On 2004, Sep 09, , at 16:57, Hal Finney wrote:
... an extension to IPsec to allow for unauthenticated
connections.  Presently IPsec relies on either pre-shared secrets or a
trusted third party CA to authenticate the connection.
No. It can also use RSA public keys without embedding them in
certificates or requiring a CA, let alone a 3rd party one.
The new proposal
would let connections go forward using a straight Diffie-Hellman type
exchange without authentication.

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.

Sounds right to me, though unauthenticeted might be
more precise.
I believe that in the context of e-mail [1, 2, 3, 4] and FreeSWAN this
is called opportunistic encryption.
That is certainly not what FreeS/WAN meant by opportunistic encryption.
http://www.freeswan.org/freeswan_trees/freeswan-1.99/doc/glossary.html#carpediem
OE does authenticate all connections. The trick is that the public keys
are stored in DNS so you do not have to exchange keys with the admin of
a site before you can do secure communications to it.
For this to be secure, you need DNSsec widely deployed. In effect you
are using DNS as a PKI. Without DNSsec, this reduces to something
fairly anonymous -- anyone who can lie in DNS can pretend to be
OE. If you want anonymous connections, there are easier ways.

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

### Re: cryptograph(y|er) jokes?

bear wrote:
Bob and Alice routinely discuss bombs, terrorism, tax cheating, sexual
infidelity, and deviant sex over the internet.  They conspire to commit
crimes, share banned texts and suppressed news, or topple tyrannical
governments whose agents eavesdrop on their every communication.  They
do all this with utmost secrecy and unbreakable codes.
However, Alice and Bob do not even trust each other.
A protocol designer then, is someone who does not think that Alice
and Bob are insane.
For the original, see:
http://www.conceptlabs.co.uk/alicebob.html
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

### Re: cryptograph(y|er) jokes?

does anyone know good jokes about
cryptography, cryptographers, or security?
There's always the sys admin's mantra:
I know I'm paranoid, but I worry about whether
I'm paranoid enough.
FreeS/WAN docs have links to several collections
of crypto quotes, many funny:
http://www.freeswan.org/freeswan_trees/freeswan-2.06/doc/web.html#quotes
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

### Re: efficiency?? vs security with symmetric crypto? (Re: Tinc's response to Linux's answer to MS-PPTP)

What conceivable trade-offs could you have to make to get acceptable
performance out of symmetric crypto encrypted+authenticated tunnel?
All ciphers you should be using are like 50MB/sec on a 1Ghz machine!!
There's fairly detailed performance data for Linux FreeS/WAN IPsec
http://www.freeswan.org/freeswan_trees/freeswan-2.02/doc/performance.html
It's around 50 M bit/second on a GHz machine with 3DES. You can
roughly double that with AES.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

### Re: authentication and ESP

John S. Denker wrote:
On 06/19/2003 01:49 PM, martin f krafft wrote:
As far as I can tell, IPsec's ESP has the functionality of
authentication and integrity built in:
It depends on what you mean by built in.
1) The RFC provides for ESP+authentication but
does not require ESP to use authentication.
2) Although the RFC allows ESP without
authentication, typical implementations are
less flexible.  In FreeS/WAN for instance, if
you ask for ESP will get ESP+AH.
ESP without authentication may be vulnerable to
replay attacks and/or active attacks that tamper
with the bits in transit.  The degree of vulnerability
depends on details (type of chaining, higher-level