2003-10-15 Thread Ian Grigg
Eric Rescorla wrote:
 Ian Grigg [EMAIL PROTECTED] writes:
  I'm sorry, but, yes, I do find great difficulty
  in not dismissing it.  Indeed being other than
  dismissive about it!
  Cryptography is a special product, it may
  appear to be working, but that isn't really
  good enough.  Coincidence would lead us to
  believe that clear text or ROT13 were good
  enough, in the absence of any attackers.
  For this reason, we have a process.  If the
  process is not followed, then coincidence
  doesn't help to save our bacon.

 Disagree. Once again, SSL meets the consensus threat
 model. It was designed that way partly unconsciously,
 partly due to inertia, and partly due to bullying by
 people who did have the consensus threat model in mind.

(If you mean that the ITM is consenus, I grant
you that two less successful protocols follow
it - S/MIME and IPSec (partly) but I don't
think that makes it consensus.  I know there
are a lot of people who don't think in any other
terms than this model, and that is the issue!
There are also a lot of people who think in
terms completely opposed to ITM.

So to say that ITM is consensus is something
that is going to have to be established.

If that's not what you mean, can you please

 That's not the design process I would have liked,
 but it's silly to say that a protocol that matches
 the threat model is somehow automatically the wrong
 thing just because the designers weren't as conscious
 as one would have liked.

I'm not sure I ever said that the protocol
doesn't match the threat model - did I?  What
I should have said and hoped to say was that
the protocol doesn't match the application.

I don't think I said automatically, either.
I did hold out hope in that rant of mine that
the designers could have accidentally got it
right.  But, they didn't.

Now, SSL, by itself, within the bounds of the
ITM is actually probably pretty good.  By all
reports, if you want ITM, then SSL is your
best choice.

But, we have to be very careful to understand
that any protocol has a given set of characteristics,
and its applicability to an application is an
uncertain thing;  hence the process of the threat
model and the security model.  In SSL's case, one
needs to say use SSL, but only if your threat
model is close to ITM.  Or similar.  Hence the
title of this rant.

The error of the past has been that too many
people have said something like Use SSL, because
we already got it right.  Which, unfortunately,
skips the whole issue of what threat model one
is dealing with.  Just like happened with secure

In this case, the ITM was a) agreed upon after
the fact to fill in the hole, and b) not the right
one for the application.

   And on the client side the user can, of course, click ok to the do
   you want to accept this cert dialog. Really, Ian, I don't understand
   what it is you want to do. Is all you're asking for to have that
   dialog worded differently?
  There should be no dialogue at all.  Going from
  HTTP to HTTPS/self signed is a mammoth increase
  in security.  Why does the browser say it is
  less/not secure?
 Because it's giving you a chance to accept the certificate,
 and letting you know in case you expected a real cert that
 you're not getting one.

My interpretation - which you won't like - is that
it is telling me that this certificate is bad, and
asking whether me if I am sure I want to do this.

A popup is symonymous with bad news.  It shouldn't be
used for good news.  As a general theme, that is,
although this is the reason I cited that paper:  others
have done work on this and they are a long way ahead
in their thinking, far beyond me.

   It's not THAT different from what
   SSH pops up.
  (Actually, I'm not sure what SSH pops up, it's
  never popped up anything to me?  Are you talking
  about a windows version?)
 SSH in terminal mode says:
 The authenticity of host ' (' can't be established.
 RSA key fingerprint is d3:a8:90:6a:e8:ef:fa:43:18:47:4c:02:ab:06:04:7f.
 Are you sure you want to continue connecting (yes/no)? 
 I actually find the Firebird popup vastly more understandable
 and helpful.

I'm not sure I can make much of your point,
as I've never heard of nor seen a Firebird?


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

Re: cryptographic ergodic sequence generators?

2003-10-15 Thread John S. Denker
Perry E. Metzger wrote:

I've noted to others on this before that for an application like
the IP fragmentation id, it might be even better if no repeats
occurred in any block of 2^31 (n being 32) but the sequence did not
repeat itself (or at least could be harmlessly reseeded at very very
long intervals).
I assume the point of the reseeding is to make
the ID-values more unpredictable.
On 09/07/2003 11:18 AM, David Wagner wrote:

 Let E_k(.) be a secure block cipher on 31 bits with key k.
 Pick an unending sequence of keys k0, k1, k2, ... for E.

 Then your desired sequence can be constructed by
   E_k0(0), E_k0(1), E_k0(2), ..., E_k0(2^31 - 1),
   2^31 + E_k1(0), 2^31 + E_k1(1), ..., 2^31 + E_k1(2^31 - 1),
   E_k2(0), E_k2(1), E_k2(2), ..., E_k2(2^31 - 1),
   2^31 + E_k3(0), 2^31 + E_k3(1), ..., 2^31 + E_k3(2^31 - 1),
