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 a...@poneyhot.org writes: I have spent a couple of days looking around the Internet, and things appear to be .. erm .. hectic and disorganized. [...] Your summary pretty much answers the question, lots of bit players sitting around waiting for the market to emerge, and they've been waiting, in some cases, for at least the last decade or so. In Europe the vendors are pinning their hopes on legislation forcing people to use TSPs, although even there it's been severely crippled by the fact that having to point a legislative gun at the customers head to get them to use it doesn't engender much enthusiasm for it. These players are sitting in the wrong place then. I have run into a fairly well defined need for a timestamping service in a graphic design community. Interestingly enough they do not need the timestamps for the courts, they need them more as a deterrent to a blatant theft of their creative ideas. If someone copies their work, verbosely or at a concept level, then the clone is wortheless unless it can be sold or used as a promotion vehicle. The copycat's goal is to get the copy published in as many online galleries and auction/specwork sites as possible, and the goal of the original author is to prevent that from happening. At the moment the challenge frequently boils down to searching through archive.org contents, and using that as a proof of who was first. In this context archive.org, clearly, serves as a coarse time stamping service, implicitly trustworthy. There is obviously a room for improvement, and that's why I asked what I asked. Alex - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Entropy USB key
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: [EMAIL PROTECTED] [mailto:owner- [EMAIL PROTECTED] On Behalf Of Eric Rescorla Sent: August 20, 2008 10:31 AM To: Alex Pankratov Cc: 'theory and practice of decentralized computer networks'; cryptography@metzdowd.com Subject: Re: [p2p-hackers] IETF rejects Obfuscated TCP [snip] May I ask what you're trying to accomplish? Recall that TLS doesn't start until a TCP connection has been established, so there's aready a proof of the round trip. That said, a mechanism of this type has already been described for DTLS (RFC 4347), so no new invention would be needed. My comment was in a context of a thread discussing Obfuscated TCP. One of the suggestions was to piggyback SSL handshake on TCP handshake, to which someone pointed at an issue with SYN-flood like DoS attacks. My response was to the latter comment. Alex - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: survey of instant messaging privacy
[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 cryptography@metzdowd.com Subject: Just update the microcode (was: Re: defending against evil in all layers of hardware and software) Date: Mon, 28 Apr 2008 18:16:12 -0400 Intel and AMD processors can have new microcode loaded to them, and this is usually done by the BIOS. Presumably there is some asymmetric crypto involved with the processor doing the signature validation. A major power that makes a good fraction of the world's laptops and desktops (and hence controls the circuitry and the BIOS, even if they do not control the chip manufacturing process) would be in a good place to introduce problems that way, no? /ji - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Protection for quasi-offline memory nabbing
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
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: Ian G [mailto:[EMAIL PROTECTED] Sent: Monday, October 08, 2007 6:05 AM To: Peter Gutmann Cc: [EMAIL PROTECTED]; cryptography@metzdowd.com Subject: Re: Trillian Secure IM Peter Gutmann wrote: Alex Pankratov [EMAIL PROTECTED] writes: SecureIM handshake between two version 3.1 (latest) clients takes about .. 48 bytes. That's altogether, 32 bytes in one direction, and 16 in another. And that's between the clients that have never talked to each other before, so there's no session resuming business happenning. Or they could be using static/ephemeral DH with fixed shared DH key values, which isn't much better. (This is just speculation, it's hard to tell without knowing what the exchanged quantities are). Speculation is fun. But, opportunistic cryptography is even more fun. It is very encouraging to see projects implement cryptography in limited forms. A system that uses a primitive form of encryption is many orders of magnitude more secure than a system that implements none. Primitive form - maybe, weak form - absolutely not. It is actually worse than having no security at all, because it tends to create an _illusion_ of protection. Which is by the way exactly the case with SecureIM. How hard is it to brute-force 128-bit DH ? My guesstimate is it's an order of minutes or even seconds, depending on CPU resources. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
another Skype worm attack via IM
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: 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.
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]
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
Damien Miller wrote: On Wed, 15 Mar 2006, Ed Gerck wrote: [snip] ...allows the detection of man-in-the-middle (MiTM) attacks by displaying a short authentication string for the users to read and compare over the phone. Depends on the trust model. May not work. This is incomplete. The paragraph goes on to say: we still get fairly decent authentication against a MiTM attack, based on a form of key continuity. It does this by caching some key material to use in the next call, to be mixed in with the next call's DH shared secret, giving it key continuity properties analogous to SSH. Here's a quote from the draft - We use an analogous baby duck security model to authenticate the DH exchange in ZRTP. We don't need to exchange persistent public keys, we can simply cache a shared secret and re-use it to authenticate a long series of DH exchanges for secure phone calls over a long period of time. If we read aloud just one SAS, and then cache a shared secret for later calls to use for authentication, no new voice authentication rituals need to be executed. We just have to remember we did one already. The draft says that shared secrets are keyed by ZID when stored in a local cache, where ZID is a unique persistent random ZRTP endpoint ID. Unless I am missing something, ZIDs exchanged by peers during a handshake remain unauthenticated. This means that if both A and B have cached shared secrets with M, then M can mount MitM attack against A-B session and both A and B will be under the impression that they are protected by 'key continuity' from their previous (A-B) session. Their SAS won't match of course, but since they see shared secret being used for KE, they are not likely to bother with SAS check. Alex - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Zfone and ZRTP :: encryption for voip protocols
That's not what I described. An attacker uses his own ZID and valid shared secrets that he creates with A and B on some prior occassion. In other words - * M talks to A as himself. This creates cached AM secret. * M talks to B as himself. This creates cached BM secret. * M intercepts A-B handshake and completes each 'leg' of the handshake using his own ZID and above secrets. Since responder's ZID in not a part of a hash in Commit, this key exchange will complete just fine. I don't see the draft talking about how/if ZIDs might be linked to non-ZRTP peer's identities, so I can't see how A or B can actually discover that they've been MitM'd by M *unless* they do SAS check. They do however see that KE used cached shared secret, and they (being humans) are likely to skip SAS check because of that. Alex Philip Zimmermann wrote: An attacker can easily present the wrong ZID, but he will not possess the cached shared secrtes held by the real owner of that ZID. The user interface will tell the user that there are no shared secrets, which means he must reverify the SAS. Thus, his attack will fail. On Mar 17, 2006, at 4:21 PM, Alex Pankratov wrote: Damien Miller wrote: On Wed, 15 Mar 2006, Ed Gerck wrote: [snip] ...allows the detection of man-in-the-middle (MiTM) attacks by displaying a short authentication string for the users to read and compare over the phone. Depends on the trust model. May not work. This is incomplete. The paragraph goes on to say: we still get fairly decent authentication against a MiTM attack, based on a form of key continuity. It does this by caching some key material to use in the next call, to be mixed in with the next call's DH shared secret, giving it key continuity properties analogous to SSH. Here's a quote from the draft - We use an analogous baby duck security model to authenticate the DH exchange in ZRTP. We don't need to exchange persistent public keys, we can simply cache a shared secret and re-use it to authenticate a long series of DH exchanges for secure phone calls over a long period of time. If we read aloud just one SAS, and then cache a shared secret for later calls to use for authentication, no new voice authentication rituals need to be executed. We just have to remember we did one already. The draft says that shared secrets are keyed by ZID when stored in a local cache, where ZID is a unique persistent random ZRTP endpoint ID. Unless I am missing something, ZIDs exchanged by peers during a handshake remain unauthenticated. This means that if both A and B have cached shared secrets with M, then M can mount MitM attack against A-B session and both A and B will be under the impression that they are protected by 'key continuity' from their previous (A-B) session. Their SAS won't match of course, but since they see shared secret being used for KE, they are not likely to bother with SAS check. Alex -- Philip R Zimmermann[EMAIL PROTECTED] http://philzimmermann.com tel +1 650 322-7223 (spelled with 2 n's) fax +1 650 322-7877 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: bounded storage model - why is R organized as 2-d array?
- 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 05:58 AM 3/3/2006 +, Ben Laurie wrote: [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Alex Alten wrote: At 05:12 PM 2/26/2006 +, Ben Laurie wrote: Alex Alten wrote: At 02:59 PM 2/24/2006 +, Ben Laurie wrote: Ed Gerck wrote: We have keyservers for this (my chosen technology was PGP). If you liken their use to looking up an address in an address book, this isn't hard for users to grasp. I used PGP (Enterprise edition?) to encrypt my work emails to a distributed set of members last year. We all had each other's public keys (about a dozen or so). What I really hated about it was that when [EMAIL PROTECTED] sent me an email often I couldn't decrypt it. Why? Because his firm's email server decided to put in the FROM field [EMAIL PROTECTED]. Since it didn't match the email name in his X.509 certificate's DN it wouldn't decrypt the S/MIME attachment. This also caused problems with replying to his email. It took us hours, with several experimental emails sent back and forth, to figure out the root of the problem. No wonder PKI has died commercially and encrypted email is on the endangered species list. I trust you don't think this is a problem with PKI, right? Since clearly the issue is with the s/w you were using. I place the blame squarely on X.509 PKI. The identity aspect of it is all screwed up. No software implementation can overcome such a fundamental architectural flaw. OK - I'll bite - why does the sender's identity have any impact on the recipient's ability to decrypt? Because the software needs a unique ID/name to find the correct key to use. In practice (corporate) users can have multiple email names, see my reply to Peter Gutman. This is not the fault of the email architecture, which has been working fine for 30-40 years, but the fault of the X.509 architecture trying to piggyback on an address/name space that is not designed with security/cryptography considerations in mind. I have to admit to not being familiar with S/MIME, but the usual practice is to identify the signing key in the signature. Certainly this is what OpenPGP does. Its also kinda weird to refuse to decrypt just because the signature can't be verified. How does OpenPGP identify the signing key in the incoming email's signature? Here's the output of one of the example programs in OpenPGP:SDK (http://openpgp.nominet.org.uk/), showing the structure of an OpenPGP signed file. I trust it is self-explanatory. Assuming this file is attached to an incoming email message, how does the receiver's email software match the Signer ID (= 0x8337FE6485F4ED64) to a X.509 cert in his local cache that is associated with the email sender's name (= [EMAIL PROTECTED])? -- - Alex Alten - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
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: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
I replied to Tero privately, then realized that I was not the only recipient of his email. So here's a copy for everyone's reference. Alex Tero Kivinen wrote: Travis H. writes: http://www.hamachi.cc/security Based on a cursory look over this, I'm impressed by both the level of detail and the level of security apparently afforded. Too bad I can't see the source code. I can see couple of problems in the system. Firstly it seems it uses same key for both directions for the encryption and for authentication, i.e. the KEYMAT is only split to Ke and Ka keys, which are used for encryption and authentication. In general using same keys for different directions is bad. The description on a page was not updated properly. Recent clients use per-direction keys after they complete P2P KE. Secondly I cannot find where it authenticates the crypto suite used at all (it is not included in the signature of the AUTH message). Crypto suite is essentially just a protocol number. It requires no authentication. If the server side responds with HELO.OK, it means that it can comprehend specified protocol revision. Similar to what happens during the SSH handshake. Also it seems that the identity itself is not authenticated at all, as it (or it's MACed form) is not included in the signature. It is not. There might be (I am not sure whether AUTH packet is encrypted and MACed) a MAC over it, but the MAC key is not yet authenticated as it is generated from the anonymous Diffie-Hellman. That might give it some protection, but I am not sure if that is enough. A protection against what kind of attack ? Identity is used to specify which public key the client wants to be authenticated with on the server side. Assuming it is swapped in transition by a man in the middle, it would still require an attacker to re-sign authentication hash in the message. Assuming he has a private key to do that, he will effectively succeed in authenticating under substituted ID. He then will need to re-sign server's auth hash to complete the attack, which is not going to happen. There is an off chance that the attacker might swapped the identity to one that has the same public key. The chances of this happening are infinitely small unless an attacker also has an access to victim's keypair, which becomes a trivial attack case. The protocol description is missing some details, so cannot say anything about them (things like what is the format of Ni, Nr, Gi, Gr when sent over wire and when put to the signatures etc, are the Gi, Gr always the lenght of modulus (2048 bits) etc). What would you like to know exactly ? The page was not meant to be a bit-level description of messages, merely a description of the security framework. The protocol is also tied to use SHA1. If you are referring to HMAC-SHA1 for authentication hashes, it is a part of a crypto suite (protocol revision) spec. In general it would be much better to use standard protocol, instead of generating your own. This is the second revision of Hamachi system. First revision was using SSL for cli-srv and IKE/ESP for p2p security. It was a prototype and it soon become obvious that both SSL and IKE were overkills for our purposes. We did not need certificate authentication of SSL, we did not want to run our own auth protocol over SSL/AnonDH, which would've increased the number of packets per login sequence. We didn't need the flexibility (ie complexity) of IKE either. After stripping down IKE (ie removing SA negotiation, reworking ID payloads and not doing quick mode), we essentially ended up with a protocol that was also fit for securing cli-srv session. It was further tweaked and replaced SSL. I should probably add that I implemented IKE (v1) keying daemon from scratch with all bells and wistles (NATT, extended MODP groups, etc) at some point in the past. Some remnants of it are still floating around, the library name was libike. Designing security protocols is hard... Yes, it is. This is why I like it. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
At 06:09 PM 2/24/2006 +0100, Ian G wrote: Steven M. Bellovin wrote: Certainly, usability is an issue. It hasn't been solved because there's no market for it here; far too few people care about email encryption. Usability is the issue. If I look over onto my skype window, it says there are 5 million or so users right now. It did that without any of the hullabaloo of the other systems, and still manages to encrypt my comms. By some measures it is the most successful crypto system ever. Actually the usability issue has been solved elsewhere too. We did it over at TriStrata before the firm crashed in 1998. We allowed the system security officer to select the default cipher to use in sending emails (DES, 3DES, Blowfish, RC4, etc.). The receiver could use any cipher for decrypting incoming email. A sys admin installed some filter software into the email client, and except for an initial login dialog (and we even simplified that by hooking the OS login dialog), the user never had to do anything further. The local auth keys that he received during enrollment were encrypted with his password on a small floppy disk, or could be installed on the hard drive automatically. Last I heard (early 2005) one system was operational over in the nuclear engineering department at Ohio State (for DOE work?). Of course one old system rack in the dusty corner of a school building does not a market make. - Alex -- - Alex Alten - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: hamachi p2p vpn nat-friendly protocol details
Travis H. wrote: On 2/24/06, Alex Pankratov [EMAIL PROTECTED] wrote: Tero Kivinen wrote: [snip] The protocol description is missing some details, so cannot say anything about them (things like what is the format of Ni, Nr, Gi, Gr when sent over wire and when put to the signatures etc, are the Gi, Gr always the lenght of modulus (2048 bits) etc). What would you like to know exactly ? The page was not meant to be a bit-level description of messages, merely a description of the security framework. Presumably he wants to make sure that the messages like the following have an unambiguous interpretation: AUTH Identity Signature(Ni | Nr | Gi | Gr, Kpri_cli) Merely concatenating them is insufficient unless all but one have a fixed length. I think a terse unambiguous representation rationale is the whole reason for ASN.1, although it seems awfully complex for such a simple goal. Nonces and DH exponents are serialized using PER-style ASN.1 encoding. So the whole concatenation is unambigious. I sort of wonder at the utility of a TCP implementation of the p2p VPN... tunnelling TCP over TCP is well known to be a Bad Thing with regard to interaction of the TCP timeouts. Just to be clear, Hamachi tunnels VPN/P2P traffic over UDP. TCP is used for client-server session only. VPN over TCP is bad for two reasons. One you listed, and another is that it becomes trivial to DoS this kind of VPN. TCP packets are not authenticated (unless MD5/BGP extension is used, which is unlikely), so the state of VPN transport layer and consequently the state of a tunnel can be altered by 3rd party. That's why SSL VPNs make very little sense in non-proxied setups and that's why (I'd guess) OpenVPN 'tweaked' SSL to run over UDP instead. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Unforgeable dialog.
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
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]
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]
