RE: Trusted timestamping

2009-10-07 Thread Alex Pankratov
 

 -Original Message-
 From: pgut001 [mailto:pgut...@wintermute01.cs.auckland.ac.nz] 
 On Behalf Of Peter Gutmann
 Sent: October 5, 2009 10:07 PM
 To: a...@poneyhot.org; cryptography@metzdowd.com
 Subject: Re: Trusted timestamping
 
 Alex Pankratov a...@poneyhot.org writes:
 
 I have spent a couple of days looking around the Internet, 
 and things 
 appear to be .. erm .. hectic and disorganized.
 
 [...]
 
 Your summary pretty much answers the question, lots of bit 
 players sitting around waiting for the market to emerge, and 
 they've been waiting, in some cases, for at least the last 
 decade or so.  In Europe the vendors are pinning their hopes 
 on legislation forcing people to use TSPs, although even 
 there it's been severely crippled by the fact that having to 
 point a legislative gun at the customers head to get them to 
 use it doesn't engender much enthusiasm for it.

These players are sitting in the wrong place then. I have run 
into a fairly well defined need for a timestamping service in 
a graphic design community. 

Interestingly enough they do not need the timestamps for the 
courts, they need them more as a deterrent to a blatant theft 
of their creative ideas. 

If someone copies their work, verbosely or at a concept level, 
then the clone is wortheless unless it can be sold or used as 
a promotion vehicle. The copycat's goal is to get the copy 
published in as many online galleries and auction/specwork 
sites as possible, and the goal of the original author is to 
prevent that from happening. At the moment the challenge 
frequently boils down to searching through archive.org contents, 
and using that as a proof of who was first. 

In this context archive.org, clearly, serves as a coarse time
stamping service, implicitly trustworthy. There is obviously
a room for improvement, and that's why I asked what I asked.

Alex





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


Entropy USB key

2009-08-11 Thread Alex Pankratov
Just spotted this on one of the tech news aggregators - 

http://www.entropykey.co.uk
 
The Entropy Key, or eKey, is a small, unobtrusive and easily 
installed USB stick that generates high-quality random numbers, 
or entropy, which can improve the performance, security and 
reliability of servers. 

Alex


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


RE: [p2p-hackers] IETF rejects Obfuscated TCP

2008-08-20 Thread Alex Pankratov
CC'ing cryptography mail list as it may be of some interest to the 
folks over there.

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:p2p-hackers-
 [EMAIL PROTECTED] On Behalf Of Lars Eggert
 Sent: August 19, 2008 5:34 PM
 To: David Barrett; theory and practice of decentralized computer
 networks
 Subject: Re: [p2p-hackers] IETF rejects Obfuscated TCP
 
 On 2008-8-19, at 17:20, ext David Barrett wrote:
  On Tue, 19 Aug 2008 4:19 pm, Lars Eggert wrote:
  Actually, in 1994, the IETF standardized Transactional TCP (T/TCP)
 in
  RFC1644, which allows just that. However, there are serious DDoS
  issues with T/TCP which have prevented it seeing significant
  deployment.
 
  Hm, I'm sorry I don't know the history there -- why is this more
  costly
  or abusive than SSL over standard TCP?  Is it due to something
  specific
  to SSL, or due to it a simple lack of congestion control on those
  first
  payloads?
 
 
 The issue is unrelated to a specific kind of SYN payload (SSL or
 otherwise.) The issue is that a SYN flood of SYNs with data consumes
 much more memory on the receiver than a regular SYN flood, because the
 receiver is obligated to cache the data if a T/TCP liveness check
 fails. You can't use SYN cookies with data SYNs, either.

This is just a quick thought, but a variation of SYN cookies for TLS
appears to be quite easy to do. It does require defining new record 
type, but latter is permitted by TLS spec as per Section 6, RFC 2246.

The idea, obviously, is to include a copy of ClientHello message in a
second batch of records sent by the client. This should allow server
to generate ServerKeyExchange parameters from the original ClientHello
message (ClientHello.random + IP/port quintet + server cookie secret),
then discard ClientHello and delay creating the state .. exactly the
same way SYN cookies mechanism does it.

This still doesn't protect against host CPU exhaustion attacks, because
ServerKeyExchange may require some heavy crypto. But since all this is
being discussed in a context of obfuscated TCP and opportunistic
encryption, then using anonymous DH suite might be a feasible option.

The above is trivial to implement, it is backward compatible with existing 
TLS implementations (as per the same section of RFC - records of unknown
types are silently discarded) and all it requires little standardization
effort.

