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

2005-12-04 Thread R. A. Hettinga
At 2:29 PM -0800 12/3/05, John Gilmore wrote:
 ...how many people on this list use or have used online banking?
 To start the ball rolling, I have not and won't.

Dan, that makes two of us.

The only thing I ever use it for is to make sure the wires are in before I
spend money. :-)

Cheers,
RAH
Still living at the bottom of the bathtub curve...
-- 
-
R. A. Hettinga mailto: [EMAIL PROTECTED]
The Internet Bearer Underwriting Corporation http://www.ibuc.com/
44 Farquhar Street, Boston, MA 02131 USA
... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

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


Re: Proving the randomness of a random number generator?

2005-12-04 Thread Travis H.
On 12/3/05, Victor Duchovni [EMAIL PROTECTED] wrote:
 Actually, this is inaccurate, proving the strength of AES or factoring is
 difficult, and may never happen, we may even prove AES to be not secure
 (in a broad sense) some day. Proving an RNG secure is *impossible*.

I'm not sure it's impossible, but you certainly have to restrict the
scope from unconditional security, which is an impossibility anyway.
 By analogy, an attacker may have encrypted some plaintext with your
key and gotten your ciphertext before.

Here is a reasonable security model:
An attacker has access to all outputs of this PRNG x_0 .. x_n and
nothing else of relevance.
Can he guess x_(n+1) with probability greater than chance?

Even if you allow the attacker to have seen the sequence before, using
assumptions such as the bounded storage model may prevent him from
completely compromising the PRNG:
http://www.crypto.ethz.ch/research/itc/samba/

Part of the problem is that we just don't know what the attacker has
access to, and that the implicit goal (prove that there is no
algorithm for predicting x_(n+1) better than y) is a universal, akin
to cipher design's goal of proving that there is no algorithm for
decrypting ciphertext without the key that is more efficient than y.

There are other possible goals; one might want an observer to be
unable to distinguish it from a stream of numbers drawn from a uniform
distribution, that re-seeding recover from state compromise, that the
smallest program which generates the output x_0..n be of length O(n),
that predicting the next output implies being able to solve a hard
problem.  There are some examples of the latter, for example the
blum-blum shub (BBS) generator:
http://en.wikipedia.org/wiki/Blum_Blum_Shub

I believe that it has been proven that if one-way functions exist,
then secure PRNGs exist.  If I am not mistaken, lack of one-way
functions would prevent effective encryption.  After all, conventional
encryption is just a one-way permutation based on a secret input k. 
It is not even necessary that *trapdoor* one-way functions exist,
which is a common assumption in public-key systems.

For more information, see Pseudorandomness and Cryptographic
Applications, ISBN 0-691-02546-0, by Michael Luby.  Warning:
theory-intensive.
--
http://www.lightconsulting.com/~travis/  -- Knight of the Lambda Calculus
We already have enough fast, insecure systems. -- Schneier  Ferguson
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B

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


RNG implementations and their problems

2005-12-04 Thread Travis H.
I'm dissatisfied with the state of /dev/random devices on Unix.  Here
are my gripes:

So far I haven't seen any userland tools for updating the entropy count.

This is unfortunate, because sometimes I generate entropy on one machine
and want to pipe it into the /dev/random pool.

However, I cannot update entropy counts without writing programs that can
do ioctl (meaning C or C++).  This is no good.  Can't we make writes to
/dev/random take some kind of structured form that's easy to do from a
shell script so that we don't have to use ioctls?  Failing that, could
we have a userland tool that can make the requisite ioctls?

The entropy harvesting and estimation code is bound too tightly to the
entropy pool.

It is in kernelspace so cannot do floating point, like measuring
chi-square or Shannon entropy to estimate the amount of randomness.

Reading from /dev/urandom empties the entropy pool immediately; this is
unfriendly to people who need real random numbers.

In Linux, writing to /dev/random and /dev/urandom is absolutely
identical; the data gets mixed in, but the entropy count isn't updated.
The random_write_wakeup_thresh is almost worthless as any woken processes
will probably not be able to update the entropy count, unless they are
specially coded for this purpose.

The write interface isn't exploited thoroughly enough.  If writes to
/dev/random were to block when the entropy pool is full, and writes
to /dev/urandom never blocks. then it greatly simplifies the design of
userland programs that harvest entropy from sources of non-zero cost;
they merely write(2) to /dev/random, and if it doesn't need any more
entropy, then it simply blocks until more is needed.  This way it doesn't
have to pool the entropy pool using ioctl(2).