Again if we assume the point is to make the values
unpredictable (not just ergodic), then there is
room for improvement.
To see what I mean, divide the values into generations
G=0,1,2,3... where each row in the tableau above is
one generation.
The problem is that at the end of each generation,
the values become highly predictable, à la Blackjack.
David's proposal can be improved by the method used
by Blackjack dealers:  shuffle early.  In each
generation, let the argument of E_kG(.) max out at
some fraction (f) of 2^(n-1).  A limit of f=1/2 is
the obvious choice, although other f values e.g. f=2/3
work nicely too.  The domain and range of E_kG(.) are
still unrestricted (n-1)-bit numbers.
This gives us the following properties
 -- Guaranteed no repeats within the last f*2^(n-1) IDs.
 -- Probably no repeats in an even longer time.
 -- Even if the opponent is a hard-working Blackjack
player, he has only one chance in (1-f)*2^(n-1)
of guessing the next value.  To put this number in
context, note that the opposition has one chance
in 2^(n-1) of guessing the next value without any
work at all, just by random guessing.
Setting f too near zero degrades the no-repeat guarantee.
Setting f too near unity leads to the Blackjack problem.
Setting f somewhere in the middle should be just fine.

Discussion of conceivable refinements:

A proposal that keeps coming up is to take the values
generated above and run them through an additional
encryption stage, with a key that is randomly chosen
at start-up time (then held fixed for all generations).
The domain and range of this post-processing stage
are n-bit numbers.
This makes the output seem more elegant, in that we
have unpredictability spread over the whole n-bit word,
rather than having n-1 hard-to-predict bits plus one
almost-constant bit.
Define the phase to be P := (G mod 2).

The opponent will have to collect roughly 2^n data
points before being able to figure out which values
belong to which phase, so initially his guess rate
will be closer to one in 2^n, which is a twofold
improvement ... temporarily.
This temporary improvement is not permanent, if we
allow the opponent to have on the order of 2^n
memory.  He will in the long run learn which values
belong to which phase.  I see no way to prevent this.
So as far as I can tell, the proposed post-processing
is more in the nature of a temporary annoyance to the
opposition, and should not be considered industrial-strength
Perhaps more to the point, if we are going to allow
the opposition to have 2^n memory, it would be only
fair to allow the good guys to have 2^n memory.  In
that case, all the schemes discussed above pale in
comparison to something I suggested previously, namely
generating an ID absolutely randomly, but using a
look-up table to check if it has been used recently,
in which case we veto it and generate another.  If
you can afford the look-up table, these randomly
generated IDs have the maximum possible unpredictability.
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: Internal format of RSA private keys in microsoft keystore.

2003-10-15 Thread Anton Stiglic

- Original Message - 
Sent: Friday, October 10, 2003 1:20 AM
Subject: Internal format of RSA private keys in microsoft keystore.

 In the process of trying to work around some of the limitations
 of the m$-CAPI API, I'm trying to decipher the internal representation
 of private keys in the default m$ key store, in order to extract
 the private key out.

If you could acquire a context, you could export the private key into 
a blob and then read it from that, but you can't acquire a context.
As Tom mentioned, the keys are encrypted in the container.
The FIPS 140 security policies for M$'s CSPs say that the task 
of protecting the keys in the system is delegated to Data Protection 
API (DPAPI).  There is a brief explanation in the security policies, 
see for example
section Key Storage.
You might be able to find more detailed information somewhere else...

Good luck!


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

Indian National Workshop on Cryptography

2003-10-15 Thread R. A. Hettinga

Tuesday, October 14, 2003 
 Cyber India Online 

National workshop on cryptography 

PUNE: Cryptography was until recently an exclusive domain of the defense and security 
agencies. However, with the explosive growth of computerization, networking and the 
Internet coupled with the increasing importance of electronic commerce, cryptography 
has become an essential component of all electronic data exchange and economic 

The AU-KBC Research Center has organized its annual workshop, which is an annual event 
of the Cryptology Research Society of India (CRSI) to focus on this subject. This 
year's workshop, which would be from October 16, 2003 - October 18, 2003 at Hyderabad 
is based on the theme Applications of cryptology to Information Security. Satyakam 
Mishra (certified ethical hacker) and Dr. SA Vetha Manickam of Network Security 
Solutions, Pune will present a paper on Software implementation of attack on A5/1 
with possible improvements at the workshop. 

As part of the effort, Satyakam and Dr. Manickam have implemented an attack against 
A5/1, the strong over the air voice privacy algorithm for GSM networks, on an IBM PC. 
Eli Biham and Orr Dunkelmann described the attack in a recent paper. With their 
effort, in a simulated environment, they were able to recover the 64 bit secret key. 
They were also able to find errors in the Bihams attack and the effect was increase in 
proposed complexity from 240.97 to 241.29. The paper describes the attack techniques, 
the implementation, and some optimizations to make the attack more efficient from the 
earlier work. 

Network Security Solutions has developed an esoteric expertise and capability in 
consulting, research and development in PKI Infrastructure, Cryptography that includes 
development of pseudo- random generator, development of a new stream cipher, 
implementations on secret sharing schemes and various Cryptanalysis techniques, WEP 
cracking and key clustering. 

R. A. Hettinga mailto: [EMAIL PROTECTED]
The Internet Bearer Underwriting Corporation
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]