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

2013-09-17 Thread Sandy Harris
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

2013-09-14 Thread Sandy Harris
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

2013-09-10 Thread Sandy Harris
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

2013-08-26 Thread Sandy Harris
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:
http://learn.adafruit.com/onion-pi/overview

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

2010-07-25 Thread Sandy Harris
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?

2010-07-09 Thread Sandy Harris
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
still worry about other things. Use your own protocol or crypto
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

2009-11-17 Thread Sandy Harris
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
  read capability.

  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

2009-11-11 Thread Sandy Harris
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
overheads.

What about this construction:

  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
so you need not worry much about overheads here.

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

2009-11-08 Thread Sandy Harris
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

2009-06-07 Thread Sandy Harris
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}?)

2009-05-10 Thread Sandy Harris
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!

2009-05-03 Thread Sandy Harris
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

2009-04-30 Thread Sandy Harris
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

2009-04-30 Thread Sandy Harris
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.

2008-12-16 Thread Sandy Harris
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

2008-11-19 Thread Sandy Harris
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

2008-10-27 Thread Sandy Harris
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.
I'd use addition, which costs about the same as XOR
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

2008-04-24 Thread Sandy Harris
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
overheads are the same.

-- 
Sandy Harris,
Nanjing, China

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


Re: Cruising the stacks and finding stuff

2008-04-22 Thread Sandy Harris
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

2008-02-01 Thread Sandy Harris
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

2008-01-14 Thread Sandy Harris
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
   answer is no, and what that answer means.

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
have access to any such technology are even less trustworthy.

-- 
Sandy Harris,
Nanjing, China

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


Re: Password vs data entropy

2007-10-27 Thread Sandy Harris
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
million years instead.

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

2007-06-26 Thread Sandy Harris

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
address is dynamically assigned:

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
in dynamic address space.

--
Sandy Harris
Quanzhou, Fujian, China

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


Re: ad hoc IPsec or similiar

2007-06-22 Thread Sandy Harris

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

2007-02-26 Thread Sandy Harris

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.

Paper is likely somewhere under his home page.
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

2007-02-07 Thread Sandy Harris

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
that start with q it is very low indeed.

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)

2006-03-23 Thread Sandy Harris
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

2004-12-09 Thread Sandy Harris
Lee Parkes wrote:
Hi,
I'm working on a project for a company that involves the use of 3DES. They have
asked me to find out what the overheads are ...
 

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

2004-09-11 Thread Sandy Harris
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
anyone they choose. However, that was never the design intent of
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?

2004-06-24 Thread Sandy Harris
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?

2004-06-23 Thread Sandy Harris
Hadmut Danisch wrote:
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)

2003-09-27 Thread Sandy Harris
Adam Back wrote:

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

2003-06-22 Thread Sandy Harris
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
properties of payload, ...).
There's some discussion and links in the FreeS/WAN
docs:
http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/ipsec.html#encnoauth


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