As I said, this is just a quick thought, so in all likelihood I might be
reinventing a (broken) bike here.

Alex

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


RE: [p2p-hackers] IETF rejects Obfuscated TCP

2008-08-20 Thread Alex Pankratov


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:owner-
 [EMAIL PROTECTED] On Behalf Of Eric Rescorla
 Sent: August 20, 2008 10:31 AM
 To: Alex Pankratov
 Cc: 'theory and practice of decentralized computer networks';
 cryptography@metzdowd.com
 Subject: Re: [p2p-hackers] IETF rejects Obfuscated TCP

[snip]

 May I ask what you're trying to accomplish? Recall that TLS doesn't
 start until a TCP connection has been established, so there's
 aready a proof of the round trip.
 
 That said, a mechanism of this type has already been described
 for DTLS (RFC 4347), so no new invention would be needed.

My comment was in a context of a thread discussing Obfuscated TCP.

One of the suggestions was to piggyback SSL handshake on TCP 
handshake, to which someone pointed at an issue with SYN-flood 
like DoS attacks. My response was to the latter comment.

Alex

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


RE: Password vs data entropy

2007-10-27 Thread Alex Pankratov

 -Original Message-
 From: Ben Laurie [mailto:[EMAIL PROTECTED] 
 Sent: Friday, October 26, 2007 3:56 PM
 To: Alex Pankratov
 Cc: cryptography@metzdowd.com
 Subject: Re: Password vs data entropy
 
[snip]
 
 In other words, your password needs to be x/y times the size of the
 secret (in bits), where x and y are the costs of attacking the secret
 and the password respectively.

Essentially the entropy measure alone is not sufficient to 
make a decision, we should also account for the algorithms 
being used. This certainly makes sense .. now that you said 
it :)

Is there any published research into entropy estimates of 
PBKDF2 transformation ? Perhaps, for specific PRF(s) and 
fixed iteration counts. I.e. if I have a password with N 
bits of entropy in a password, what the entropy of the key 
going to be like given *this* set of PBKDF2 parameters.

Also, can you elaborate on this remark ? Specifically, the
second part of it -

 I want to make this distinction because I'd like to talk 
 about secret keys, which have to be rather larger than 4 
 kbits to have 4kbits of entropy for modular arithmetic stuff.

Are you referring to RSA-like secrets that involve prime
numbers, which are therefore selected from a smaller subset
of Z(n) ?

Thanks,
Alex

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


Password vs data entropy

2007-10-26 Thread Alex Pankratov
Say, we have a random value of 4 kilobits that someone wants 
to keep secret by the means of protecting it with a password. 

Empirical entropy estimate for an English text is 1.3 bits of 
randomness per character, IIRC.

Assuming the password is an English word or a phrase, and the 
secret is truly random, does it mean that the password needs 
to be 3100+ characters in size in order to provide a proper
degree of protection to the value ? 

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

I realize that this is rather .. err .. open-ended question, 
and it depends on what one means by protected, but I'm sure 
you can see the gist of the question. How would one deem a
password random enough to be fit for protecting an equivalent
of N bits of random data ? Is it a 1-to-1 ratio ?

Thanks,
Alex

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


RE: Trillian Secure IM

2007-10-10 Thread Alex Pankratov
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Leichter, Jerry
 Sent: Monday, October 08, 2007 11:48 AM
 To: Alex Pankratov
 Cc: cryptography@metzdowd.com
 Subject: RE: Trillian Secure IM
 
 |  But, opportunistic cryptography is even more fun.  It is 
 |  very encouraging to see projects implement cryptography in 
 |  limited forms.  A system that uses a primitive form of 
 |  encryption is many orders of magnitude more secure than a 
 |  system that implements none.
 | 
 | Primitive form - maybe, weak form - absolutely not. It 
 | is actually worse than having no security at all, because 
 | it tends to create an _illusion_ of protection. 

 This is an old argument.  I used to make it myself.  I even used
 to believe it.  Unfortunately, it misses the essential truth:  
 The choice is rarely between really strong cryptography and weak 
 cryptography; it's between weak cryptography and no cryptography 
 at all. What this argument assumes is that people really *want* 
 cryptography; that if you give them nothing, they'll keep on asking 
 for it; but if you give them something weak, they'll stop asking 
 and things will end there.  But in point of fact hardly anyone 
 knows enough to actually want cryptography. Those who know enough 
 will insist on the strong variety whether or not the weak is 
 available; while the rest will just continue with whatever they 
 have.

