Re: Crypto dongles to secure online transactions
Peter Gutmann wrote: external data from finding its way onto their corporate networks (they are really, *really* concerned about this). If you wanted this to work, you'd need to build a device with a small CMOS video sensor to read data from the browser via QR codes and return little more than a 4-6 digit code that the user can type in (a MAC of the transaction details or something). It's feasible, but not quite what you were thinking of. That reminds me of the Lenslok copy protection device on the Elite (and others) game from the '80s[1] [1] http://www.birdsanctuary.co.uk/sanct/s_lenslok.php -- Darren J Moffat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: AES-CBC + Elephant diffuser
Eugen Leitl wrote: We discuss why no existing cipher satisfies the requirements of this application. Uh-oh. http://www.microsoft.com/downloads/details.aspx?FamilyID=131dae03-39ae-48be-a8d6-8b0034c92555DisplayLang=en AES-CBC + Elephant diffuser Brief Description A Disk Encryption Algorithm for Windows Vista ^^^ That is the key issue here, it is a disk encryption algorithm independent of the filesystem that sits above it. If instead you put the encryption directly into the filesystem, rather than below it, then the restrictions of sector size that mean you can't easily use a MAC go away. This is exactly what we have done for ZFS, we do use a MAC (the one from CCM or GCM modes) as well as a SHA256 hash of the ciphertext (used for resilvering operations in RAID) and they are stored in the block pointers (not the data blocks) forming a Merkle tree. We also have a place to store an IV. So every encrypted ZFS block is self contained, has an IV and a 16 byte MAC. This means that the crypto is all standards based algorithms and modes for ZFS. http://hub.opensolaris.org/bin/view/Project+zfs-crypto/ -- Darren J Moffat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Truncating SHA2 hashes vs shortening a MAC for ZFS Crypto
For the encryption functionality in the ZFS filesystem we use AES in CCM or GCM mode at the block level to provide confidentiality and authentication. There is also a SHA256 checksum per block (of the ciphertext) that forms a Merkle tree of all the blocks in the pool. Note that I have to store the full IV in the block. A block here is a ZFS block which is any power of two from 512 bytes to 128k (the default). The SHA256 checksums are used even for blocks in the pool that aren't encrypted and are used for detecting and repairing (resilvering) block corruption. Each filesystem in the pool has its own wrapping key and data encryption keys. Due to some unchangeable constraints I have only 384 bits of space to fit in all of: IV, MAC (CCM or GCM Auth Tag), and the SHA256 checksum, which best case would need about 480 bits. Currently I have Option 1 below but I the truncation of SHA256 down to 128 bits makes me question if this is safe. Remember the SHA256 is of the ciphertext and is used for resilvering. Option 1 IV 96 bits (the max CCM allows given the other params) MAC 128 bits ChecksumSHA256 truncated to 128 bits Other options are: Option 2 IV 96 bits MAC 128 bits ChecksumSHA224 truncated to 128 bits Basically if I have to truncate to 128 bits is it better to do it against SHA224 or SHA256 ? Option 3 IV 96 bits MAC 128 bits ChecksumSHA224 or SHA256 truncated to 160 bits Obviously better than the 1 and 2 but how much better ? The reason it isn't used just now is because it is slightly harder to layout given other constrains in where the data lives. Option 4 IV 96 bits MAC 32 bits ChecksumSHA256 at full 256 bits I'm pretty sure the size of the MAC is far to small. Option 5 IV 96 bits MAC 64 bits ChecksumSHA224 at full 224 bits This feels like the best compromise, but is it ? Option 6 IV 96 bits MAC 96 bits ChecksumSHA224 or SHA256 truncated to 192 bits -- Darren J Moffat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: FileVault on other than home directories on MacOS?
Ivan Krsti wrote: TrueCrypt is a fine solution and indeed very helpful if you need cross-platform encrypted volumes; it lets you trivially make an encrypted USB key you can use on Linux, Windows and OS X. If you're *just* talking about OS X, I don't believe TrueCrypt offers any advantages over encrypted disk images unless you're big on conspiracy theories. Note my information may be out of date. I believe that MacOS native encrypted disk images (and thus FileVault) uses AES in CBC mode without any integrity protection, the Wikipedia article seems to confirm that is (or at least was) the case http://en.wikipedia.org/wiki/FileVault There is also a sleep mode issue identified by the NSA: http://crypto.nsa.org/vilefault/23C3-VileFault.pdf TrueCrypt on the other hand uses AES in XTS mode so you get confidentiality and integrity. -- Darren J Moffat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: AES-GMAC as a hash
Hal Finney wrote: Darren J Moffat darren.mof...@sun.com asks: Ignoring performance for now what is the consensus on the suitabilty of using AES-GMAC not as MAC but as a hash ? Would it be safe ? The key input to AES-GMAC would be something well known to the data and/or software. No, I don't think this would work. In general, giving a MAC a fixed key cannot be expected to produce a good hash. With AES-GMAC in particular, it is unusual in that it has a third input (besides key and data to MAC), an IV, which makes your well-known-key strategy problematic. And even as a MAC, it is very important that a given key/IV pair never be reused. Fixing a value for the key and perhaps IV would defeat this provision. But even ignoring all that, GMAC amounts to a linear combination of the text blocks - they are the coefficients of a polynomial. The reason you can get away with it in GMAC is because the polynomial variable is secret, it is based on the key. So you don't know how things are being combined. But with a known key and IV, there would be no security at all. It would be linear like a CRC. Thanks, that is pretty much what I suspected would be the answer but you have more detail than I could muster in my head at a first pass on this. Thanks. -- Darren J Moffat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: SHA-1 and Git (was Re: [tahoe-dev] Tahoe-LAFS key management, part 2: Tahoe-LAFS is like encrypted git)
Ben Laurie wrote: Perry E. Metzger wrote: Yet another reason why you always should make the crypto algorithms you use pluggable in any system -- you *will* have to replace them some day. In order to roll out a new crypto algorithm, you have to roll out new software. So, why is anything needed for pluggability beyond versioning? Versioning catches a large part of it, but that alone isn't always enough. Sometimes for on disk formats you need to reserve padding space to add larger or differently formatted things later. Also support for a new crypto algorithm can actually be done without changes to the software code if it is truely pluggable. An example from Solaris that is how our IPsec implementation works. If a new algorithm is available via the Solaris crypto framework in many c cases were we don't need any code changes to support it, just have the end system admin run the ipsecalgs(1M) command to update the IPsec protocol number to crypto framework algorithm name mappings (we use PKCS#11 style mechanism names that combine algorithm and mode). The Solaris IPSec implementation has no crypto algorithm names in the code base at all (we do currently assume CBC mode though but are in the process of adding generic CCM, GCM and GMAC support). Now having said all that the PF_KEY protocol (RFC 2367) between user and kernel does know about crypto algorithms. It seems to me protocol designers get all excited about this because Not just on the wire protocols but persistent on disk formats, on disk is a much bigger deal. Consider the case when you have terrabytes of data written in the old format and you need to migrate to the new format - you have to support both at the same time. So not just versioning but space padding can be helpful. -- Darren J Moffat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Unattended reboots (was Re: The clouds are not random enough)
Arshad Noor wrote: Almost every e-commerce site (that needs to be PCI-DSS compliant) I've worked with in the last few years, insists on having unattended reboots. Not only that but many will be multi-node High Availability cluster systems as well or will be horizontally scaled. This means that there are multiple machines needing access to the same key material. Or it means putting a crypto protocol terminator on the front - the down side of that is loosing end to end security. Even when the server is configured with a FIPS-certified HSM and the cryptographic keys are in secure storage with M of N controls for access to the keys, in order for the application to have access to the keys in the crypto hardware upon an unattended reboot, This is because availability of the service is actually more important to the business than real security. the PINs to the hardware must be accessible to the application. If the application has automatic Or at least a broker for the application. access to the PINs, then so does an attacker who manages to gain entry to the machine. The way we have traditionally done that in Solaris for IKE is to write the passphrase/PIN in the clear to disk but rely on UNIX permissions to protect ie readable only to root or the user account the service runs as. P.S. As an aside, the solution we have settled on is to have the key- custodians enter their PINs to the crypto-hardware (even from remote locations, if needed, through secure channels). While it does not provide for unattended reboots, it does minimize the latency between reboots while ensuring that there is nothing persistent on the machine with PINs to the crypto-hardware. We recently added this ability for the IKE daemon on Solaris/OpenSolaris for the case when the private keys IKE uses are stored in a PKCS#11 keystore (HSM or TPM). However we don't expect this to be used in the case where unattended reboots or cluster failover be used. This is really no different to storing a root/host/service keytab on disk for Kerberos - yet that seems to be accepted practice even in organisations that by policy don't want passphrase/PIN on disk. -- Darren J Moffat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Weakness in Social Security Numbers Is Found
d...@geer.org wrote: I don't honestly think that this is new, but even if it is, a 9-digit random number has a 44% chance of being a valid SSN (442 million issued to date). I wonder if the UK NI numbers suffer from a similar problem. The look a little like this: AB 12 34 56 C Information on how they are strutured is here: http://en.wikipedia.org/wiki/National_Insurance#National_Insurance_number However given we don't use the NI number in the UK like the SSN is abused in the US there isn't the same security risk in guessing them. Although the Wikipedia article claims they are sometimes used for identification I know I have never been asked for mine other than by an employer or suitably authorised government body how has a real need to know. -- Darren J Moffat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: consulting question.... (DRM)
John Gilmore wrote: It's only the DRM fanatics whose installed bases of customers are mentally locked-in despite the crappy user experience (like the brainwashed hordes of Apple users, or the Microsoft victims) who are troublesome. In such cases, the community should I assume the Apple reference here is aimed at iTunes. You do know that iTunes Music Store no longer uses any DRM right ? -- Darren J Moffat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Warning! New cryptographic modes!
Jerry Leichter wrote: To support insertions or deletions of full blocks, you can't make the block encryption depend on the block position in the file, since that's subject to change. For a disk encryptor that can't add data to the file, that's a killer; for an rsync pre-processor, it's no big deal - just store the necessary key-generation or tweak data with each block. This has no effect on security - the position data was public anyway. That is basically what I'm doing in adding encryption to ZFS[1]. Each ZFS block in an encrypted dataset is encrypted with a separate IV and has its own AES-CCM MAC both of which are stored in the block pointer (the whole encrypted block is then checksumed with an unkeyed SHA256 which forms a merkle tree). To handle smaller inserts or deletes, you need to ensure that the underlying blocks get back into sync. The gzip technique I mentioned earlier works. Keep a running cryptographically secure checksum over the last blocksize bytes. ZFS already supports gzip compression but only does so on ZFS blocks not on files so it doesn't need to do this trick. The downside is we don't get as good a compression as when you can look at the whole file. ZFS has its own replication system in its send/recv commands (which take a ZFS dataset and produce either a full or delta between snapshots object change list). My plan for this is to be able to send the per block changes as ciphertext so that we don't have to decrypt and re-encrypt the data. Note this doesn't help rsync though since the stream format is specific to ZFS. [1] http://opensolaris.org/os/project/zfs-crypto/ -- Darren J Moffat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: full-disk subversion standards released
Thor Lancelot Simon wrote: No, no there's not. In fact, I solicited information here about crypto accellerators with onboard persistent key memory (secure key storage) about two years ago and got basically no responses except pointers to the same old, discontinued or obsolete products I was trying to replace. I wouldn't normally play marketeer but since you asked did you look at this product ? Either way I'd be interested in your view on it. http://www.sun.com/products/networking/sslaccel/suncryptoaccel6000/index.xml Please ignore the sslaccel in the URL this card doesn't know anything about SSL it is a pure Crypto accelerator and keystore with a FIPS 140-2 @ Level certification. Support on Solaris, OpenSolaris, RHEL 5 and SuSE 10. It has the ability to have centralised key management and shared keystores (within and across machines). It even has Eliptic Curve support available. -- Darren J Moffat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: full-disk subversion standards released
Thor Lancelot Simon wrote: To the extent of my knowledge there are currently _no_ generally available, general-purpose crypto accellerator chip-level products with onboard key storage or key wrapping support, with the exception of parts first sold more than 5 years ago and being shipped now from old stock. CA-6000 supports on board key storage and key wrapping. It even supports the NIST AES Keywrap algorithm. This card is certainly newer than 5 years old, in fact when we first released it we had some deployment issues because we had created a PCIe only card and several customers wanted to put on in machines that didn't have PCIe capability. -- Darren J Moffat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: full-disk subversion standards released
Peter Gutmann wrote: (Does anyone know of any studies that have been done to find out how prevalent this is for servers? I can see why you'd need to do it for software-only implementations in order to survive restarts, but what about hardware-assisted TLS? Is there anything like a study showing that for a random sampling of x web servers, y stored the keys unprotected? Are you counting things like Windows' DPAPI, which any IIS setup should use, as protected or unprotected?) We recently had some discussion about this inside Sun. Not just for TLS but for IKE as well. Until very recently our IKE daemon required the PKCS#11 PIN to be on disk (readable only by root) even if you were using sensitive and non extractable keys in a hardware keystore. We changed that to provide an admin command to interactively load the key. However we know that this won't actually be used on the server side in many case, and not in a cluster (the Solaris/OpenSolaris IKE and IPsec is cluster capable). For Web servers the situation was similar, either the naked private key was on disk or the PKCS#11 PIN that allowed access to it was. I solicited information here about crypto accellerators with onboard persistent key memory (secure key storage) about two years ago and got basically no responses except pointers to the same old, discontinued or obsolete products I was trying to replace. I was hoping someone else would leap in about now and question this, but I guess I'll have to do it... maybe we have a different definition of what's required here, but AFAIK there's an awful lot of this kind of hardware floating around out there, admittedly it's all built around older crypto devices like Broadcom 582x's and Cavium's Nitrox (because there hasn't been any real need to come up with replacements) but I didn't think there'd be much problem with finding the necessary hardware, unless you've got some particular requirement that rules a lot of it out. The Sun CA-6000 card I just pointed to in my other email is such a card it uses Broadcom 582x. -- Darren J Moffat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
Paul Hoffman wrote: At 12:24 PM +0100 1/12/09, Weger, B.M.M. de wrote: When in 2012 the winner of the NIST SHA-3 competition will be known, and everybody will start using it (so that according to Peter's estimates, by 2018 half of the implementations actually uses it), do we then have enough redundancy? No offense, Benne, but are serious? Why would everybody even consider it? Give what we know about the design of SHA-2 (too little), how would we know whether SHA-3 is any better than SHA-2 for applications such as digital certificates? In specific, if most systems have implemented the whole SHA-2 family by the time SHA-3 is settled, and then there is a problem found in SHA-2/256, I would argue that it is probably much more prudent to change to SHA-2/384 than to SHA-3/256. SHA-2/384 will most likely be much than to SHA-3/256, but it will have had significantly more study. Can you state the assumptions for why you think that moving to SHA384 would be safe if SHA256 was considered vulnerable in some way please. SHA256,384,512 are a suite all built on the same basic algorithm construction. Depending on how SHA256 fell the whole suite could be vulnerable irrespective of the digest length or maybe it won't be. Until we know how the SHA3 digest is actually constructed the same could even be true of that. I don't think it depends at all on who you trust but on what algorithms are available in the protocols you need to use to run your business or use the apps important to you for some other reason. It also very much depends on why the app uses the crypto algorithm in question, and in the case of digest/hash algorithms wither they are key'd (HMAC) or not. -- Darren J Moffat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: once more, with feeling.
Dirk-Willem van Gulik wrote: ... discussion on CA/cert acceptance hurdles in the UI I am just wondering if we need a dose of PGP-style reality here. We're really seeing 3 or 4 levels of SSL/TLS happening here - and whilst they all appear use the same technology - the assurances, UI, operational regimen, 'investment' and user expectations are way different: ^^^ I seriously doubt that even a single digit percentage of end users out on the internet know anything about the different types of certificates used in SSL/TLS and what they mean. I know none of my family (other than my wife: but given she worked for a large CA doing authentication and verification) knows what SSL really means never mind what the different types of cert are supposed to indicate and what to do about them, yet they buy stuff on the internet. It doesn't mean they are ignorant it is just the normal case. So my take is that it is pretty much impossible to get the UI to do the right thing - until it has this information* - and even then you have a fair chunk of education left to do :). Even if you got the UI to do the right thing it still doesn't mean anything real about trust all it really means is how much money was invested in getting the cert and setting up the correct information about the company identity behind it. -- Darren J Moffat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
Perry E. Metzger wrote: I was shocked that several people posted in response to Peter Gutmann's note about Wachovia, asking (I paraphrase): What is the problem here? Wachovia's front page is only http protected, but the login information is posted with https! Surely this is just fine, isn't it? [snip] (I won't be forwarding followups to this unless they are unusually interesting.) Hopefully this is interesting enough to get forwarded on... Sadly this practice is all too common, and often goes hand in hand with the other cardinal sin of https that of mixed http/https pages. I believe the only way both of these highly dubious deployment practices will be stamped out is when the browsers stop allowing users to see such web pages. So that there becomes a directly attributable financial impact to the sites that deploy in that way. As much as I like Firefox Safari [ the only two browsers I use now ] this has to be led by Microsoft with Internet Explorer since that will have the biggest impact, given IE 8 is in beta this seems like a perfect opportunity to get this in as a change for the next version. Warnings aren't enough in this context [ whey already exists ] the only thing that will work is stopping the page being seen - replacing it with a clearly worded explanation with *no* way to pass through and render the page (okay maybe with a debug build of the browser but not in the shipped product). -- Darren J Moffat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: how to read information from RFID equipped credit cards
On Tue, Apr 01, 2008 at 12:47:45AM +1300, Peter Gutmann wrote: Actually there are already companies doing something like this, but they've run into a problem that no-one has ever considered so far: The GTCYM needs a (relatively) high-bandwidth connection to a remote server, and there's no easy way to do this. You can get a fairly high-bandwidth channel with 2D barcodes. It's uni-directional, but that's enough for many useful scenarios. The data gets shown on the PC monitor and is captured by a ubiquitous camera-phone or a dedicated locked-down device. This approach avoids the problems you mentioned about USB/Firewire/Ethernet lockdown. Disclosure: I work for a company, Cronto, which makes a product based around this technology -- http://www.cronto.com/ Steven. -- w: http://www.cl.cam.ac.uk/users/sjm217/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Skype new IT protection measure
Ed Gerck wrote: BTW, one may wonder what is really happening. Any other reports? The NYT today had this article: http://www.nytimes.com/2007/08/17/business/17ebay.html Wren begin:vcard fn:J. Wren Hunt n:Hunt;J. Wren adr;dom:;;;Cambridge;MA;02138 email;internet:[EMAIL PROTECTED] title:Sr. Engineer tel;fax:1-270-897-0159 x-mozilla-html:FALSE url:http://wrenhunt.com version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: Creativity and security
On Fri, Mar 24, 2006 at 06:47:07PM -, Dave Korn wrote: J. Bruce Fields wrote: If all that information's printed on the outside of the card, then isn't this battle kind of lost the moment you hand the card to them? 1- I don't hand it to them. I put it in the chip-and-pin card reader myself. Oh, right, sorry, I missed that. In any case, even if I hand it to a cashier, it is within my sight at all times. 2- If it was really that easy to memorize a name and the equivalent of a 23-digit number at a glance without having to write anything down, surely the credit card companies wouldn't need to issue cards in the first place? Well, obviously there's some gap between what you need to make use of the card convenient, and what you'd need if you were an attacker willing to spend some minimum of effort. IOW, unless we're talking about a corrupt employee with a photographic memory and telescopic eyes, Tiny cameras are pretty cheap these days, aren't they? The employee would be taking more of a risk at that point though, I guess. --b. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Creativity and security
On Thu, Mar 23, 2006 at 08:15:50PM -, Dave Korn wrote: So what they've been doing at my local branch of Marks Spencer for the past few weeks is, at the end of the transaction after the (now always chip'n'pin-based) card reader finishes authorizing your transaction, the cashier at the till asks you whether you actually /want/ the receipt or not; if you say yes, they press a little button and the till prints out the receipt same as ever and they hand it to you, but if you say no they don't press the button, the machine doesn't even bother to print a receipt, and you wander away home, safe in the knowledge that there is no wasted paper and no leak of security information ... ... Of course, three seconds after your back is turned, the cashier can still go ahead and press the button anyway, and then /they/ can have your receipt. With the expiry date on it. And the last four digits of the card number. And the name of the card issuer, which allows you to narrow the first four digits down to maybe three or four possible combinations. OK, 10^8 still aint easy, but it's a lot easier than what we started with. If all that information's printed on the outside of the card, then isn't this battle kind of lost the moment you hand the card to them? --b. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Countries that ban the use of crypto?
--- Lee Parkes [EMAIL PROTECTED] wrote: Hi, A colleague of mine is locked in a battle with a client about the use of NULL ciphers for OpenSSL. The client claims that he has/wants to allow NULL ciphers so that people in countries that ban the use of crypto can still use the website. My colleague wants to know if there is a list of such countries that he could use. Well, I suppose you could always check Bert-Jaap Koops' crypto law survery (http://rechten.uvt.nl/koops/cryptolaw/). However, there are only two countries, to the best of my knowledge, that outright ban cryptography: Russia and China. And even that's only a de-facto ban since both only require individuals to obtain a license to use cryptography in any way, shape or form. From what I have heard, it's nearly impossible for your average Joe to actually be issued such a license. (Your average Joe in those countries is most likely more concerned with putting food on the table anyhow but that's besides the point.) Israel has a license requirement as well. But since personal use is exempt and the law allows for general licensing of software products, it's pretty much a non-issue these days. -Jörn __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [PracticalSecurity] Anonymity - great technology but hardly used
--- Travis H. [EMAIL PROTECTED] wrote: [snip] Another issue involves the ease of use when switching between a [slower] anonymous service and a fast non-anonymous service. I have a tool called metaprox on my website (see URL in sig) that allows you to choose what proxies you use on a domain-by-domain basis. Something like this is essential if you want to be consistent about accessing certain sites only through an anonymous proxy. Short of that, perhaps a Firefox plug-in that allows you to select proxies with a single click would be useful. You can already do the latter with SwitchProxy (http://www.roundtwo.com/product/switchproxy). Basically, it's a Firefox extension that saves you the trouble of going into the 'preferences' dialogue everytime you want to switch from one proxy to another (or go from using a proxy to not using one, that is). It works like a charm with tor and a local proxy. It also has a Anonymizer mode, which cycles through a list of proxies in an attempt to give you some kind of pseudo-anonymity (which I guess is good enough for many people). Jörn __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: mother's maiden names...
--- Dan Kaminsky [EMAIL PROTECTED] wrote: Bank Of America put my photo on my ATM card back in '97. They're shipping me a new one right now, so I assume they kept it in the DB. My local bank asked me apply for a Visa photo credit card back in 1998. There were two problems though: 1.) Their request really was just that, a request. They told me that I was free to get a regular card if I was in any way uncomfortable with the photo card. In retrospect, it seemed more like a we'd appreciate it if you could do us a big favor thing, and not so much like look, we're doing this for your own protection. The manager I talked to about this also informed me that they were only asking customers with high credit lines (whatever that's supposed to mean) to get credit cards with pictures since they were more expensive (apparently, the bank had to eat the majority of the cost; I recall only paying a $5 one-time fee). 2.) Secondly, checkout clerks just don't care. Well, they actually did notice the picture on the back of the credit card and asked what it was about maybe 6 out of 10 times. In most cases, the question resulted in very pleasant but pointless chit-chat. Noone ever asked me why I didn't look like the guy in the picture (I had since grown a beard and the picture was really grainy and low-quality). Noone ever called a manager to verify my identity despite the fact that it clearly said Please verify cardholder's picture. on the back. (I still have one photo credit card and it no longer says that and has a more up-to-date picture.) The problem here was that most check out clerks these days are teenagers making minimum wage. They care about getting paid, not getting robbed and not getting hassled. And, frankly, I can understand that attitude because I felt the same way when I was in high school. Having too little cash in the register at the end of the shift stands out and is likely to get a cashier in trouble. Having a credit card purchase flagged as fraudulant a week after the fact doesn't cause as much trouble. That's why there's no incentive to check CCs. It's also why the Zug.com credit card prank worked so well back in the day. My gym(!) has quite a different policy - they take a picture of every member when apply. You may bring a guest but the member has to be authenticated first and the guest has to sign in. If you forget your RFID card, they just check the database (or, most likely, they will recognize you). Any employee who lets people in withot an ID check or without signing in, gets a warning. Employees get fired after three warnings. Draconian? Yes. But it does work. And it wouldn't be too hard for the credit card companies to print MUST VERIFY ID onto the back of new credit cards. These days, I am on a first name basis with most of the cashiers at the local grocery stores (which is due to the fact that I'm friends with their parents who pretty much all live in the same neighborhood as we do - suburbia and all). But I do remember when we moved here and back then cashiers really noticed the credit card I had written PLEASE ASK FOR ID. THANK YOU. onto. At that time, it was mostly a social experiment. And, frankly, it didn't work. They noticed (as in huh, that's weird) but they never bothered to ask me for ID (as huh, that's weird, may I see your ID please, Sir?). __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ID theft -- so what?
--- John Denker [EMAIL PROTECTED] wrote: [...] It's only a problem if somebody uses that _identifying_ information to spoof the _authorization_ for some transaction. [...] Identifying information cannot be kept secret. There's no point in trying to keep it secret. Getting a new SSN because the old one is no longer secret is like bleeding with leeches to cure scurvy ... it's completely the wrong approach. The only thing that makes any sense is to make sure that all relevant systems recognize the difference between identification and authorization. See, that's precisely where the problems lies: I could not agree more with you but the fact that you are completely, 100% right doesn't help me one bit if T-Mobile's computer system requires that I give them my SSN (which, by the way, may no longer be the case). And there's no point in arguing with the store manager because he likely doesn't have the power to do anything about it anyway and probably just doesn't care. The fact of the matter is that you're making entirely too much sense. ;) SSNs were never intended to be used for authorization. That's why it explicitly said For Social Security Purposes. Not for Identification on the bottom of old social security cards. These days, federal law says quite the opposite. USC 405 [C] and subsequent sections state that it's okay for any state or government agency to require an individual to provider their SSN [...] for the purpose of establishing the identification of individuals affected by such law [...]. In the Greate State of California, you can, for instance, not even get a driver's license without telling the DMV your SSN. Since I don't see a connection between said (semi-)randomly assigned number and my ability to operate a motor vehicle, I'd have to wager a guess and say that the CA DMV does indeed use social security numbers for identification purposes. Fortunately, they don't just go ahead and use your SSN as your driver's license number, too (IL, I believe, used to do that). And the fact that many private businesses and schools still use SSNs as unique identifiers and often display them quite prominently for the world to see (eg. to people working in call centers half-way around the world) makes matters even worse. Because you will often find that people treat you like you're going out of your way to be a PITA if you refuse to give them your SSN. And that's all fine and well as long as we're talking about the likes of T-Mobile. Just use a different carrier, right? Well, they all (used to) require that you give them your SNN. And so do most telcos, utility companies, landlords, banks, public schools, community colleges, DMVs, credit card companies, car dealerships (financing, etc.), cable companies and pretty much any government agency (state and federal) that issues any kind of license. The answer to this dilemma? I'm afraid this time it really is legislation. Frankly, I'm not even sure if that would work but, at this time, it's our best shot. Congress won't do anything about this unless a few representatives have their identities stolen and experience first-hand what a PITA it is to have to deal with the fallout. -Jörn __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: EMV [was: Re: Why Blockbuster looks at your ID.]
--- [EMAIL PROTECTED] wrote: [decline in credit card fraud] Interesting statistics. [...] But these are still considerable numbers, [...] I totally agree. And I would just like to make a quick point: the credit card companies (especially Visa/Mastercard) have been very agressive in fraud prevention in the last ten years. And I don't mean algorithms that detect unusual activity and flag a card, thereby prompting your bank to call and verify that that the charges are good. They've been doing that for years, if not decades. No, I mean literally detective work -- tracking people down, having their sites closed and bank accounts freezed and actually pushing to have people prosecuted. They have been quite active, trying to recruite people in the law enforcement community and offering handsome salaries. The whole thing works based on the premise that there are a lot of small-time gangsters at any given time but only a few big fish. And if you can increase the cost of doing business (either in terms of making credit fraud more expensive or in terms of increasing the likelihood to get caught) you can basically justify the expense of running a big anti-fraud unit. But, in a way, that's only dealing with the symptoms, whilst at the same time ignoring the root cause of the problem. You're only making it less attractive to commit credit card fraud. You are, however, not making it harder. That's why I believe the credit cards companies will indeed have a good, long look at smartcards. Probably not tomorrow or next week but in the near future. -Jörn __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Time-Memory-Key tradeoff attacks?
My paper ``Understanding brute force'' explains an attack with a much better price-performance ratio than the attack described by Biryukov: http://cr.yp.to/talks.html#2005.05.27 http://cr.yp.to/papers.html#bruteforce Biryukov's central point regarding key amortization was made earlier (and, I think, more clearly) in my paper. My paper also analyzes the merits of various defenses against the attack. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Optimisation Considered Harmful
Here's an amusing example of optimization: On the PowerPC 7450 (G4e), integer multiplication is faster by one cycle if the second operand is between -131072 and 131071. Ever use multiplication in cryptography? Jerrold Leichter writes: There are only a couple of roads forward: - Develop algorithms that offer reasonable performance even if implemented in unoptimized ways. We already have some secret-key ciphers that naturally run in constant time on current CPUs. One example is my own Salsa20, which is a quite conservative design but still faster than AES. Some other examples are Phelix and good old TEA. Furthermore, most CPUs have constant-time floating-point multiplication. Floating-point multiplication usually turns out to be the fastest way to do integer arithmetic in RSA etc., although it takes some effort to use. The quick summary is that we _can_ have high-speed constant-time cryptography. The algorithms are already there---although they need to be distinguished from the impostors such as Rijndael. The implementation techniques are already there---although they need to be more widely understood and used. I can't recall ever seeing a benchmark that reported the variance of timing across instances of the loop. For years now I've been reporting multiple individual timings rather than averages. See, e.g., http://cr.yp.to/mac/poly1305-20041101.pdf, Appendix B; those are the AES timings that prompted me to start investigating cache-timing attacks. (Subsequent versions of the poly1305 paper report even more timing information but, for space reasons, have to compress the information into small graphs. Big tables are on the web.) ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Protecting against the cache-timing attack.
Jon Callas writes: So let's conduct a small thought experiment. Take the set of timings T, where it is the timings of all possible AES keys on a given computer. (It's going to be different depending on cpu, compiler, memory, etc.) Order that set so that the shortest timing is t_0 and the longest one is t_omega. Obviously, if you delay until t_omega, you have a constant-time encryption. A network packet arrives during your AES computation, takes tens of thousands of cycles to handle, and knocks a few of your table lines (perhaps chosen by a remote attacker?) out of both L1 and L2 cache. Part of the problem here is that t_omega is huge, forcing a huge delay. Another part of the problem is that your timings are now interacting with the timings of other processes. An extreme form of this effect is illustrated by the very fast hyperthreading attack; I'm sure that some bored undergraduate will figure out a remote exploit for a less extreme form of the effect. Section 13 of my paper discusses a solution to the interrupt problem, but that solution requires massive software changes. I'm not aware of simpler solutions. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: massive data theft at MasterCard processor
On 6/21/05, Florian Weimer [EMAIL PROTECTED] wrote: Also there are several attacks on Chip n' PIN as deployed here in the UK, starting with the fake reader attacks - for instance, a fake reader says you are authorising a payment for $6.99 while in fact the card and PIN are being used to authorise a transaction for $10,000 across the street. In Germany, there's a widely used system based on PIN and a magnetic stripe, and you can buy used reader devices on Ebay. 8-( This makes it rather easy to mount a MITM attack. That most certainly is true but you're overlooking a more practical aspect. All German financial institutions that processes credit card transactions contractually require their merchants to offer the customer a receipt (as does German law in most cases). Most, if not all, banks that issue credit cards require their customers to retain a copy of those receipts for one billing cycle (ie. until they send you your statement and you have a chance to review it and compare individual charges that seem suspect with the data on the receipts you have). If your receipt says $6.99 but your statement says $10,000 (classic MITM attack), you have a valid defense in the eyes of the German law. Legally, the receipt is the document which authorized the financial transaction. If you show up in court and present your $6.99 receipt, you automatically shift the burden of proof to the bank -- now they have to positively proof that you indeed authorized $10k, and not just $6.99, not be transfered. Realistically, the will hardly ever be able to do that. That model works fairly well. The weak point is the customer -- just tossing or blindly signing a receipt obviously breaks the model. But, personally, I don't really have a problem with that; the point is to protect the customer from scammers, and not from his or her own stupidity. Sincerely, Joern Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AES cache timing attack
http://cr.yp.to/talks.html#2005.06.01 has slides that people might find useful as an overview of what's going on. In particular, there's a list of six obstacles to performing array lookups in constant time. People who mention just one of the obstacles are oversimplifying the problem. Hal Finney writes: The one extra piece of information it does return is the encryption of an all-zero packet. So there is a small element of chosen plaintext involved. Known plaintext, not chosen plaintext. I used timings to identify 105 key bits and then compared the remaining 2^23 keys against a known plaintext-ciphertext pair, namely the encrypted zero that you mention. One can carry out the final search with nothing more than known ciphertext: try decrypting the ciphertext with each key and see which result looks most plausible. It should even be possible to carry out a timing attack with nothing more than known ciphertext, by focusing on either the time variability in the last AES-encryption round or the time variability in the first AES-decryption round. Of course, most applications have some known plaintext, and some applications allow chosen plaintext, so even a chosen-plaintext attack is considered to be a fatal flaw in a cryptographic standard. The user isn't supposed to have to worry that someone who influences part of the plaintext will be able to read all the rest. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cryptography and the Open Source Security Debate
There doesn't appear to be a discussion forum related to the Web post, so I'll reply here. We've gone through a similar thought process at my company. We have a commercial security product (MatrixSSL), but provide an open source version for many of the good points Daniel makes. There are a few additional reasons that the general open-source conclusion isn't as clear cut however. One of the benefits of having security algorithms open source is that the code can be better trusted in terms of back doors. So while Daniel may trust the NSA, others may not. Standard software typically isn't treated with the same positive paranoia, and therefore doesn't often have the same requirement. Back doors in closed source networked software, for example can be somewhat tested for through network protocol analysis and controlled through firewalls. Cryptography must be trusted at an algorithm level, since protocol analysis of the resultant data (should be) very difficult. A larger problem with the expansion from cryptographic algorithm benefits to open source benefits in general is one of pure code size. The number of lines of code of both Windows and Linux distributions is 30-40 million. The number of developers that 1. bother reading the code, 2. can actually understand it, 3. have the expertise and motivation to suggest/correct problems is a very small subset of developers for either proprietary or open source solutions. Developers that understand the complex interactions between software components are even fewer. When it comes down to it, a very small set of people becomes trusted in whatever code area they specialize in. Crypto algorithms are typically on the order of 1000 lines of code, with a large portion containing static key blocks. Experts looking at an open crypto algorithm require a great deal of expertise, but can also be much more focused in their analysis. Do you trust both the talent and moral integrity of the company you are getting your closed source software from so much that you think the products they are supplying you are superior (from a security standpoint) to those that can be created via peer review and attack by tens of thousands? This question is less related to the crypto specific conclusion, so I'll keep it short. The power of capitalism to produce competition and better products is underestimated here. Market pressure is growing for closed source to become more secure, and when money is at stake, the products will improve. Peer review by tens of thousands of largely unpaid, untrained developers vs. a corporation's all important shareholder value in this increasingly security conscious market is a much more even fight than one might expect. This is why we have combined both sides of the debate to produce a dual licensed product that has the security benefits of open source, with the market responsibility of a commercial product. J Harper PeerSec Networks http://www.peersec.com - Original Message - From: R. A. Hettinga [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 9:46 AM Subject: Cryptography and the Open Source Security Debate http://www.osopinion.com/print.php?sid=1792 osViews | osOpinion Cryptography and the Open Source Security Debate Articles / Security Date: Jul 20, 2004 - 01:03 AM Contributed by: Daniel R. Miessler :: Open Content If you follow technology trends, you're probably aware of the two schools of thought with regard to security and/or cryptography. Does cryptography and security solutions become more secure as the number of eyes pouring over its source code increases or is a private solution which leverages security through obscurity provide a more secure environment? Daniel R. Miessler submitted the following editorial to osOpinion/osViews, which offers some compelling arguments for both scenarios. In the end, his well thought out opinion, comes to a universal conclusion. -- I've been reading Bruce Schneier's Book on cryptography for the last couple of days, and one of the main concepts in the text struck me as interesting. One of the points of discussion when looking at the security of a given algorithm is its exposure to scrutiny. Bruce explicitly states that no one should ever trust a proprietary algorithm. He states that with few exceptions, the only relatively secure algorithms are those that have stood the test of time while being poured over by thousands of cryptanalysts. Similar Situations What struck me is the similarity between this mode of thought and that of the open source community on the topic of security. In that debate there is much disagreement about which is better - open or closed -, while in the crypto world it's considered common knowledge that open is better. According to the crypto paradigm, having any measure of an algorithm's security based on the fact that it's a secret is generally a bad thing. There, keys are what makes the system
Humorous anti-SSL PR
This barely deserves mention, but is worth it for the humor: Information Security Expert says SSL (Secure Socket Layer) is Nothing More Than a Condom that Just Protects the Pipe http://www.prweb.com/releases/2004/7/prweb141248.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Claimed proof of the Riemann Hypothesis released
On Wed, Jun 09, 2004 at 04:56:03PM -0400, Perry E. Metzger wrote: Actual practical impact on cryptography? Likely zero, even if it turns out the proof is correct (which of course we don't know yet), but it still is neat for math geeks. Also, the impact of such a proof is often that it represents a milestone in understanding a certain piece of theory, so in the long run the ideas used in the proof may be useful even if the result is no suprise, just as in the cas of factoring challenges, when the work done to come up with algorithms that can factor large integers may be important, and the fact that someone was able to factor an integer of a certain size may say something about the state of the art, even though nobody will actually give a hoot what the factors turned out to be. Of course, who knows about this particular case--apparently this guy has a history of premature announcements. --b. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
MatrixSSL Embedded SSL/TLS
For those of you who are interested in the coding aspects of crypto, I'd like to announce that our small footprint SSL/TLS library, MatrixSSL is available for download at http://www.matrixssl.org With a footprint under 50KB, MatrixSSL not only meets device requirements, it also provides a protocol implementation that is easy to read and understand. Some unique benefits for the cryptography community are: + Clean, clear implementation makes bugs and security issues easier to spot and fix + Focused, well documented implementation of SSL is a good teaching tool + Open Source ensures potential backdoors and security issues can be found + Compact implementation of a standard security protocol removes an excuse for homegrown solutions I'm interested in your feedback about MatrixSSL. We are actively working to make sure this a unique solution that solves some of the issues preventing adoption of standard security protocols in Internet enabled devices. J Harper PeerSec Networks http://www.peersec.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Open Source Embedded SSL - (License and Memory)
1) Not GPL or LPGL, please. I'm a fan of the GPL for most things, but for embedded software, especially in the security domain, it's a killer. I'm supposed to allow users to modify the software that runs on their secure token? And on a small platform where there won't be such things as loadable modules, or even process separation, the (L)GPL really does become viral. This is, I think, why Red Hat releases eCos under a non-GPL (but still open source) license. We're aware of these issues. How do other people on the group feel? 2) Make it functional on systems without memory allocation. Did I mention that I work on (very) small embedded systems? Having fixed spaces for variables is useful when you want something to run deterministically for a long time with no resets, and I have yet to find a free bignum library that didn't want to use malloc all the time. We have implemented a block allocation scheme for our device Web services product that would probably solve this issue. Queues of various structure sizes are held within a single chunk of memory. This has the nice side effect of cleaning up any leaked memory when freed. If the demand is there we'll consider releasing the source for this as well. Doing an apache style per-session memory pool for SSL sessions would be a nice way to make sure all memory was freed after each SSL session closes. For now we use the classic #define sslMalloc malloc, and let you swap in your own implementation if desired. J Harper PeerSec Networks http://www.peersec.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Open Source Embedded SSL - Export Questions
Thanks. Pretty simple for open source code. Single email to two addresses once we have code available online. http://www.bxa.doc.gov/Encryption/pubavailencsourcecodenofify.html (yes, notify is spelled wrong) What about the patent/trademark issues? - Original Message - From: Sidney Markowitz [EMAIL PROTECTED] To: J Harper [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, November 25, 2003 5:23 PM Subject: Re: Open Source Embedded SSL - Export Questions J Harper wrote: pointers to documentation on the steps required for government registration The official site for this is at http://www.bxa.doc.gov/Encryption/Default.htm -- sidney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Open Source Embedded SSL - (AES)
I've just taken a look. This OCB mode for AES looks really interesting. Encryption and MAC in one pass! Wait, OCB is patented. That's not in the spirit of AES :-) I suppose one could do a user defined cipher suite for AES OCB, if both client and server knew about it. Anyway... must focus on current release. Any word on whether it's OK to use the TLS AES cipher suite with SSLv3? J -Original Message- From: Sidney Markowitz [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 26, 2003 5:13 PM To: J Harper Cc: [EMAIL PROTECTED] Subject: Re: Open Source Embedded SSL - Export Questions As a separate issue from whether you want to implement AES, if you do decide to implement it look at Brian Gladman's code at http://fp.gladman.plus.com/cryptography_technology/rijndael/ It is the fastest free implementation of AES that I know of, and has a good history and credentials behind it as you can see from the background information linked from that web page. -- sidney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Open Source Embedded SSL - Export Questions
Hi All, We've implemented a small version of SSL that we plan to release as open source by year's end. I've seen some discussion on this group indicating that this would be useful in the embedded environments, given the current landscape of larger implementations such as OpenSSL (Crypto++, etc). We developed this ourselves (using some of the crypto routines in Tom's libtomcrypt) as part of our Web services based device management software because we needed to keep our own footprint small, and I imagine there are others looking to do the same. Once our code is released, we welcome feedback in terms of additional requirements, gotchas, etc. (and if you want to jump in now, that's fine too). But before we can release, we need to understand the export issues (we're a US based company). An overview of what we're developed for the first release: SSLv3 protocol implementation Simple ASN.1 parsing Cipher suites: TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA We're not looking for official legal advice, just some pointers to current online resources of how to go about registering our product in the US. I've seen posts that for SSL implementations you just need to send a letter to the government, but haven't come across an official government checklist and address. We may be able to weaken the code down using the export ciphers, but I doubt end users will be interested in that level of encryption. Plus, if we do have to limit key lengths, it seems a bit arbitrary with open source code, since users can simply change a few lines of code and have full strength crypto. Are there any special provisions for source release (short of getting a tattoo, singing an mp3 or sending a model rocket over to Mexico - kidding, kidding)? We'd appreciate feedback or pointers to documentation on the steps required for government registration and an approximate timeframe for the process. On a different, but similar legal note, what current patent/trademark issues have people run across with the algorithms mentioned above? RSA patents expired a few years ago and our ARC4 implementation is not trademarked as far as I understand (although most books on the subject seem a bit squirrelly). Open source crypto libraries include implementations of these and other disputed algorithms including DSS and ECC, so I'm wondering how they handled the situation. Thanks, J Harper PeerSec Networks http://www.peersec.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