If we change the semantics, they should be queryable in some way,
because currently the source code or experimentation is the only way of
discerning them.  Getting good randomness shouldn't be platform-specific,
and shouldn't fail in silent or unsafe ways at runtime.

I may take some action to remedy this situation if I am not overlooking
something simple.
--
http://www.lightconsulting.com/~travis/  -- Knight of the Lambda Calculus
We already have enough fast, insecure systems. -- Schneier  Ferguson
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B

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


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

2005-12-04 Thread mis
dan, maybe you should just keep less money in the bank.

i use online banking and financial services of almost every kind
(except bill presentment, because i like paper bills).  i ccannot do
without it.

it seems to me the question is how much liability do i expose myself to by
doing this, in return for what savings and convenience.  

i don't keep a lot of money in banks (why would anyone?)  -- most of
the assets are in (e.g.)  brokerage accounts.  at most  i'm exposing
a month of payroll check to an attacker briefly until it pays some
bill or is transferred to another asset account.  

(the lack of payment planning tools is my biggest beef with bill
paying systems... it's so stupid that they don't show you the future
running balances based on already arranged scheduled payments and
regular withdrawals).

i have an slightly too elaborate drip-feed system set up, with direct
deposit of the paycheck into an account which pays (as scheduled
payments) my fixed bills automatically every month and makes minimum
credit card payments too, so i don't often pay nuisance fees.  (my
utilities have been switched to average payment plans, or more
recently to bill to credit cards so they fit into this plan).

i haven't written more than a few paper checks in years.  i just add the
payee to the online system and have the bank do it.  the online system
has paid around 200 bills so far this year. 

so i save on time, on postage, on the float (since the banks do ach
transfers to the larger payees which often post in 2-3 days), on
nuisance and finance charges, and on the phone, complaining about
problems posting paper checks.

i would notice a fraudulent transfer on my online backing long before
i would notice a fraudulent paper check written against the same account.

not only do i use online banking, i use aggregation systems which scrape
screens for most of my accounts and display recent transactions,
current balances, etc.  

i think i've tried almost all of these.
fidelity's full view seems among the best of the group (they 
use
yodlee for the scraping but manage their own password store).
(while dan is surveying, i'll ask if anyone is using gnucash 
for this).

i find this extremely helpful in managing diversification across
several accounts, and in noticing such details such as both sides of
payments or transfers between institutions or charges on infrequently
used credit card accounts.

an interesting question regarding aggregation was whether i should let
them use the information they scraped to decide what to offer me.  (so
far they haven't offered me a free toaster to entice me to move assets
to them.  according to an informant, they don't use the information
for poaching.)

On Fri, Dec 02, 2005 at 11:05:29PM -0500, [EMAIL PROTECTED] wrote:
 
 You know, I'd wonder how many people on this
 list use or have used online banking.  
 
 To start the ball rolling, I have not and won't.
 
 --dan
 
 
 Cryptography is nothing more than a mathematical framework for
 discussing the implications of various paranoid delusions.
 -- Don Alvarez 
 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

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


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

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

I do.

My bank provides an RSA SecureId, so I feel reasonably safe against
anyone other than the bank.  I have no basis for knowing how good the
bank's precautions against insider fraud are, but they phone back to
confirm unusual instructions, and they ask for only fragments of
passwords when they do, so there is evidence that they make sensible
efforts to do the right thing.

I have been a good customer for more than 30 years, it's a highly
respectable specialist bank, I am a lawyer, and if I find a fake
transaction on my account I believe I stand a good chance of fighting
it.  I know who to hire as an expert to investigate the bank's system
when I have put it in issue in litigation.  The aggregate of my balance
and my credit limit is an amount I can afford to lose.

In this context the convenience of online banking is enough to justify
the risk.

Nicholas Bohm
-- 
Salkyns, Great Canfield, Takeley,
Bishop's Stortford CM22 6SX, UK

Phone   01279 871272(+44 1279 871272)
Fax  020 7788 2198   (+44 20 7788 2198)
Mobile  07715 419728(+44 7715 419728)

PGP public key ID: 0x899DD7FF.  Fingerprint:
5248 1320 B42E 84FC 1E8B  A9E6 0912 AE66 899D D7FF


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


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

2005-12-04 Thread Ian G

[EMAIL PROTECTED] wrote:

You know, I'd wonder how many people on this
list use or have used online banking.  


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


I have not!  I declined the chance when my
bank told me that I had to download their
special client that only runs on windows...