Well, I view it from a slightly different perspective. 

Even the most ignorant person knows a difference between 
the privacy and the lack of thereof. Cryptography or not. 
Therefore, if he is being told that A offers a privacy, 
it may lead this person to assume the level of this 
privacy protection is adequate ... simply because if it 
weren't, it wouldn't be offered. Needless to say that
this sort of an assumption in case of a weak crypto is
dangerous.

When there's a choice between no and weak protection, I am 
of course in favour of latter *if* it is clearly labeled as 
weak.

 | Which is by the way exactly the case with SecureIM. How 
 | hard is it to brute-force 128-bit DH ? My guesstimate
 | is it's an order of minutes or even seconds, depending
 | on CPU resources.

 It's much better to analyze this in terms of the cost to 
 the attacker and the defender.

Yup, I am familiar with the methodology. My point was that
128bit DH is breakable in terms of the people from those
forum's threads.

Alex

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


RE: Trillian Secure IM

2007-10-08 Thread Alex Pankratov
 

 -Original Message-
 From: Ian G [mailto:[EMAIL PROTECTED] 
 Sent: Monday, October 08, 2007 6:05 AM
 To: Peter Gutmann
 Cc: [EMAIL PROTECTED]; cryptography@metzdowd.com
 Subject: Re: Trillian Secure IM
 
 Peter Gutmann wrote:
  Alex Pankratov [EMAIL PROTECTED] writes:
  
  SecureIM handshake between two version 3.1 (latest) 
 clients takes about .. 48
  bytes. That's altogether, 32 bytes in one direction, and 
 16 in another. And
  that's between the clients that have never talked to each 
 other before, so
  there's no session resuming business happenning.
  
  Or they could be using static/ephemeral DH with fixed 
 shared DH key values,
  which isn't much better.  (This is just speculation, it's 
 hard to tell without
  knowing what the exchanged quantities are).
 
 
 Speculation is fun.
 
 But, opportunistic cryptography is even more fun.  It is 
 very encouraging to see projects implement cryptography in 
 limited forms.  A system that uses a primitive form of 
 encryption is many orders of magnitude more secure than a 
 system that implements none.

Primitive form - maybe, weak form - absolutely not. It 
is actually worse than having no security at all, because 
it tends to create an _illusion_ of protection. 

Which is by the way exactly the case with SecureIM. How 
hard is it to brute-force 128-bit DH ? My guesstimate
is it's an order of minutes or even seconds, depending
on CPU resources.

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


Re: Secure phones from VectroTel?

2006-05-23 Thread Alex Pankratov



Perry E. Metzger wrote:

Following the links from a /. story about a secure(?) mobile phone
VectroTel in Switzerland is selling, I came across the fact that this
firm sells a full line of encrypted phones.

http://www.vectrotel.ch/

The devices apparently use D-H key exchange to produce a 128 bit AES
key which is then used as a stream cipher (presumably in OFB or a
similar mode). Authentication appears to be via a 4 digit pin,
certainly not the best of mechanisms.


According to -

http://www.ohgizmo.com/2006/05/22/vectrotel-provides-secure-mobile-communications/

   Additional security and integrity is ensured by a calculated
   HASH checksum that is indicated on the display.

   To protect you from misuse by a third party we secured the
   crypto functions by a user-determined PIN code

PINs are not used for phone-to-phone authentication, only user-to-phone.
Though the article is full of obvious mistakes, so they might've gotten
this part wrong too.

Alex



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


Re: Zfone and ZRTP :: encryption for voip protocols

2006-03-18 Thread Alex Pankratov
Damien Miller wrote:
 On Wed, 15 Mar 2006, Ed Gerck wrote:

[snip]

...allows the detection of man-in-the-middle (MiTM) attacks by
displaying a short authentication string for the users to read and
compare over the phone.

Depends on the trust model. May not work.
 
 This is incomplete. The paragraph goes on to say:
 
we still get fairly decent authentication against a MiTM attack, based
on a form of key continuity. It does this by caching some key material
to use in the next call, to be mixed in with the next call's DH shared
secret, giving it key continuity properties analogous to SSH.

Here's a quote from the draft -

  We use an analogous baby duck security model to authenticate the DH
  exchange in ZRTP.  We don't need to exchange persistent public keys,
  we can simply cache a shared secret and re-use it to authenticate a
  long series of DH exchanges for secure phone calls over a long period
  of time.  If we read aloud just one SAS, and then cache a shared
  secret for later calls to use for authentication, no new voice
  authentication rituals need to be executed.  We just have to remember
  we did one already.

