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