However, I have used and/or written many
online DGC tools (which is for the sake of
this discussion, gold-denominated online
payments) which are honed through experience,
incentive and willingness to deal with the
issues.

( As an aside, e-gold was generally the first
to be hit by these problems as well as all the
other problems that have only effected banks
in passing.  Generally the DGC sector is much
more savvy about threats, through repetitive
losses, at least. )

iang

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


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

2005-12-04 Thread leichter_jerrold
| You know, I'd wonder how many people on this
| list use or have used online banking.  
| 
| To start the ball rolling, I have not and won't.
Until a couple of months ago, I avoided doing anything of this sort at all.
Simple reasoning:  If I know I never do any financial stuff on-line, I can
safely delete any message from a bank or other financial institution.

Now, I pay some large bills - mortgage, credit cards - on line.  I just got
tired of the ever-increasing penalties for being even a day late in paying -
coupled with ever-more-unpredictable post office delivery times.  (Then
again,
who can really say when the letter arrived at the credit card company?  You
have to accept their word for it, and they have every incentive to err in 
their own favor.)

I have consistently refused on-line delivery of statements, automated
paying, 
or anything of that sort.  I cannot at this point forsee a world in which I 
would trust these systems enough to willingly move in that direction.  (It
doesn't help that, for example, one credit-card site I use - ATT Universal
-
sends an invalid certificate.  ATT Universal has its own URL, but they
are 
owned by Citibank, so use the citibank.com certificate)

Of course, increasingly one has little choice.  My employer doesn't provide
an 
option:  Pay stubs are on-line only.  Reimbursment reports likewise.

There are increasing hints of various benefits if you use the on-line
systems for banking and credit cards and such.  The next step - it won't
be long - will be charges for using the old paper systems.  How many people 
here still ask for paper airline tickets?  (I gave up on this one)

-- Jerry


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


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

2005-12-04 Thread Joseph Ashwood
- Original Message - 
From: Sidney Markowitz [EMAIL PROTECTED]

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



Joseph Ashwood wrote:

  byte [] rawBytes = new byte[lenNum/8];
  rand.nextBytes(rawBytes);
  curNum = new BigInteger(rawBytes);



curNum = BigInteger.ONE.or(new BigInteger(512, rand));


Ok after making that change, and a few others. Selecting only odd numbers 
(which acts as a small seive) I'm not getting much useful information. It 
appears to be such that at 512 bits if it passes once it passes 128 times, 
and it appears to fail on average about 120-130 times, so the sieve 
amplifies the values more than expected. Granted this is only a test of the 
generation of 128 numbers, but I got 128 primes (based on 128 MR rounds). 
For the sake of full code review and duplication I've appended the entire 64 
lines of code. You'll see I made a few optimizations, and removed writing 
the data to a csv. I developed compiled and ran it only through Eclipse.'

   Joe




import java.math.BigInteger;
import java.security.SecureRandom;
import java.io.IOException;

public class millerMain {
static int numTests = 128;
static int lenNum = 512;
static SecureRandom rand = new SecureRandom();
static BigInteger two = BigInteger.valueOf(2);


public static void main(String[] args) throws IOException {
 BigInteger curNum = null;
 int totalPrimes = 0;
 int [] successes = new int[numTests];
 int failuresBetween = 0;
 for(int i = 0; i  numTests; i++)
 {
  failuresBetween = -1;
  //choose starting number
  do
  {
   curNum = BigInteger.ONE.or(new BigInteger(lenNum, rand));
   failuresBetween++;
  }
  while(testOnce(curNum) == false);
  System.out.println(Failed  + failuresBetween+  times);
  //passed once


  //run 127 more tests
  for(int j = 0; j  127; j++)
  {
   if(testOnce(curNum))
   {
successes[i]++;
   }
  }
  if(successes[i] == 127) totalPrimes++;
  System.out.println(Test Number +i+ successes +(successes[i]+1)+ 
Total Prime so far +totalPrimes);


  BigInteger temp = BigInteger.valueOf(successes[i]);
  String num = temp.toString();
 }
}


static boolean testOnce(BigInteger N){
 BigInteger A = null;

 // 0  A  N
 A = new BigInteger(lenNum, rand).mod(N);
 if(A.compareTo(BigInteger.ZERO) == 0) return testOnce(N);

 BigInteger Nminus1 = N.subtract(BigInteger.ONE);

 //shouldBeOne = A^(N-1) mod N
 BigInteger shouldBeOne = A.modPow(Nminus1, N);
 if(shouldBeOne.compareTo(BigInteger.ONE)!= 0) return false;
 return true;

}
}



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


