RE: Trusted timestamping
> -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" 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
Trusted timestamping
Does anyone know what's the state of affairs in this area ? This is probably slightly off-topic, but I can't think of a better place to ask about this sort of thing. I have spent a couple of days looking around the Internet, and things appear to be .. erm .. hectic and disorganized. There is for example timestamp.verisign.com, but there is no documentation or description of it whatsoever. Even the website itself is broken. However it is used by Microsoft's code signing tool that embeds Verisign's timestamp into Authenticode signature of signed executable files. There is also a way to timestamp signed PDFs, but the there appears to be nothing _trusted_ about available Trusted Timestamping Authorities. Just a bunch of random companies that call themselves that way and provide no indication why they should actually be *trusted*. No audit practicies, not even a simple description of their backend setup. The same goes for the companies providing timestamping services for arbitrary documents, either using online interfaces or a downloadable software. There are also Digital Poststamps, which is a very strange version of a timestamping service, because their providers insist on NOT releasing the actual timestamp to the customer and then charging for each timestamp verification request. I guess my main confusion at the moment is why large CAs of Verisign's size not offering any standalone timestamping services. Any thoughts or comments ? Thanks, Alex - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Entropy USB key
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
> -Original Message- > From: Eric Rescorla [mailto:[EMAIL PROTECTED] > Sent: August 20, 2008 12:29 PM > To: Alex Pankratov > Cc: 'Eric Rescorla'; 'theory and practice of decentralized computer > networks'; cryptography@metzdowd.com > Subject: Re: [p2p-hackers] IETF rejects Obfuscated TCP > > At Wed, 20 Aug 2008 11:59:48 -0700, > Alex Pankratov wrote: > > > 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. > > Well, as I stated in the original discussion on obfuscated TCP (on > TCPM), I'm not convinced that the latency problem is that severe, and > if it is there are a number of potential performance improvements one > could make to TLS before one started screwing around with TCP. Based on this reply alone I'm not sure I follow. I also read quickly through your exchange on TCPM and your comments appear to be specific to Adam's draft. My comment was not related to either a latency or a potential performance problems of TLS. It was in a response to another idea - that of bundling TLS handshake with TCP handshake. The goal of this (and I apologize for stating the obvious, just want to make sure we are on the same page here) is to provide transparent to application layer opportunistic encryption of TCP streams. Whether this goal makes any sense and if it is worth pursuing is a separate issue; it's the DoS aspect of the implementation idea that I was commenting on. Alex - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: [p2p-hackers] IETF rejects Obfuscated TCP
> -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: [p2p-hackers] IETF rejects Obfuscated TCP
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: survey of instant messaging privacy
[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)
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 > 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
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
> - 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)
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
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
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
Sorry for the long delay in responding, I was traveling out of "radio range" this week. At 06:23 PM 1/4/2008 -0500, Leichter, Jerry wrote: | > | ...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) | > Why not just require that the senders of malign packets set the Evil Bit | > in their IP headers? | > | > How can you possibly require that encrypted traffic *generated by the | > attackers* will allow itself to be inspected? | | You misunderstand me. We can for the most part easily identify | encrypted data, either it is using a standard like SSL or it is | non-standard but can be identified by data payload characteristics | (i.e. random bits). If it is a standard (or even a defacto standard | like Skype) we can require access under proper authority. If it is | not (or access under authority is refused), then just simply block or | drop the packets, there's no need to inspect them. Just because it *looks* like SSL doesn't mean that the key it leaks to you is actually valid. And if it *is* actually valid, it doesn't mean that there isn't a second layer of encryption inside the SSL session. 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. 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. Go back to my example: How will you distinguish between random bits and a compressed video stream? Do you assume that every codec in the world will be registered? How about a big scientific dataset of floating point values? Or some huge, validly formatted, spreadsheet of such values? Well, in order to be useful, codecs need to be well known. If unknown then they probably follow well known algorithms and thus probably be ameniable to dogged digital forensics. And that doesn't even consider obvious countermeasures. What happens if you decrypt and see a bunch of ASCII values that follow the first and second order statistics of English text? Sure, encoding my encrypted data like that costs me some overhead - but given the speed of today's networks, who cares? Sure, but then interoperability goes out the window, and I'm pretty sure that most thieves and attackers are not going to rebuild complex protocol stacks and textual parsers from scratch. This is what software reuse is all about. In the case of botnet control lines then this may be more likely but it seems to me that once you identify the suspicious packet flows (which you are of course looking for on the infected machine), that dedicated forensics analysis can be done successfully. These packets would probably have some sort of anomolous signature compared to more normal packets of the same nature. Also, don't forget, at the very least L4 signature information will never be encrypted, otherwise it would be unroutable. And remember even if you can decrypt the botnet control lines (which still must do key distribution/exchanges over the same comm links as the victim computers so it should be possible to intecept them) you can certainly block them with something like a Cisco guard. This train left the station a *long* time ago. So it's not so clear that the train has even left the station. - Alex -- Alex Alten [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Death of antivirus software imminent
At 05:47 PM 1/4/2008 -0500, Leichter, Jerry wrote: | ...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) Why not just require that the senders of malign packets set the Evil Bit in their IP headers? How can you possibly require that encrypted traffic *generated by the attackers* will allow itself to be inspected? You misunderstand me. We can for the most part easily identify encrypted data, either it is using a standard like SSL or it is non-standard but can be identified by data payload characteristics (i.e. random bits). If it is a standard (or even a defacto standard like Skype) we can require access under proper authority. If it is not (or access under authority is refused), then just simply block or drop the packets, there's no need to inspect them. - Alex -- Alex Alten [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Death of antivirus software imminent
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
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
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
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
> -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
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
> -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
> -Original Message- > From: pgut001 [mailto:[EMAIL PROTECTED] > Sent: Monday, October 08, 2007 7:52 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Cc: cryptography@metzdowd.com > Subject: Re: Trillian Secure IM > > Marcos el Ruptor <[EMAIL PROTECTED]> writes: > > >I found those threads: > > > >http://forums.ceruleanstudios.com/showthread.php?t=53433 > > > >http://forums.ceruleanstudios.com/showthread.php?t=56207 > > One of them contains a link to an older thread: > > http://www.ceruleanstudios.com/forums/showthread.php?s=&threadid=33279 > > with this gem: > > Speaking as a software developer, if I ever had someone on > my forums who's posts consisted solely of questions about > how my private encryption systems work [an earlier post by > a crypto-savvy person had asked about use of DH primes, the > block cipher encryption mode used, and so on], I would ban > them and report them to their ISP without a second thought. > > If you're interested in creating good encryption, learn the > principles: encryption schemes are weakened when they are based > on someone else's work. So if you're honestly wanting to make > good encryption for Trillian, its a bad idea to try to use CS's > work as a base. Funny enough, his conclusion *is* correct :) Alex - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Trillian Secure IM
> -Original Message- > From: Marcos el Ruptor [mailto:[EMAIL PROTECTED] > Sent: Monday, October 08, 2007 6:21 AM > To: Alex Pankratov > Cc: cryptography@metzdowd.com > Subject: Re: Trillian Secure IM > > I found those threads: > > http://forums.ceruleanstudios.com/showthread.php?t=53433 > > http://forums.ceruleanstudios.com/showthread.php?t=56207 > > As you can see from the last post in the second thread, ultimately > they agreed that 128-bit DH is secure and that I am just some crazy > guy trying to scare them. Yickes. Ignorance is a bliss. I am actually curious to see what was the DH modulus size in T's versions that were blocked by AOL. Given T's installation base, strong SecureIM would've dramatically complicated "lawful intercepts", which AOL is probably required to implement. Alex - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Trillian Secure IM
> -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]
Trillian Secure IM
Hi, I've been poking around Oscar (ICQ/AIM) protocol parsing and had a look at Trillian's SecureIM handshake protocol. For those who don't know, Trillian is a very popular multi- protocol instant messanging application for Windows. One of its notable features, for which is got some rave/positive reviews, is an ability to encrypt ICQ/AIM IMs exchanged by two Trillian instances. AOL made repeated attempts to block SecureIM, but eventually stopped them [1]. The protocol is closed, but it was reversed engineered by some guys over at GAIM project. It appeared to be a Blowfish encryption of bulk IMs using a key derived from an anonymous DH exchange [2]. This was also indirectly confirmed by another project [3]. Leaving aside the lack of authentication and replay protection, here's what is even more striking - 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. If that's DH exchange, then it's 128 bit one. Fertile ground for some interesting speculation, don't you think ? Alex [1] http://en.wikipedia.org/wiki/Trillian_%28instant_messenger%29#Entry_into_mai nstream_and_the_.22IM_Wars.22 [2] http://sourceforge.net/tracker/download.php?group_id=235&atid=300235&file_id =56799&aid=777300 [3] http://code.google.com/p/joscar/wiki/TrillianSecureIm - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
another Skype worm attack via IM
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
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: Susan Landau Op Ed on new NSA powers
It seems that a large chunk (and probably relative soon nearly all) voice is now via VoIP. And to date, Skype not withstanding, this has all been cleartext traffic. Using router netflow records, etc., one can now pinpoint any phone conversation and then do a pcap dump. Many Tier 1 through Tier 3 internet carriers are now deploying this type of L7 deep packet inspection directed analysis. Currently they are limited to about 10 Gbps (L4 DPI), but soon 40 Gbps will be available. - Alex Alten At 05:12 PM 8/9/2007 -0400, Perry E. Metzger wrote: http://www.washingtonpost.com/wp-dyn/content/article/2007/08/08/AR2007080801961.html Selected quote: To avoid wiretapping every communication, NSA will need to build massive automatic surveillance capabilities into telephone switches. Here things get tricky: Once such infrastructure is in place, others could use it to intercept communications. Grant the NSA what it wants, and within 10 years the United States will be vulnerable to attacks from hackers across the globe, as well as the militaries of China, Russia and other nations. Perry - 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: A secure Internet requires a secure network protocol
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
> [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?
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?
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
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)
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.
some thoughts about Oracle's security breach (by SAP)
It seems to me that this could have been prevented (or better damage control) by: 1) encrypting the files 2) putting in place good access controls (policy adjudication and enforcement) examples: if more than 100 files / week then raise alert if customer access incorrect areas /directories raise an alert 3) possibly better auditing in place to assist after-the-fact forensics (this might have reduced the scope of the theft by allowing a more timely response) In other words a good security system to secure and protect the customer support files against insider attack (a hacker using a legitimate customer login). http://www.nytimes.com/reuters/business/business-rpt-update.html http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2007/03/22/BUG32OPUKU7.DTL http://www.oracle.com/sapsuit/index.html - Alex -- Alex Alten [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: gang uses crypto to hide identity theft databases
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
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 ?
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 ?
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]
OpenSSL PKCS #7 supports AES & SHA-2 ?
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: switching from SHA-1 to Tiger ?
> - 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?
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?
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
> - 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
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
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
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: Zfone and ZRTP :: encryption for voip protocols
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: bounded storage model - why is R organized as 2-d array?
At 06:13 PM 3/9/2006 +, Ben Laurie wrote: Steven M. Bellovin wrote: > On Thu, 09 Mar 2006 02:10:58 -0500 > [EMAIL PROTECTED] wrote: > >> This is very useful for encrypting things like video >> streams without an expensive hardware cryptographic accelerator card. >> > I think you vastly overestimate how much hardware one needs to do > something like AES. I ran > > dd if=/dev/zero bs=32k count=1024| openssl speed aes-128-cbc I presume you were expecting this to test encrypting a long stream of data. It doesn't. "openssl speed" does encryption internally - the stuff on stdin was ignored. Something like: dd if=/dev/zero bs=32k count=1024 | openssl enc -aes-128-cbc > /dev/null is probably what you want (untested). You have to be careful. I meant in regards to the incremental overhead of the cipher once the cleartext is loaded from DRAM into L1 cache. And the cleartext data is constantly streaming in enough to cause the L1 cache to be refreshed constantly during the timing test. Of course if the Vernam cipher's pad is constantly loading in too, then it's DRAM overhead must be counted against it. The best ones tend to place as much of the original random material as possible in L1 and randomly remix the pads inside. It's very tricky, balancing speed against the decay rate of the cipher (and countering things like partial key attacks). - Alex -- - Alex Alten - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: bounded storage model - why is R organized as 2-d array?
> - 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
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
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 +0000, 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
> 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. - Alex - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: hamachi p2p vpn nat-friendly protocol details
Tero Kivinen wrote: > Alex Pankratov writes: > >>>>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 ? >> [snip] > > So the identity is authenticated because the server uses the identity > given by the client to search the public key from his database and > then uses that public key to check the signature? Yes. > I think that should be enough, but I wasn't sure how the server > works with the public keys, i.e. what kind of registration is done, > and how it makes sure there is no duplicate identities created for > different public keys etc. Actually it is not clear what purpose the > identity itself has. If the only purpose is to identify the public key > already stored in the server, then hash of the public key would be > better, but if that ID is assigned by the server on the first > registration, then it is probably ok. It's assigned on the first contact. >>>>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. > > > Yes, it is part of the crypto suite, and that is not authenticated. > I.e. if / when the SHA1 is completely broken, in a way that also > HMAC-SHA1 is broken, then only way to change it is to put out new code > that supports new crypto suite (with some other hash/mac) and as the > crypto suite is not authenticated, then attacker can cause downgrading > attacks forcing client and server to use the broken crypto suite. Should switching to new crypto suite be required, new revision will authenticate suite ID, and this should prevent downgrading attacks. This will work because the suite is not negotiated, but rather pre-selected by the client. All in all I agree that both Identity and Suite should be included into the hash. We'll make the change to a protocol. > Looking at the latest development of the breaking of the hash > algorithms, it would be better to make sure that the algorithm > designed now would be crypto agile, i.e. make sure they do allow > different crypto algorithms, and allows easy adding of new algorithms. Well, if one want to avoid *binary* upgrade in the event of a suite being rendered useless, the binary needs to support all known cipher/digest/mac algorithms and the protocol needs to allow for defining suites dynamically. I am not aware of any protocol that has this property. Which means that should HMAC-SHA1 gets broken, all existing binaries would still require an upgrade regardless of whether how hard it is to add/replace the algorithms. In our case all crypto resides in a single module behind generic interface. Swapping it for an implementation that uses different algorithms is a matter of minutes. >>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. > > > Now there is the IKEv2 which is much bigger improvement over IKEv1, > especiallty if profiling it suitably (i.e. use raw RSA keys instead of > certificates etc). I looked at IKEv2 and JFK when we just started. It was a couple of years ago, IKEv2 was still pretty much in a discussion phase, so it was as good of an option as a custom protocol. It's RFC'd now, I will give it another read. As a side note I want to add that there're no illusions that given two versions of the system - one based on a custom protocols and one based on a standard ones - the second one is a better choice for many reasons. We had our reasons to go with a custom protocol for the first version and it seems to have worked out to be reasonably good. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
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
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: NPR : E-Mail Encryption Rare in Everyday Use
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: NPR : E-Mail Encryption Rare in Everyday Use
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. - Alex -- - Alex Alten - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: hamachi p2p vpn nat-friendly protocol details
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: Unforgeable dialog.
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
At 03:04 AM 1/14/2006 +1100, Michael Cordover wrote: John Denker wrote: [EMAIL PROTECTED] wrote: From what I understand simple quantum computers can easily brute-force attack RSA keys or other types of PK keys. My understanding is that quantum computers cannot "easily" do anything. Au contraire, quantum computers can easily perform prime factoring or perform discrete logarithms - this is Shor's algorithm and has been known for more than a decade. The difficulty is in making a QC. Is ECC at risk too? And are we at risk in 10, 20 or 30 years from now? ECC is also at risk because it relies on the difficulty of discrete logarithms which are victim to a quantum attack. Are we at risk in 10, 20 or 30 years? Well, as John said, it's hard to say. The first working 2 qbit computers were demonstrated in 1998, then 3 qbits in the same year. 7 qbits were demonstrated in 2000. 8 in December 2005. As you can see, adding a qbit is pretty hard. In order to factor a 1024 bit modulus you'd need a 1024 bit QC. Perhaps if there were some sudden breakthrough it'd be a danger in a decade - but this is the same as the risk of a sudden classical breakthrough: low. My assessment: nothing to worry about for now or in the immediate future. A key valid for 20 years will face much greater dangers from expanding classical computer power, weak implementations, social engineering etc. The "quantum chip" is just a new housing, not anything that puts RSA or ECC at risk. Hmm, extrapolating forward... 1998 = 2 qubits 2005 = 8 qubits (a 4x increase in 7 years) 2013 = 32 qubits? 2020 = 128 qubits? 2027 = 512 qubits? 2034 = 2048 qubits? So, say, somewhere between 20 to 30 years from now current RSA moduli may possibly be at risk from the Shor's algorithm. Is that a reasonable assumption? If so, would ECC (moduli) also be at risk within this time frame? - Alex -- - Alex Alten - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: quantum chip built
>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
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]
status of SSL vs SHA-1/MD-5, etc.?
Everyone, So where do we stand with secure networking protocols vs SHA-1/MD-5? Is SSL at risk? Is TLS OK (because of HMAC)? SSH, IPSec, etc? - Alex -- - Alex Alten - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: When people ask for security holes as features
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"
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
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]