The draft says that shared secrets are keyed by ZID when stored
in a local cache, where ZID is a unique persistent random ZRTP
endpoint ID.

Unless I am missing something, ZIDs exchanged by peers during a
handshake remain unauthenticated. This means that if both A and
B have cached shared secrets with M, then M can mount MitM
attack against A-B session and both A and B will be under the
impression that they are protected by 'key continuity' from
their previous (A-B) session.

Their SAS won't match of course, but since they see shared secret
being used for KE, they are not likely to bother with SAS check.

Alex

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


Re: Zfone and ZRTP :: encryption for voip protocols

2006-03-18 Thread Alex Pankratov
That's not what I described. An attacker uses his own ZID
and valid shared secrets that he creates with A and B on
some prior occassion. In other words -

* M talks to A as himself. This creates cached AM secret.

* M talks to B as himself. This creates cached BM secret.

* M intercepts A-B handshake and completes each 'leg' of
  the handshake using his own ZID and above secrets.

Since responder's ZID in not a part of a hash in Commit,
this key exchange will complete just fine.

I don't see the draft talking about how/if ZIDs might be
linked to non-ZRTP peer's identities, so I can't see how
A or B can actually discover that they've been MitM'd by
M *unless* they do SAS check. They do however see that KE
used cached shared secret, and they (being humans) are
likely to skip SAS check because of that.

Alex