[Clips] Call for IFCA Conference Sponsors, Financial Cryptography and Data Security '06

2005-12-04 Thread R. A. Hettinga
Um, what's Data Security?

;-)

Cheers,
RAH
---
--- begin forwarded text


 Delivered-To: [EMAIL PROTECTED]
 Date: Sun, 4 Dec 2005 19:10:25 -0500
 To: Philodox Clips List [EMAIL PROTECTED]
 From: R. A. Hettinga [EMAIL PROTECTED]
 Subject: [Clips]
  Call for IFCA Conference Sponsors, Financial Cryptography and
  Data Security '06
 Reply-To: [EMAIL PROTECTED]
 Sender: [EMAIL PROTECTED]


 --- begin forwarded text


  To: Robert Hettinga [EMAIL PROTECTED]
  From: Patrick McDaniel [EMAIL PROTECTED]
  Subject: Call for IFCA Conference Sponsors, Financial Cryptography and
 Data Security '06
  Date: Sun,  4 Dec 2005 18:52:19 -0500 (EST)

  Dear Robert,

  The Financial Cryptography and Data Security '06 is celebrating its
  10th year in Anguilla, British West Indies from February 27 to March
  2, 2006.  This conference has become a yearly touch-stone for those
  involved in the construction and use of technology in commercial
  environments.  To this end, the conference brings together top
  cryptographers, data-security specialists, and scientists with
  economists, bankers, implementers, and policy makers.

  Intimate and colorful by tradition, the FC'06 program will feature
  invited talks, academic presentations, technical demonstrations, and
  panel discussions. In addition, we will celebrate this 10th year
  edition with a number of initiatives, such as: especially focused
  session, technical and historical state-of-the-art panels, and one
  session of surveys.

  As a past attendee, IFCA wishes to make a plea for your sponsorship.
  The importance of this conference to the larger security community is
  clear, and it is largely sustainable through the generous support of
  its sponsors.  The benefit to your organization is also well worth the
  sacrifice: sponsors receive the kinds unique exposure to the
  cognoscenti that can only be received at these events.  Sponsorship
  opportunities are available at modest levels and beyond.

  If you are interested in sponsoring, we would be very interested in
  talking to you.  Please visit the conference website:

http://siis.cse.psu.edu/fc06/

  Feel free reply to this message or send email to myself
  ([EMAIL PROTECTED]) or contact me via phone (814) 863-3599 for
  further information.

  Sincerely,
  Patrick McDaniel, General Chair, FC '06

 --- end forwarded text


 --
 -
 R. A. Hettinga mailto: [EMAIL PROTECTED]
 The Internet Bearer Underwriting Corporation http://www.ibuc.com/
 44 Farquhar Street, Boston, MA 02131 USA
 ... however it may deserve respect for its usefulness and antiquity,
 [predicting the end of the world] has not been found agreeable to
 experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
 ___
 Clips mailing list
 [EMAIL PROTECTED]
 http://www.philodox.com/mailman/listinfo/clips

--- end forwarded text


-- 
-
R. A. Hettinga mailto: [EMAIL PROTECTED]
The Internet Bearer Underwriting Corporation http://www.ibuc.com/
44 Farquhar Street, Boston, MA 02131 USA
... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

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


Re: Proving the randomness of a random number generator?

2005-12-04 Thread Victor Duchovni
On Sat, Dec 03, 2005 at 10:47:52PM -0600, Travis H. wrote:

 On 12/3/05, Victor Duchovni [EMAIL PROTECTED] wrote:
  Actually, this is inaccurate, proving the strength of AES or factoring is
  difficult, and may never happen, we may even prove AES to be not secure
  (in a broad sense) some day. Proving an RNG secure is *impossible*.
 
 I'm not sure it's impossible, but you certainly have to restrict the
 scope from unconditional security, which is an impossibility anyway.
  By analogy, an attacker may have encrypted some plaintext with your
 key and gotten your ciphertext before.
 
 Here is a reasonable security model:
 An attacker has access to all outputs of this PRNG x_0 .. x_n and
 nothing else of relevance.
 Can he guess x_(n+1) with probability greater than chance?
 

Wrong threat model. The OP asked whether the system generating random
numbers can prove them to have been randomly generating to a passive
observer. The answer is no, this is not possible for the reasons
explained before. This is different from security of random numbers I
generate against being predicted by an adversary.

