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: survey of instant messaging privacy

2008-06-11 Thread alex
[Moderator's note: Please don't send giant run on paragraphs to the
list. They're hard to read. --Perry]

 From: Marcos el Ruptor [EMAIL PROTECTED]
  Interesting.  Of course, with the possible exception of Skype, 
  only  the over-the-network part of the communication is 
  protected.  The  IM providers can still give the contents of your 
  communications to  third parties.
 
 As far as I can tell after having reverse engineered its protocol,  
 Skype is actually very well made with a few exceptions that would  
 still be next to impossible to exploit for a street hacker (and 

A year ago when I took a hard look at the Skype login protocol (via public 
reverse engineering publications, etc.), I determined that the user id to 
public key binding was fundamentally weak.  If I remember correctly they were 
vulnerable to at least one attack, a dictionary attack against a password of a 
user account is possible using the Skype login client-server messages (they 
can't tell you are attacking since the account name and password are hashed 
together in the public key/AES encrypted request and you are using one of the 
well-known 14+ valid Skype public keys).  Their multiple layering of crypto 
obscures things but with software one can automate the building of the login 
request encrypted layers fairly easily.  Once you get a valid user cert from 
the login attack it looks like that account is permanently compromised (I 
didn't see any user cert validity period).  Because of Kerckhoff's principles 
there is really no way Skype can prevent this attack (basically they are using 
the data channel itself to distribute the user certs (with public  private 
auth keys) to then establish an enciphered phone session over it).   They also 
have at least one back door mechanism in place, which could be used to quickly 
compromise a user password.  They allow a user that forgot their password to 
have it reset and sent to their enrollment email address so that a Tier 1 IDS 
like Narus could easily scoop it up (this requires careful social engineering). 
 Also, any SSL traffic to a Skype server can be MITM intercepted (say via a 
Bluecoat ProxySG appliance) using a ICA cert from a major CA vendor (or 
internal corporate CA) and any user passwords could be scooped up that way as 
well.

Thus a retail level wiretap attack against a particular user is quite possible. 
 Having said that because the 14+ private Skype keys are (only?) stored on 
their servers, it does not look like a wholesale attack against the Skype 
system is easy to do (although they did use MD5 in their login algorithm).  
However, given this centralization of Skype keys, they certainly could 
cooperate with any CALEA warrants, etc., by giving police the user certs to be 
wiretapped (which still requires an active MITM during the setup handshake of 
the encrypted channel between the two user end-points).  Of course, if physical 
theft occurs of the 14+ Skype PKI private keys then the whole security ediface 
will collapse.

- Alex


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


Re: Just update the microcode (was: Re: defending against evil in all layers of hardware and software)

2008-04-29 Thread alex

No need to be a major power.  Linux patches x86 code, as does Windows.  I ran 
across a project several years ago that modified the microcode for some i/o x86 
assembly instructions.  Here's a good link explaining it all.  

http://en.wikipedia.org/wiki/Microcode

All this hw/sw flexibility makes designing a good security system a real 
challenge.  You need a reference monitor somewhere in it that you can truly 
trust.

- Alex


 - Original Message -
 From: John Ioannidis [EMAIL PROTECTED]
 To: Cryptography cryptography@metzdowd.com
 Subject: Just update the microcode (was: Re: defending against 
 evil in all layers of hardware and software)
 Date: Mon, 28 Apr 2008 18:16:12 -0400
 
 
 Intel and AMD processors can have new microcode loaded to them, and 
 this is usually done by the BIOS.  Presumably there is some 
 asymmetric crypto involved with the processor doing the signature 
 validation.
 
 A major power that makes a good fraction of the world's laptops and 
 desktops (and hence controls the circuitry and the BIOS, even if 
 they do not control the chip manufacturing process) would be in a 
 good place to introduce problems that way, no?
 
 /ji
 
 -
 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: Protection for quasi-offline memory nabbing

2008-03-26 Thread Alex Alten

At 10:38 AM 3/21/2008 -0700, Jon Callas wrote:


Despite that my hypotheses are only that, and I have no experimental
data, I think that using a large block cipher mode like EME to induce
a pseudo-random, maximally-fragile bit region is an excellent
mitigation strategy.


Isn't EME patented?  - Alex

--

Alex Alten
[EMAIL PROTECTED]



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


Re: Toshiba shows 2Mbps hardware RNG

2008-02-14 Thread alex

 - Original Message -
 From: Pat Farrell [EMAIL PROTECTED]
 To: 
 Subject: Re: Toshiba shows 2Mbps hardware RNG
 Date: Sun, 10 Feb 2008 17:40:19 -0500
 
 
 Perry E. Metzger wrote:
  [EMAIL PROTECTED] (Peter Gutmann) writes:
  I've always wondered why RNG speed is such a big deal for anything but a 
  few
  highly specialised applications.
 
  Perhaps it isn't, but any hardware RNG is probably better than none
  for many apps, and they've managed to put the whole thing in a quite
  small bit of silicon. The speed is probably icing on the cake.
 
 One of the benefits of speed is that you can use cleanup code to 
 control bias. Carl Ellison put some out on his website last century.
 
 

It is a HUGE win for designing a crypto system to have a really 
fast (and good) HW RNG. Being able to generate 10-20,000 AES keys
per second means that you can engineer things that were impossible
to do otherwise.  You can generate as many keys as you like, throw
away keys after one time use, treat them as ephemeral authentication
keys (say give a few million or so to a user), etc. Or you could 
hand a sender 10 MBytes (less than a minute to generate), which then
can be used to create billions of keys (say using Ueli Maurer's 
Bounded Storage Model).  The sender could then use each key to 
uniquely encrypt (AES CTR) each message of a series of messages or
packets to a receiver (AES key setup is fast). No need for an IV or 
worrying about message ordering (each one has a key id), or even the
compromise of a key or two.

Randomness is the most fundamental underpinning of a crypto system
and having lots of it on demand is really fabulous to have in our 
system security design tool box.

- Alex


 


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


Re: TLS-SRP TLS-PSK support in browsers (Re: Dutch Transport Card Broken)

2008-02-03 Thread Alex Alten

At 09:34 PM 2/1/2008 +0100, Ian G wrote:

* Browser vendors don't employ security people as we know them on this 
mailgroup, they employ cryptoplumbers. Completely different layer.  These 
people are mostly good (and often very good) at fixing security bugs.  We 
thank them for that!  But they are completely at sea when it comes to 
systemic security failings or designing new systems.


An excellent observation Ian!!

I too have run into this mindset at enterprises with inhouse security teams 
(mostly in Silicon Valley).  They focus on the nuts and bolts like 
producing/using cryptographic libaries, fixing security bugs in code or 
configuring network appliances to stop intrusions.  But it is really hard 
to find any of them with decent experience or knowledge at the overall 
software/hardware/people system design level. They are often very smart and 
educated engineers. I find that there's this mindless focus on using 
groups of security standards, e.g PKI / LDAP / SSL type of combinations, 
etc.  The DoD contractor firms seem to be a little bit better at 
recognizing the system level aspects of security, although they too are 
often blinded by the emphasis on COTS security products.


- Alex
--

Alex Alten
[EMAIL PROTECTED]



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


malware in digital photo frames infects users computers

2008-01-27 Thread Alex Alten
Great.  What next?  I guess air-gap transfer of flash memory might be the 
best solution.


Malware's new infection route: photo frames
http://www.sfgate.com/cgi-bin/article.cgi?file=/c/a/2008/01/26/MNE7UHOOQ.DTL

- Alex
--

Alex Alten
[EMAIL PROTECTED]



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


Re: Death of antivirus software imminent

2008-01-18 Thread Alex Alten

At 07:35 PM 1/18/2008 +1000, James A. Donald wrote:

Alex Alten wrote:
 Generally any standard encrypted protocols will
 probably eventually have to support some sort of CALEA
 capability. For example, using a Verisign ICA
 certificate to do MITM of SSL, or possibly requiring
 Ebay to provide some sort of legal access to Skype
 private keys.

And all the criminals will of course obey the law.

Why not just require them to set an evil flag on all
their packets?


These are trite responses.  Of course not.  My point is
that if the criminals are lazy enough to use a standard
security protocol then they can't expect us not to put
something in place to decrypt that traffic at will if necessary.


 If there is a 2nd layer of encryption then this would
 require initial key exchanges that may be vulnerable
 to interception or after-the-fact analysis of the
 decrypted SSL payloads.

I guarantee I can make any payload look like any other
payload.  If the only permitted communications are
prayers to Allah, I can encode key exchange in prayers
to Allah.


Yeah and you can only communicate with Allah with
that type of design.

Look, the criminals have to design their security system with
severe disadvantages; they don't own the machines they
attack/take over so they can't control its software/hardware
contents easily, they can't screw around too much with the IP
protocol headers or they lose communications with them, and
they don't have physical access to the slave/owned machines.

And, last I heard, they must obey Kerckhoff's law, despite
using prayers to Allah for key exchanges.

Given all this, I'm not saying its easy to do, but it should be
quite possible to crack open some or all of their encrypted
comms and/or trace back to the original source attack
machines.

- Alex

--

Alex Alten
[EMAIL PROTECTED]



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


Re: Death of antivirus software imminent

2008-01-04 Thread Alex Alten

At 11:23 PM 1/3/2008 +, Steven M. Bellovin wrote:

On Thu, 03 Jan 2008 11:52:21 -0500
[EMAIL PROTECTED] wrote:

 The aspect of this that is directly relevant to this
 list is that while we have labored to make network
 comms safe in an unsafe transmission medium, the
 world has now reached the point where the odds favor
 the hypothesis that whomever you are talking to is
 themselves already 0wned, i.e., it does not matter if
 the comms are clean when the opponent already owns
 your counterparty.

Right -- remember Spaf's famous line about how using strong crypto on
the Internet is like using an armored car to carry money between
someone living in a cardboard shack and someone living on a park bench?

Crypto solves certain problems very well.  Against others, it's worse
than useless -- worse, because it blocks out friendly IDSs as well as
hostile parties.


I agree with these statements.  I have a couple of comments
regarding crypto and IDS.  I think that we will have to move toward
encrypting more data at rest in some manner that is that is easy for
the user to use (like ATM cash cards) yet difficult for a malicious
piece of software on the user's machine to circumvent.  This will
require that all PC's ship with a trusted hardware/firmware chip
AKA a reference monitor on the motherboard that can safely handle
any red keys.  This also means the PC needs a trusted path to
the user like the pin pad in ATM machines.  Many laptops now
ship with fingerprint scanners, so maybe these things are not such
an onerous requirement on PC manufacturers anymore.  Also
the reference monitor could be used to prevent viruses being able
to completely taking over the user's machine (maybe at least
to maintain some sort of host IDS capability).

For IDS, I think we need to think of it in more the context of policing.
These virus writers are human beings, and I suspect for the most
part a very small fraction of the total Internet population.  We need to
have tools and international Interpol-like treaties in place that allow
police to track down and arrest these people (or deny them access
via an ISP or a carrier).  Many of the tier 1 carriers apparently are
refusing to share IDS information with one another.  This needs to
change.  We need really good IDS tools that track down the control
lines of the botnets, etc., back to their actual handlers.  This may
mean that each carrier must archive large amounts of either netflow
data or even raw packets (say for non-TCP traffic) so that detailed
L7 analysis can take place to track botnet control lines back to their
handlers in after-the-fact investigations.  Also, I hate to say this, we
may need to also require that all encrypted traffic allow inspection of
their contents under proper authority (CALEA essentially).  If we
can do this then we can put real policing pressure on these virus
writers, essentially removing them from being able to attack us
over the Internet.

- Alex

--

Alex Alten
[EMAIL PROTECTED]



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


Re: crypto class design

2007-12-26 Thread Alex Alten

At 06:48 PM 12/18/2007 -0800, Arshad Noor wrote:

While there are many different ways to approach encryption
and decryption of sensitive data, you may want to consider
how you plan to manage the encryption keys before you go
down this path.


This is prudent.  You should consider how to securely integrate
key management with other important components of a security
system, such as identity/authentication, policy adjudication
(policy enforcement should be the encrypt/decrypt itself) and
audit/logging.  Logging is usually very important in financial
firms.  You should also carefully think about how to support
revocation of users (i.e. preventing a revoked user from using
a key to decrypt/encrypt data), and also to support key recovery
of encrypted data under proper authority (say to comply with
a legal warrant.)

Finally, regardless of your design you must carefully weigh and
assess it's performance, doing the tradeoff between cryptography
and speed and reliability.  And you need to design it to be robust
in the face of operational failure.

Just my two cents worth (based on over a decade's worth of
cryptographic based security system design).

- Alex
--

Alex Alten
[EMAIL PROTECTED]



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


Re: gauging interest in forming an USA chapter of IISP

2007-12-14 Thread Alex Alten

Ali,

Sorry for the misunderstanding.  I'm not soliciting for new members.

If there happens to be anyone on this list who is an IISP member and lives 
in the USA
and would be interested in forming a chapter on this side of the Atlantic 
then I'd like to

work with them to establish it.

That's all.

- Alex

At 11:05 AM 12/13/2007 -0800, Ali, Saqib wrote:

How will this be any different from being a member of ISC2 or ISACA?
Why do we need to be a member of yet another organization?

saqib
http://www.quantumcrypto.de/dante/


On Dec 12, 2007 12:21 PM, Alex Alten [EMAIL PROTECTED] wrote:

 Would anyone on this list be interested in forming a USA chapter of the
 Institute
 of Information Security Professionals (IISP, www.instisp.org)?

 I'm finding it rather difficult to attend events, etc., that are only in
 London.

 - Alex


--

Alex Alten
[EMAIL PROTECTED]



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


gauging interest in forming an USA chapter of IISP

2007-12-13 Thread Alex Alten


Would anyone on this list be interested in forming a USA chapter of the 
Institute

of Information Security Professionals (IISP, www.instisp.org)?

I'm finding it rather difficult to attend events, etc., that are only in 
London.


- Alex


--

Alex Alten
[EMAIL PROTECTED]



-
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]


another Skype worm attack via IM

2007-09-11 Thread alex
eWeek Insider Channel published an interesting article today about, “Skype 
working with domain owners to shut down malicious sites infecting Skype for 
Windows users via instant messages.”

http://www.channelinsider.com/article/Skype%20Worm%20Attacks%20Security%

- Alex

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


Re: New DoD encryption mandate

2007-08-17 Thread Alex Alten

At 04:02 AM 8/17/2007 -0700, =?UTF-8?Q?Ivan_Krsti=C4=87?= wrote:

On Aug 16, 2007, at 8:30 AM, Ali, Saqib wrote:

The other problem is that it lacks any centralized management. If you
are letting TPM manage your Bitlocker keys you still need a TPM
management suite with key backup/restore/transfer/migrate capabilities
in case your computer goes bad.


How so? If your computer goes bad, you need a *backup*. That's
entirely orthogonal to the drive encryption problem. Bitlocker uses
the TPM to provide assurance that your drive -- really, volume -- is
locked to your computer, and that the early boot environment hasn't
been messed with. When either check fails, you use the BitLocker
recovery password (either on a USB stick or entered manually) to
recover your data. This holds in the event that you take your drive
out and stick it in a different machine. In other words, the TPM is
not a single point of failure, so I don't understand why you think
you care about TPM backup/restore/transfer.


It depends on your requirements.  For a large numbers of computers
owned by a corporation/organization centralized key management
makes a lot of sense.  For a single user with a privately purchased
computer then the recovery password makes more sense.


The third problem is that it is software based encryption, which uses
the main CPU to perform the encryption.


Security is never free, but in 2007, we can afford the cycles. What's
a better use for them? Drawing semi-transparent stained glass window
borders?


Agreed, for most requirements.  Sometimes one may need to keep keys
in trusted hardware only.  The only real fly-in-the-ointment is that current
hash algorithms (SHA-1, SHA-2, etc.) don't scale across multiple CPU
cores (assuming you need integrity along with your privacy).

- Alex

--

Alex Alten
[EMAIL PROTECTED]



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


Re: A secure Internet requires a secure network protocol

2007-06-23 Thread Alex Alten

Lynne or Anne,

At 10:30 AM 6/22/2007 -0600, Anne  Lynn Wheeler wrote:

A secure Internet requires a secure network protocol
http://www.infoworld.com/article/07/06/22/25OPsecadvise_1.html



Actually I think we need a shadow Internet that is used only for security 
purposes (and is
fully encrypted).  It is sort of like the old SS7 signaling infrastructure 
of the phone network.
It doesn't need the same bandwidth, maybe 1/1000 or 1/10,000 as much.  It 
would use
strictly cryptographic protocols for identity  authentication and key 
management, etc..




one of the things seen in various of the SSL (authentication) vulnerabilities


SSL seems to be hanging by a thread, mainly the name to public key mapping
depends on how thorough the checking is done in to SSL vs application layers
inside of the web browser.  If this is hosed then unrestricted MITM is in 
the cards

sometime in the near future.

- Alex

--

Alex Alten
[EMAIL PROTECTED]



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


Re: question re practical use of secret sharing

2007-06-22 Thread alex
 [EMAIL PROTECTED] 
 
 D. K. Smetters [EMAIL PROTECTED] writes:
 
  However, given the difficulty people have in managing keys in general,
  building effective systems that allow them to manage key fragments is beyond
  the range of most current commercial products.
 
 I think that's the perfect summary of the problem with threshold schemes.
 The processes they involve is simply too complex both to model mentally for
 users and to build an interface to.  

Heck, even normal key management seems to be too much.  Most real world 
secure systems I seen have a leap of faith aspect to them when distributing
the first key (such as a CA or a login server's public key). Often MITM
scenarios are not properly considered when distributing the session keys/ 
certificates. Software ease-of-use/automation trumps properly done key 
management/user enrollment.  It's a pity because often millions of people 
start using them before the serious problems start to crop up (like thievery
or illegal wiretapping) and then it's too late to retrofit them properly
(for example Skype seems to have made these types of mistakes).

- Alex

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


Re: Blackberries insecure?

2007-06-21 Thread alex
Steve,

It could be that the linkage between user ids and auth keys is too weak,
allowing a MITM attack to be undetected that sniffs the data encryption
key. This seems to be common problem with many of the secure protocols 
I've examined.

- Alex


 - Original Message -
 From: Steven M. Bellovin [EMAIL PROTECTED]
 To: cryptography@metzdowd.com
 Subject: Blackberries insecure?
 Date: Wed, 20 Jun 2007 23:41:20 -0400
 
 
 According to the AP (which is quoting Le Monde), French government
 defense experts have advised officials in France's corridors of power
 to stop using BlackBerry, reportedly to avoid snooping by U.S.
 intelligence agencies.
 
 That's a bit puzzling.  My understanding is that email is encrypted
 from the organization's (Exchange?) server to the receiving Blackberry,
 and that it's not in the clear while in transit or on RIM's servers.
 In fact, I found this text on Blackberry's site:
 
   Private encryption keys are generated in a secure, two-way
   authenticated environment and are assigned to each BlackBerry
   device user. Each secret key is stored only in the user's secure
   regenerated by the user wirelessly.
 
   Data sent to the BlackBerry device is encrypted by the
   BlackBerry Enterprise Server using the private key retrieved
   from the user's mailbox. The encrypted information travels
   securely across the network to the device where it is decrypted
   with the key stored there.
 
   Data remains encrypted in transit and is never decrypted outside
   of the corporate firewall.
 
 Of course, we all know there are ways that keys can be leaked.
 
 
   --Steve Bellovin, http://www.cs.columbia.edu/~smb
 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]



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


Russian cyberwar against Estonia?

2007-05-18 Thread Alex Alten

This may be a bit off the crypto topic, but it is interesting nonetheless.

Russia accused of unleashing cyberwar to disable Estonia
http://www.guardian.co.uk/print/0,,329864981-103610,00.html

Estonia accuses Russia of 'cyberattack'
http://www.csmonitor.com/2007/0517/p99s01-duts.html

- Alex
--

Alex Alten
[EMAIL PROTECTED]

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


SSL MITM attack vs wiretap laws question

2007-05-05 Thread Alex Alten
I have a question about the legality of doing a successful MITM attack 
against SSL
(server-side authentication only).  This is mainly a USA only 
question.  Although
Europe and Japan is of interest too.  This is not a CALEA or ETSI type of 
situation.


If the SSL connection is traversing an enterprise or a common carrier is it 
legal for
that party to perform a MITM against it in order to examine the encrypted 
information?


My reading of the US Federal wiretap laws seems to indicate that this is ok 
if one of the

following conditions exists:
1. The enterprise/carrier posts a notice that all SSL connections are 
subject to inspection.
2. The enterprise/carrier notifies one or both parties of the SSL 
connection that inspection

is taking place.
3. The enterprise/carrier examines the SSL to prevent 
DoS/DDoS/Worm/Phishing attacks

or to do QoS (load balancing, bandwidth shaping, etc).

I don't think wire fraud laws are involved, even though a properly signed 
yet fake X.509
PKI certificate is sent to the browser by the MITM enterprise/carrier 
pretending to be
the destination site in order to extract the encryption keys used to 
encrypt the

SSL connection.

Any lawyers out there who would know how to interpret US federal law regarding
this area?  (European/Japan, or other rule-of-law type countries are of 
interest too.)


Thanks,

- Alex
--

Alex Alten
[EMAIL PROTECTED]



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


2nd Benelux Workshop on Information and System Security (WISSEC)

2007-05-02 Thread Alex Biryukov

Dear cryptographers,

Prof. Sjouke Mauw and myself would like to invite you and your students to
submit research papers
to the 2nd Benelux Workshop on Information and System Security (WISSEC)
which will take place
*September 20-21, 2007 in Luxembourg.

* The purpose of the workshop is to share ideas, experiences and information
on the following, or related, topics:

  - Design and analysis of cryptographic algorithms
  - Cryptographic and security protocols, formal verification
  - Network security, Internet security, Wireless security
  - Security for embedded systems, smart cards and RFID
  - Security of software and hardware systems
  - Privacy enhancing technologies
  - E-voting, e-banking, e-government
  - Financial cryptography and security
  - Content protection, DRM, watermarking
  - Biometrics
  - Standards for information security
  - Legal and social aspect of information security
  - Ethical hacking, protection against malware, spam


*
*Please visit the web-site to see the call for papers:*
*http://wissec2007.uni.lu/

The submission server of WISSec 2007 is now open at:
https://wissec2007.uni.lu/iChair/

Please encourage your colleagues and students to submit papers for the
evaluation and feel free to advertise WISSec 2007!

Thank you for your help,
The WISSec 2007 program co-chairs
Alex Biryukov and Sjouke Mauw.
P.S: sorry if you get this mail twice.


Re: gang uses crypto to hide identity theft databases

2006-12-22 Thread Alex Alten
I'm curious as to why the cops didn't just pull the plugs right away.  It 
would probably
take a while (minutes, hours?) to encrypt any significant amount of 
data.  Not to

mention, where is the master key? The guy couldn't have jumped up and typed
in a pass phrase to generate it in handcuffs? Even if it got erased, it's 
image could
be recovered from a disk or RAM.  My understanding is that even tamperproof 
cards

one can get keys from them with the right equipment from the right folks.

- Alex

At 02:51 AM 12/23/2006 +1300, Peter Gutmann wrote:

Jim Gellman [EMAIL PROTECTED] writes:
Well this just sucks if you ask me.
 According to the Crown Prosecution Service (CPS), which confirmed that
 Kostap had activated the encryption after being arrested, it would
 have taken 400 computers twelve years to crack the code.
Scales linearly, right?  4,800 computers'll get it in a year?

I don't think you can even apply that much analysis to it.  How exactly did
they come up with such a figure in the first place?  400 *what* computers?
TRS-80's?  Cray XT4's?  Does the encryption software come with a disclaimer
saying if you forget your password, it'll take 400 computers 12 years to
recover your data?  With that level of CPU power it sounds like it'd
something at the level of brute-forcing a 56-bit DES key (using a software-
only approach), which sounds like an odd algorithm to use if it's current
crypto software.  It sounds more like a quote for the media (or, more likely,
misreporting) than any real estimate of the effort involved.

Peter.

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


--

Alex Alten
[EMAIL PROTECTED]



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


Re: cellphones as room bugs

2006-12-04 Thread Alex Alten


At 10:21 AM 12/2/2006 -0500, Perry E. Metzger wrote:


Quoting:

   The FBI appears to have begun using a novel form of electronic
   surveillance in criminal investigations: remotely activating a
   mobile phone's microphone and using it to eavesdrop on nearby
   conversations.

   The technique is called a roving bug, and was approved by top
   U.S. Department of Justice officials for use against members of a
   New York organized crime family who were wary of conventional
   surveillance techniques such as tailing a suspect or wiretapping
   him.

http://news.com.com/2100-1029_3-6140191.html


Cellphones maintain contact with cell towers, so they can be roughly
tracked on the ground too, even when you are not talking.  With GPS
being embedded this may become much more accurate.

As an amusing aside, for a while someone was accidently calling my
land line with their cell phone.  You could hear them driving around, with
the usual car noises, and sometimes the radio on too. Occasionally I
heard them in conversation with someone else. This went on for months.

- Alex


--

Alex Alten
[EMAIL PROTECTED]



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


Re: OpenSSL PKCS #7 supports AES SHA-2 ?

2006-10-12 Thread Alex Alten

Russ,

OK.  I found SHA-2 in RFC 4634 (only 3 months old), which refers back to 
FIPS 180-2.


But I reach a dead-end with PKCS #7 (now RFC 3852).  There's no support for 
SHA-2

algorithm types (RFC 3279). Also PKCS #1 (now RFC 3447) needs an update for
SHA-2 with RSA encryption (OIDs, etc.).

Did I miss something or do you need help in updating these, since I, and 
probably

others too, need them?

- Alex


At 01:19 PM 10/9/2006 -0400, Russ Housley wrote:
PKCS#7 has been turned over to the IETF for maintenance.  The most recent 
version is RFC 3852.  Since the protocol is more stable than the 
cryptographic algorithms, the algorithm discussion appear in separate RFCs.


TLS 1.2 is under development in the IETF.  It is being done in such a way 
that none of the ciphersuites that have already been defined need to be 
updated, including the ones that use AES and the SHA-2 family.


Russ


At 01:28 AM 10/7/2006, Alex Alten wrote:

After reading PKCS #1 v2 more closely and SHA-2 is not even in the specs,
therefore OpenSSL PKCS #7 functions won't support SHA-2.  This spec was
last updated in 1998.

PKCS Editor, is there a new update in progress by RSA Labs to incorporate
SHA-2 and AES?

Does OpenSSL implement PKCS #1 v2 or just v1.5?  If the latter then not even
SHA-1 is supported.

PKCS editor, is there any timeline as to when PKCS #7 will then be updated
with references to official OIDs, etc., for specifying SHA-2 and AES?

Dr. Ron Rivest, are you going to publish new message-digest IETF RFCs for 
SHA-1

and SHA-2?  (So that they can be referenced by an updated PKCS #7.)

Mr. Russ Housley, can you weigh in with what happening in the IETF WG 
security
area?  I know that Mr. Eric Rescorla is working on a new TLS v1.2 
draft.  Will this
be done/ratified soon?  I assume OpenSSL will incorporate this soon 
thereafter?


This mess with the MD5 and SHA-1 hashes is really starting to becoming a 
problem.
It's certainly impacting new development projects/products I'm involved 
with using

SSL and PKI certificates.  My customers are concerned about using MD5 and
SHA-1, and they don't want to keep paying for implementations repeatedly 
as the

standards catch up to reality.  Updating these various heavily used standards
quickly is quite important.

Sincerely (and thanks in advance for all of your replies),

- Alex


At 09:05 AM 10/6/2006 -0700, Alex Alten wrote:

Does anyone know if the OpenSSL PKCS #7 functions support AES and SHA-2?
(I assuming OpenSSL 0.9.7 or later.)

Thanks,

- Alex


--

Alex Alten
Alten Security Engineering, Inc.
[EMAIL PROTECTED]




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


Re: OpenSSL PKCS #7 supports AES SHA-2 ?

2006-10-08 Thread Alex Alten

After reading PKCS #1 v2 more closely and SHA-2 is not even in the specs,
therefore OpenSSL PKCS #7 functions won't support SHA-2.  This spec was
last updated in 1998.

PKCS Editor, is there a new update in progress by RSA Labs to incorporate
SHA-2 and AES?

Does OpenSSL implement PKCS #1 v2 or just v1.5?  If the latter then not even
SHA-1 is supported.

PKCS editor, is there any timeline as to when PKCS #7 will then be updated
with references to official OIDs, etc., for specifying SHA-2 and AES?

Dr. Ron Rivest, are you going to publish new message-digest IETF RFCs for 
SHA-1

and SHA-2?  (So that they can be referenced by an updated PKCS #7.)

Mr. Russ Housley, can you weigh in with what happening in the IETF WG security
area?  I know that Mr. Eric Rescorla is working on a new TLS v1.2 
draft.  Will this

be done/ratified soon?  I assume OpenSSL will incorporate this soon thereafter?

This mess with the MD5 and SHA-1 hashes is really starting to becoming a 
problem.
It's certainly impacting new development projects/products I'm involved 
with using

SSL and PKI certificates.  My customers are concerned about using MD5 and
SHA-1, and they don't want to keep paying for implementations repeatedly as 
the

standards catch up to reality.  Updating these various heavily used standards
quickly is quite important.

Sincerely (and thanks in advance for all of your replies),

- Alex


At 09:05 AM 10/6/2006 -0700, Alex Alten wrote:

Does anyone know if the OpenSSL PKCS #7 functions support AES and SHA-2?
(I assuming OpenSSL 0.9.7 or later.)

Thanks,

- Alex



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


Re: switching from SHA-1 to Tiger ?

2006-07-12 Thread alex

 - Original Message -
 From: Zooko O'Whielacronx [EMAIL PROTECTED]
...
 The AES competition resulted in a block cipher that was faster as 
 well as safer than the previous standards.  I hope that the next 
 generation of hash functions achieve something similar, because for 
 my use cases speed in a hash function is more important than speed 
 in encryption.
 

I believe that this will be more and more the case.  Hashes will 
probably become slower relative to ciphers.  CPUs are becoming 
multi-core and data pipelining from RAM into a CPU on-chip cache 
is now common.  Both of these semiconductor trends will make 
existing hashes become bottlenecks and will make it harder to 
design a fast new hash.

- Alex 

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


Re: mailer certificate retrieval via LDAP?

2006-06-09 Thread Alex Iliev
On Thu, Jun 08, 2006 at 02:32:01PM -0400, Steven M. Bellovin wrote:
 Are there any common mailers -- open source preferred but not mandatory --
 that can query LDAP directories to retrieve X.509 certificates for use in
 S/MIME messages?  Evolution and Thunderbird are both able to send S/MIME,

This works for me in a vanilla (well, debian) Thunderbird, using our
university LDAP directory (at Dartmouth). The certificates are present under
key userCertificate;binary in the LDAP, in base64.

Alex

-
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: Get a boarding pass, steal someone's identity

2006-05-10 Thread alex

 - Original Message -
 From: Steven M. Bellovin [EMAIL PROTECTED]
 To: Perry E. Metzger [EMAIL PROTECTED]
 Subject: Re: Get a boarding pass, steal someone's identity
 Date: Mon, 8 May 2006 11:15:56 -0400
 
 
 On Mon, 08 May 2006 10:38:38 -0400, Perry E. Metzger
 [EMAIL PROTECTED] wrote:
 
 
  The person who sent this asked that I forward it anonymously.
 
  From:
  Subject: Re: Get a boarding pass, steal someone's identity
  To: Perry E. Metzger [EMAIL PROTECTED]
 
  (If you want to post this, please make it anonymous.  Thanks.)
 
  Have you noticed that airline tickets are once again de-facto  
  transferable?  If you print your own boarding pass at home, you 
  can  digitally change the name on it before you print.  If you 
  have no  bags to check, then the person who checks your ID at the 
  security  checkpoint has no way to read the bar code, and the 
  person who reads  the bar code at the gate does not check your ID.
 
 This is hardly either news or sensitive.  Schneier described it in
 CRYPTOGRAM almost 3 years ago
 (http://www.schneier.com/crypto-gram-0308.html#6), as did Eric Rescorla
 (http://www.rtfm.com/movabletype/archives/2003_10.html#000546); it's also
 been in Slate (http://www.slate.com/id/2113157/fr/rss/).
 
 

What's even more hilarious is the random body searches depend on a
code (my tickets use SS) printed on the boarding pass.  To prevent
you from erasing the code via the Paint program or similar they make
you go to a kiosk to print it out.  But, if you fly regularly, you will
know that whenever they block you from printing a ticket via the web that
this indicates you will be body searched.  So take an old electronic ticket
(if you fly regularly) without the code, change the dates, etc., print it 
out and use it to get through security without a body search.

- Alex



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


Re: wiretapping in Europe

2006-04-09 Thread Alex de Joode
On Sat, Apr 08, 2006 at 02:31:58PM -0400, Steven M. Bellovin wrote:
 
 A study at the Max Planck Institute said that Italy, followed by the
 Netherlands, does the most wiretapping.  One of the authors said:

And the sad thing is most of the Dutch tapping rooms are build by
Comverse (Mossad Inside) and are maintained not by Dutch nationals.

http://www.xs4all.nl/~ronmeul/waste/tap.html

-- 
Never be afraid to try something new. Remember, amateurs built the ark. 
   Professionals built the Titanic. (Anonymous)

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


Re: Tunnels in Hash Functions: MD5 Collisions in 40 seconds

2006-03-21 Thread alex
Any time estimates for SHA-1 or SHA-2 attacks?

- Alex

 - Original Message -
 From: [EMAIL PROTECTED]
 To: cryptography@metzdowd.com
 Subject: Tunnels in Hash Functions: MD5 Collisions in 40 seconds
 Date: Sat, 18 Mar 2006 18:05:40 +0100 (CET)
 
 
 Congratulations to Marc Stevens, who described a method for fast
 collision attack on MD5!
 
 Just now (! it is a collision !) I have finished the translation of
 my paper Vlastimil Klima: Tunnels in Hash Functions: MD5 Collisions
 Within a Minute.
 
 It is based on a new method, tunneling. Using it on MD5 it gives a
 collision in 40 seconds on a 3 GHz Pentium 4.  (Actually I used two
 times slower notebook with the time about 80 seconds.) I expect the
 publication on eprint also, but I will put in on my web together
 with the source code of the program in one or two hours. It is
 http://cryptography.hyperlink.cz/MD5_collisions.html
 
 Vlastimil Klima
 http://cryptography.hyperlink.cz/
 
 --
 Od: Weger, B.M.M. de [EMAIL PROTECTED]
 Komu: cryptography@metzdowd.com
 Predmet: MD5 collisions in one minute
 Datum: 17.3.2006 - 19:37:20
 
  Hi all,
 
  You might be interested in knowing that my MSc student
  Marc Stevens has found a considerable speedup of MD5 collision 
  generation. His improvements of Wang's method
  enables one to make MD5 collisions typically in one
  minute on a PC; sometimes it takes a few minutes, and sometimes 
  only a few seconds.
  His paper (shortly to appear on the Cryptology ePrint
  Archive) can be found on http://www.win.tue.nl/hashclash/,
  where we've also made his software available (source code
  and a Win32 executable).
  Grtz,
  Benne de Weger
 
 
 
 -
 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: 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: bounded storage model - why is R organized as 2-d array?

2006-03-09 Thread alex
 - Original Message -
 From: Travis H. [EMAIL PROTECTED]
 To: cryptography@metzdowd.com
 Subject: bounded storage model - why is R organized as 2-d array?
 Date: Thu, 2 Mar 2006 23:06:41 -0600
 
 
 Hey,
 
 In Maurer's paper, which is the last link here on the following page,
 he proposes to use a public random pad to encrypt the plaintext
 based on bits selected by a key.  What I'm wondering is why he chose
 the strange construction for encryption; namely, that he uses an
 additive (mod 2) cipher where each plaintext bit is (apparently) XORed
 against K bits from the random pad.  He also uses a 2-d array
 structure, both of which appear kind of arbitrary to me.
 
 http://www.crypto.ethz.ch/research/itc/samba/
 

This is a subject that I'm painfully familiar with.  Dr. Maurer has 
slowly but surely over the last decade or so been putting together
a solid proof of a cipher very similar in construction to Dr. Atalla's 
proprietary Tristrata cipher (US patent #6088449).  The basic idea 
is that you do something like random1 XOR random2 = pad, then pad XOR
plaintext = ciphertext. If random1 and random2 are arrays of bits 
(n-bit random numbers) from a much larger amount of random material, 
then one can tune the probability of the pad repeating to be almost
zero.  Essentially you get an equation with 2 unknowns (pad and 
plaintext), which is pretty hard to solve if the pad is hard to 
determine.  The 2-D array simplifies getting the randomX's.  
Basically you treat the initial random material as a big array of N 
random bit strings.  Each randomX value is a random strip inside 
each bit string. Each strip is the same size (at TriStrata we 
typically used four 64-Kbyte strips, each from a 250 Kbyte bit 
string).  You XOR them together and get a random pad (ours was 64 
Kbytes long).  We were able to XOR about 32 Kbytes of plaintext into
ciphertext, before an inverse matrix attack became feasible.  Then 
a new pad had to be generated for the next 32 Kbytes.

The reason people like Dr. A or Dr. M are interested in doing this
is because you can get super-fast ciphers or get some sort of 
fundamental proof about its strength that is applicable to all types
of ciphers.  The speed, from a software engineering perspective, 
results from the classic tradeoff between memory lookup and execution 
loop complexity. If one can get down to a couple of XORs and memory
copies (per 32 or 64 bit data)using ordinary microprocessor 
instructions then it will outperform AES by around a couple of orders
of magnitude. This is very useful for encrypting things like video 
streams without an expensive hardware cryptographic accelerator card.

Dr. M showed in an earlier paper that if one uses enough randomX 
values that you can get arbitarily close to generating a truly random
pad each time you need it to encrypt some ciphertext (but with N XORs!).
Anyway, the big negatives are that with this type of Vernam cipher
the entropy decays really fast, especially if the initial big source
of random bits is publicly known, the pad management is really hairy, 
and generating lots of random bits of the initial material is very 
slow. Huge numbers of pads have to be generated and distributed all 
the time, and a great deal of care has to be taken to mitigate the 
cipher's decaying strength and to avoid several types of attacks on 
the pad generation.

It is of great personal interest to me to watch Dr. M slowly prove 
that the underlying mathematics of Dr. A's Tristrata cipher may not 
have been snake oil after all.

- Alex


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


Re: NPR : E-Mail Encryption Rare in Everyday Use

2006-03-08 Thread Alex Alten

At 05:58 AM 3/3/2006 +, Ben Laurie wrote:

[EMAIL PROTECTED] wrote:
 [EMAIL PROTECTED] wrote:
 Alex Alten wrote:
 At 05:12 PM 2/26/2006 +, Ben Laurie wrote:
 Alex Alten wrote:
 At 02:59 PM 2/24/2006 +, Ben Laurie wrote:
 Ed Gerck wrote: We have keyservers for this (my chosen
 technology was PGP). If you liken their use to looking up an
 address in an address book, this isn't hard for users to grasp.

 I used PGP (Enterprise edition?) to encrypt my work emails to
 a distributed set of members last year.  We all had each
 other's
 public keys (about a dozen or so).

 What I really hated about it was that when [EMAIL PROTECTED] sent
 me an email often I couldn't decrypt it.  Why?  Because his
 firm's email server decided to put in the FROM field
 [EMAIL PROTECTED]. Since it didn't match the email name
 in his X.509 certificate's DN it wouldn't decrypt the S/MIME
 attachment. This also caused problems with replying to his email.
 It took us hours, with several experimental emails sent back and
 forth, to figure out the root of the problem.

 No wonder PKI has died commercially and encrypted email is on the
  endangered species list.
 I trust you don't think this is a problem with PKI, right? Since
 clearly the issue is with the s/w you were using.
 I place the blame squarely on X.509 PKI.  The identity aspect of it
 is all screwed up. No software implementation can overcome such a
 fundamental architectural flaw.
 OK - I'll bite - why does the sender's identity have any impact on the
 recipient's ability to decrypt?

 Because the software needs a unique ID/name to find the correct
 key to use. In practice (corporate) users can have multiple email
 names, see my reply to Peter Gutman.  This is not the fault of
 the email architecture, which has been working fine for 30-40
 years, but the fault
 of the X.509 architecture trying to piggyback on an address/name
 space that is not designed with security/cryptography
 considerations in mind.
 I have to admit to not being familiar with S/MIME, but the usual
 practice is to identify the signing key in the signature. Certainly this
 is what OpenPGP does. Its also kinda weird to refuse to decrypt just
 because the signature can't be verified.


 How does OpenPGP identify the signing key in the incoming email's 
signature?


Here's the output of one of the example programs in OpenPGP:SDK
(http://openpgp.nominet.org.uk/), showing the structure of an OpenPGP
signed file. I trust it is self-explanatory.


Assuming this file is attached to an incoming email message, how does the
receiver's email software match the Signer ID (= 0x8337FE6485F4ED64) to
a X.509 cert in his local cache that is associated with the email sender's name
(= [EMAIL PROTECTED])?


--

- Alex Alten


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


Re: NPR : E-Mail Encryption Rare in Everyday Use

2006-03-08 Thread Alex Alten

At 03:13 AM 3/6/2006 +1300, Peter Gutmann wrote:


Basically our customer required us to encrypt any team communications. So we
used PGP with email.  I know the body of the email was encrypted, and I
believe attachments were too.  The certs were used to automate the
decryption.  Basically the PGP plugin would check the incoming mail's sender
email name and try to find a local cert that had the same email name in it.

Hmm, that sounds like broken software then, since the (probabilistically)
unique keyID to locate the appropriate decryption or signature verification
key is included in the message/signature - you never have to look at the From:
address, and indeed trying to use it for key lookups would be a recipe for
disaster because of the problems you pointed out.


RFC 3280 states that an end entity's subject key id SHOULD be included. It is
not a MANDATORY extension field, see section 4.2.1.2.  So the software is
not technically broken.

Since the key id is derived from the raw public key itself,  doesn't that 
defeat

the purpose of automatically authenticating that the encrypted email is really
from [EMAIL PROTECTED]?  I'm assuming a naive email user on the receiver
side that never manually maps the key id to [EMAIL PROTECTED].  Most
general users sort of understand the email name format, it's a bit much to 
force
them to map a cryptic looking key id to it too.  Especially considering the 
user
might have dozens or hundreds of people on their mailing list.  Mapping 
mistakes

would be common.

I won't mention the questions regarding certificate revocaton vs user email 
name.

:-)

- Alex


--

- Alex Alten


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


Re: NPR : E-Mail Encryption Rare in Everyday Use

2006-02-28 Thread Alex Alten

At 05:12 PM 2/26/2006 +, Ben Laurie wrote:

Alex Alten wrote:
 At 02:59 PM 2/24/2006 +, Ben Laurie wrote:
 Ed Gerck wrote: We have keyservers for this (my chosen technology
 was PGP). If you liken their use to looking up an address in an
 address book, this isn't hard for users to grasp.

 I used PGP (Enterprise edition?) to encrypt my work emails to a
 distributed set of members last year.  We all had each other's public
 keys (about a dozen or so).

 What I really hated about it was that when [EMAIL PROTECTED] sent me
 an email often I couldn't decrypt it.  Why?  Because his firm's email
 server decided to put in the FROM field [EMAIL PROTECTED].
 Since it didn't match the email name in his X.509 certificate's DN it
 wouldn't decrypt the S/MIME attachment. This also caused problems
 with replying to his email.  It took us hours, with several
 experimental emails sent back and forth, to figure out the root of
 the problem.

 No wonder PKI has died commercially and encrypted email is on the
 endangered species list.

I trust you don't think this is a problem with PKI, right? Since clearly
the issue is with the s/w you were using.


I place the blame squarely on X.509 PKI.  The identity aspect of it is all 
screwed up.

No software implementation can overcome such a fundamental architectural flaw.

- Alex


--

- Alex Alten


-
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: NPR : E-Mail Encryption Rare in Everyday Use

2006-02-26 Thread Alex Alten

At 06:09 PM 2/24/2006 +0100, Ian G wrote:

Steven M. Bellovin wrote:

Certainly, usability is an issue.  It hasn't been solved because there's 
no market for it here; far too few people care about email encryption.


Usability is the issue.  If I look over onto
my skype window, it says there are 5 million
or so users right now.  It did that without
any of the hullabaloo of the other systems,
and still manages to encrypt my comms.  By
some measures it is the most successful crypto
system ever.


Actually the usability issue has been solved elsewhere too.  We did it over 
at TriStrata
before the firm crashed in 1998.  We allowed the system security officer to 
select the
default cipher to use in sending emails (DES, 3DES, Blowfish, RC4, etc.). 
The receiver
could use any cipher for decrypting incoming email. A sys admin installed 
some filter
software into the email client, and except for an initial login dialog (and 
we even simplified
that by hooking the OS login dialog), the user never had to do anything 
further.  The local
auth keys that he received during enrollment were encrypted with his 
password on a small

floppy disk, or could be installed on the hard drive automatically.

Last I heard (early 2005) one system was operational over in the nuclear 
engineering
department at Ohio State (for DOE work?).  Of course one old system rack in 
the

dusty corner of a school building does not a market make.

- Alex

--

- Alex Alten


-
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]


Re: Unforgeable dialog.

2006-02-03 Thread Alex Iliev
James A. Donald wrote:
 --
 One needs to differentiate dialogs brought up from within the browser
 client, which are trustworthy unless one is infected with malware,
 from popups brought up by some other web page. (Of course if popups
 are disabled except for specific sites, this is considerably less of a
 problem.)
 
 How would one construct a dialog from within Firebox so that it is
 obviously different from any unprivileged web page that attempts to
 imitate it?

This was exactly what a project in our lab addressed, a few years ago.
Check out Trusted Paths for Browsers at
http://www.cs.dartmouth.edu/~sws/research/pubs.shtml. The approach was
to have trusted windows' frames flash randomly but in synchrony with an
indicator window which is inaccessible to javascript etc. The flashing
pattern is inaccessible to unprivileged code, so cannot be spoofed.
Includes some user studies.

Alex

-- 
Alex Iliev [EMAIL PROTECTED]
Dartmouth College Computer Science
http://www.cs.dartmouth.edu/~sasho/

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


Re: quantum chip built

2006-01-13 Thread alex
From what I understand simple quantum computers can easily brute-force attack 
RSA keys or other types of PK keys.  Is ECC at risk too?  And are we at risk 
in 10, 20 or 30 years from now?  

- Alex

- Original Message -
From: Steven M. Bellovin [EMAIL PROTECTED]
To: cryptography@metzdowd.com
Subject: quantum chip built
Date: Wed, 11 Jan 2006 11:38:52 -0500

 
 http://www.wired.com/news/technology/0%2c70001-0.html?tw=wn_tophead_5
 
 ...
 
 So, on a semiconductor chip roughly the size of a postage stamp, the
 Michigan scientists designed and built a device known as an ion trap,
 which allowed them to isolate individual charged atoms and manipulate
 their quantum states.
 
 ...
 
 The new chip, which is made of gallium arsenide, should be easily
 scaled and mass-produced, because it's made using microlithography --
 the same process that makes microchips.
 
 ...
 
 
   --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
 
 
 
 -
 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: How ATM fraud nearly brought down British banking

2005-10-24 Thread Alex Alten

Is there any comparable fraud with the USA ATM system in recent decades?
I've only heard of this type of wholesale fraud in Europe or in pre-1980 USA.

- Alex

At 01:58 AM 10/22/2005 -0400, R.A. Hettinga wrote:


--- begin forwarded text


 Date: Sat, 22 Oct 2005 01:58:34 -0400
 To: Philodox Clips List [EMAIL PROTECTED]
 From: R.A. Hettinga [EMAIL PROTECTED]
 Subject: How ATM fraud nearly brought down British banking

 http://www.theregister.co.uk/2005/10/21/phantoms_and_rogues/print.html



--

- Alex Alten


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


Re: When people ask for security holes as features

2005-08-19 Thread Alex Alten

At 07:37 PM 8/18/2005 +1200, Peter Gutmann wrote:

Raymond Chen's blog has an interesting look at companies trying to bypass
Windows XP's checks that a driver has been WHQL-certified:


These guys are amateurs.  There are registery flags and COM functions that
will prevent the dialogs from popping up.  I've done it myself when developing
a driver and having to reinstall it dozens of times each day.  I've even 
disabled
XP's personal firewall to install stuff that needed to use a private port 
during
install. This was for a appliance, where we controlled the OS version, 
hardware,

etc.  So any updates to the OS we validated before allowing the user to patch
the appliance.

As a small firm we couldn't afford both the time or money to go through
Microsoft every time we updated a driver.  For other firms not using the
appliance approach to shipping software, probably thay are trying to reduce
support costs, which is not unreasonable these days.

- Alex
--

- Alex Alten


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


Re: draft paper: Deploying a New Hash Algorithm

2005-08-04 Thread Alex Alten

Steve,

At 05:34 PM 7/29/2005 -0400, Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], Alex Alten 
write

s:
At 08:12 AM 7/25/2005 -0400, Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], Alex Alten
write
s:
 Steve,
 
 This also seems to be in conjunction with the potential switch over from
 RSA et al. to
 ECC for PKI, etc.
 

Yes, Eric and I have been talking about that, and we'll add some
discussion of that to the next version of the paper.

Variable output is really needed too, say 16, 32, 64, 128, 256 and 512 bits.
And on the wishful side, the ability to optimize compression across
multiple CPUs.


That's completely orthogoal to what the paper is about.  We're talking
about how to convert to *any* new hash algorithm; we're not concerned
with which is chosen.  (I confess, though, that hash outputs of less
than 128 bits don't strike me as cryptographically useful except for
HMAC and the like.)


Sorry for going off on a tangent.

Actually 32 (or even 16) bits is really useful for retrofitting old 
insecure protocols where you
don't want to alter the header size, you only need access control, and the 
packets only exist

for less than 100 msecs.

- Alex

--

- Alex Alten


[Moderator's note: I have to strongly disagree. 16 bits is rarely, if
ever, of any use in authentication in a modern system. Even if you
think something can't live long enough to be spoofed, it usually can,
and as it turns out, attackers are often cleverer than protocol
designers. Crypto is too brittle to play such games with it. --Perry]
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: ATM machine security

2005-02-22 Thread Alex Alten
You may want to look at US Patents 4,268,715 and 4,268,715.
I believe these are among the core group of ATM patents.
- Alex
At 09:58 AM 2/17/2005 +0100, Lee Parkes wrote:
Hi,
I'm working on a project that requires a benchmark against which to judge
various suppliers. The closest that has similar requirements is the ATM
industry. To this end I'm looking for any papers, specifications or published
attacks against ATM machines and their infrastructure. I'm also looking 
for what
type of networks they use and the crypto they use to protect comms.
Also any standards would be good that the ATM industry has to adhere to.

Thanks,
Lee
--
--
[EMAIL PROTECTED] DOC #25 GLASS #136
I Need A Reason To Stand Up And Fight
Need To Believe What I See - The Silver Drop - Mnemic
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
--
- Alex
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]