Philip Zimmermann wrote:
 An attacker can easily present the wrong ZID, but he will not possess 
 the cached shared secrtes held by the real owner of that ZID.  The  user
 interface will tell the user that there are no shared secrets,  which
 means he must reverify the SAS.  Thus, his attack will fail.
 
 
 On Mar 17, 2006, at 4:21 PM, Alex Pankratov wrote:
 
 Damien Miller wrote:

 On Wed, 15 Mar 2006, Ed Gerck wrote:


 [snip]

 ...allows the detection of man-in-the-middle (MiTM) attacks by
 displaying a short authentication string for the users to read and
 compare over the phone.

 Depends on the trust model. May not work.


 This is incomplete. The paragraph goes on to say:

 we still get fairly decent authentication against a MiTM attack,  based
 on a form of key continuity. It does this by caching some key  material
 to use in the next call, to be mixed in with the next call's DH  shared
 secret, giving it key continuity properties analogous to SSH.


 Here's a quote from the draft -

  We use an analogous baby duck security model to authenticate the DH
  exchange in ZRTP.  We don't need to exchange persistent public keys,
  we can simply cache a shared secret and re-use it to authenticate a
  long series of DH exchanges for secure phone calls over a long  period
  of time.  If we read aloud just one SAS, and then cache a shared
  secret for later calls to use for authentication, no new voice
  authentication rituals need to be executed.  We just have to  remember
  we did one already.


 The draft says that shared secrets are keyed by ZID when stored
 in a local cache, where ZID is a unique persistent random ZRTP
 endpoint ID.

 Unless I am missing something, ZIDs exchanged by peers during a
 handshake remain unauthenticated. This means that if both A and
 B have cached shared secrets with M, then M can mount MitM
 attack against A-B session and both A and B will be under the
 impression that they are protected by 'key continuity' from
 their previous (A-B) session.

 Their SAS won't match of course, but since they see shared secret
 being used for KE, they are not likely to bother with SAS check.

 Alex
 
 
 --
 Philip R Zimmermann[EMAIL PROTECTED]
 http://philzimmermann.com  tel +1 650 322-7223
 (spelled with 2 n's)   fax +1 650 322-7877
 
 
 
 

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


Re: hamachi p2p vpn nat-friendly protocol details

2006-02-26 Thread Alex Pankratov
I replied to Tero privately, then realized that I was
not the only recipient of his email. So here's a copy
for everyone's reference.

Alex

Tero Kivinen wrote:

 Travis H. writes:


http://www.hamachi.cc/security

Based on a cursory look over this, I'm impressed by both the level of
detail and the level of security apparently afforded.  Too bad I can't
see the source code.



 I can see couple of problems in the system. Firstly it seems it uses
 same key for both directions for the encryption and for
 authentication, i.e. the KEYMAT is only split to Ke and Ka keys, which
 are used for encryption and authentication. In general using same keys
 for different directions is bad.


The description on a page was not updated properly. Recent clients
use per-direction keys after they complete P2P KE.


 Secondly I cannot find where it
 authenticates the crypto suite used at all (it is not included in the
 signature of the AUTH message).


Crypto suite is essentially just a protocol number. It requires
no authentication. If the server side responds with HELO.OK, it
means that it can comprehend specified protocol revision. Similar
to what happens during the SSH handshake.


 Also it seems that the identity itself
 is not authenticated at all, as it (or it's MACed form) is not
 included in the signature.


It is not.


 There might be (I am not sure whether AUTH
 packet is encrypted and MACed) a MAC over it, but the MAC key is not
 yet authenticated as it is generated from the anonymous
 Diffie-Hellman. That might give it some protection, but I am not sure
 if that is enough.


A protection against what kind of attack ?

Identity is used to specify which public key the client wants
to be authenticated with on the server side. Assuming it is
swapped in transition by a man in the middle, it would still
require an attacker to re-sign authentication hash in the
message.

Assuming he has a private key to do that, he will effectively
succeed in authenticating under substituted ID. He then will
need to re-sign server's auth hash to complete the attack,
which is not going to happen.

There is an off chance that the attacker might swapped the
identity to one that has the same public key. The chances
of this happening are infinitely small unless an attacker
also has an access to victim's keypair, which becomes a
trivial attack case.


 The protocol description is missing some details, so cannot say
 anything about them (things like what is the format of Ni, Nr, Gi, Gr
 when sent over wire and when put to the signatures etc, are the Gi, Gr
 always the lenght of modulus (2048 bits) etc).


What would you like to know exactly ? The page was not meant to
be a bit-level description of messages, merely a description of
the security framework.


 The protocol is also tied to use SHA1.


If you are referring to HMAC-SHA1 for authentication hashes, it
is a part of a crypto suite (protocol revision) spec.


 In general it would be much better to use standard protocol, instead
 of generating your own.


This is the second revision of Hamachi system. First revision
was using SSL for cli-srv and IKE/ESP for p2p security. It was
a prototype and it soon become obvious that both SSL and IKE
were overkills for our purposes. We did not need certificate
authentication of SSL, we did not want to run our own auth
protocol over SSL/AnonDH, which would've increased the number
of packets per login sequence. We didn't need the flexibility
(ie complexity) of IKE either.

After stripping down IKE (ie removing SA negotiation, reworking
ID payloads and not doing quick mode), we essentially ended up
with a protocol that was also fit for securing cli-srv session.
It was further tweaked and replaced SSL.

I should probably add that I implemented IKE (v1) keying daemon
from scratch with all bells and wistles (NATT, extended MODP
groups, etc) at some point in the past. Some remnants of it
are still floating around, the library name was libike.


 Designing security protocols is hard...


Yes, it is. This is why I like it.



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


Re: hamachi p2p vpn nat-friendly protocol details

2006-02-26 Thread Alex Pankratov


Travis H. wrote:
 On 2/24/06, Alex Pankratov [EMAIL PROTECTED] wrote:
 
Tero Kivinen wrote:

[snip]

The protocol description is missing some details, so cannot say
anything about them (things like what is the format of Ni, Nr, Gi, Gr
when sent over wire and when put to the signatures etc, are the Gi, Gr
always the lenght of modulus (2048 bits) etc).

What would you like to know exactly ? The page was not meant to
be a bit-level description of messages, merely a description of
the security framework.
 
 
 Presumably he wants to make sure that the messages like the following
 have an unambiguous interpretation:
 AUTH Identity Signature(Ni | Nr | Gi | Gr, Kpri_cli)
 Merely concatenating them is insufficient unless all but one have a
 fixed length.
 I think a terse unambiguous representation rationale is the whole
 reason for ASN.1, although it seems awfully complex for such a simple
 goal.

Nonces and DH exponents are serialized using PER-style ASN.1 encoding.
So the whole concatenation is unambigious.

 I sort of wonder at the utility of a TCP implementation of the p2p
 VPN... tunnelling TCP over TCP is well known to be a Bad Thing with
 regard to interaction of the TCP timeouts.

Just to be clear, Hamachi tunnels VPN/P2P traffic over UDP. TCP is
used for client-server session only.

VPN over TCP is bad for two reasons. One you listed, and another
is that it becomes trivial to DoS this kind of VPN. TCP packets
are not authenticated (unless MD5/BGP extension is used, which
is unlikely), so the state of VPN transport layer and consequently
the state of a tunnel can be altered by 3rd party.

That's why SSL VPNs make very little sense in non-proxied setups
and that's why (I'd guess) OpenVPN 'tweaked' SSL to run over UDP
instead.


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