-- 

 /\ ASCII RIBBON  NOTICE: If received in error,
 \ / CAMPAIGN Victor Duchovni  please destroy and notify
  X AGAINST   IT Security, sender. Sender does not waive
 / \ HTML MAILMorgan Stanley   confidentiality or privilege,
   and use is prohibited.

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


Re: RNG implementations and their problems

2005-12-04 Thread Paul Hoffman

At 10:54 PM -0600 12/3/05, Travis H. wrote:

I'm dissatisfied with the state of /dev/random devices on Unix.


Depends on what you mean by Unix. FreeBSD 5 and 6 have much of what you want.


So far I haven't seen any userland tools for updating the entropy count.


From 'man 4 random':
 If the device has is using the software generator, writing data to random
 would perturb the internal state.  This perturbation of the internal
 state is the only userland method of introducing extra entropy into the
 device.  If the writer has superuser privilege, then closing the device
 after writing will make the software generator reseed itself.  This can
 be used for extra security, as it immediately introduces any/all new
 entropy into the PRNG.


The entropy harvesting and estimation code is bound too tightly to the
entropy pool.

It is in kernelspace so cannot do floating point, like measuring
chi-square or Shannon entropy to estimate the amount of randomness.


 The software random device may be controlled with sysctl(8).

 To see the devices' current settings, use the command line:

   sysctl kern.random

 which results in something like:

   kern.random.sys.seeded: 1
   kern.random.sys.burst: 20
   kern.random.sys.harvest.ethernet: 0
   kern.random.sys.harvest.point_to_point: 0
   kern.random.sys.harvest.interrupt: 0
   kern.random.yarrow.gengateinterval: 10
   kern.random.yarrow.bins: 10
   kern.random.yarrow.fastthresh: 100
   kern.random.yarrow.slowthresh: 160
   kern.random.yarrow.slowoverthresh: 2

 (These would not be seen if a hardware generator is present.)

 All settings are read/write.

Thus, you can do your own calculations and change the paramters to 
your heart's content (assuming you have root privs).


(...Other Linux-specific complaints elided...)

--Paul Hoffman, Director
--VPN Consortium

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


RNG implementations and their problems

2005-12-04 Thread David Wagner
So far I haven't seen any userland tools for updating the entropy count.

This is unfortunate, because sometimes I generate entropy on one machine
and want to pipe it into the /dev/random pool.

However, I cannot update entropy counts [...]

This is a security feature.  If non-root programs could write to
/dev/random and update its entropy count, they could lie about the
entropy count and harm others on the system who rely on /dev/random.

By the way, rngd already does pretty much what you want.  Have you
looked at it?

It would be pretty easy to hack egd or prngd to periodically feed
the entropy they have gathered into /dev/random, using the appropriate
ioctl()s and root-level access.  Seems like that would be good enough.

It would also be trivial to write a 'cat'-like program that takes
data on stdin and uses the appropriate ioctl()s to write it to /dev/random.
Problem solved.

But I am skeptical that this problem is very widespread.  I doubt there
are many people who have found this to be a barrier.

I would also question why you are using /dev/random.  For most purposes,
/dev/urandom is the right default.

Reading from /dev/urandom empties the entropy pool immediately; this is
unfriendly to people who need real random numbers.

Few applications truly need /dev/random.  Those applications that do need
/dev/random usually need random numbers only in very small quantities, and
for them, the deplete the pool behavior seems like the right semantics.

It is certainly true that there are many poorly-thought out applications
that use /dev/random even though /dev/urandom would have been a
better choice.  However, I just can't get too bent out of shape if
those applications suffer as a result of their questionable choice.
Those applications will just have to deal with the consequences of
their misdesign.  If it becomes a problem, maybe that will be sufficient
motivation for them to reconsider their use of /dev/random and switch
over to /dev/urandom, like they should have done in the first place.

Anyway, on the question of whether to use write() or ioctl() to update
the entropy pool from user land, my suspicion is that the current
semantics just hasn't been a very big problem for anyone, and so no
one has cared enough to bother writing code to change the behavior.
It's also not clear to me that current interface is problematic or
that your suggestion is a better choice.  But in any event, if you
are motivated enough to try to write code and submit patches that
would implement your preferred solution, you should probably take this
discussion over to the linux-kernel mailing list.

Getting good randomness shouldn't be platform-specific,
and shouldn't fail in silent or unsafe ways at runtime.

I'm not sure what this is referring to.  As far as I know, /dev/{u,}random
doesn't fail in silent or unsafe ways at runtime.

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