Re: Solving password problems one at a time, Re: The password-reset paradox
On Sat, 21 Feb 2009 11:33:32 -0800 Ed Gerck edge...@nma.com wrote: I submit that the most important password problem is not that someone may find it written somewhere. The most important password problem is that people forget it. So, writing it down and taking the easy precaution of not keeping next to the computer solves the most important problem with not even a comparably significant downside. Up to a point. The most important password problem is very much context-dependent. I'm not going to forget the unlock password to my laptop, because I use it many times/day. I regularly forget my login password to the CS department's servers because I use it so rarely -- as best I can tell, I haven't used it in at least 15 months, because I use public key authentication for most functions. They've installed some new service that will require it, though, so I suppose I need to learn it. However -- if you're talking about garden-variety web passwords, you're probably correct. For your last sentence, see my next response... Having automatic, secure, and self-managed password recovery and password reset (in case the password cannot be recovered) apps are also part of this solution. Define automatic and secure. Self-managed is context-dependent. It's true for generic web authentication; it most certainly is not for more serious ones. The generic recovery/reset mechanisms have their own security issues -- how secure is the back-up authentication systems? In most cases, the answer is much less secure than the base mechanism. I see the second most important problem in passwords to be that they usually have low entropy -- ie, passwords are usually easily guessable or easy to find in a quick search. So -- why does that matter? We've become prisoners of dogma here. In 1979, Bob Morris and Ken Thompson showed that passwords were guessable. In 1979, that was really novel. There was a lot of good work done in the next 15 years on that problem -- Spaf's empirical observations, Klein's '90 paper on improving password security, Lamport's algorithm that gave rise to S/Key, my and Mike Merritt's EKE, many others. Guess what -- we're not living in that world now. We have shadow password files on Unix systems; we have Kerberos; we have SecurID; we have SSL which rules out the network attacks and eavesdropping that EKE was intended to counter; etc. We also have web-based systems whose failure modes are not nearly the same. Why do we think that the solutions are the same? There was a marvelous paper at Hotsec '07 that I resent simply because the authors got there before me; I had (somewhat after them) come to the same conclusions: the defenses we've built up against password failure since '79 don't the problems of today's world. We have to recognize the new problems before we can solve them. (I *think* that the paper is at http://www.usenix.org/events/hotsec07/tech/full_papers/florencio/florencio.pdf but I'm on an airplane now and can't check... The next two important problems in passwords are absence of mutual authentication (anti-phishing) Personally, I think this is the biggest problem when it comes to phishing attacks. and absence of two-factor authentication. What problem does two-factor solve? I agree that it's helpful, but until we know the threat we can't solve it. To solve these three problems, at the same time, we have been experimenting since 2000 with a scheme where the Username/Password login is divided in two phases. In different applications in several countries over nine years, this has been tested with many hundreds of thousands of users and further improved. (you can also test it if you want). It has just recently been applied for TLS SMTP authentication where both the email address and the user's common name are also authenticated (as with X.509/PKI but without the certificates). This is how it works, both for the UI and the engine behind it. (UI in use since 2000, for web access control and authorization) After you enter a usercode in the first screen, you are presented with a second screen to enter your password. The usercode is a mnemonic 6-character code such as HB75RC (randomly generated, you receive from the server upon registration). Your password is freely choosen by you upon registration.That second screen also has something that you and the correct server know but that you did not disclose in the first screen -- we can use a simple three-letter combination ABC, for example. You use this to visually authenticate the server above the SSL layer. A rogue server would not know this combination, which allays spoofing considerations -- if you do not see the correct three-letter combination, do not enter your password. As Peter Gutmann has pointed out, that has succeeded only because it hasn't been seriously attacked. Research results show that users are very easily fooled by changes to the server. In the scenario you cite, all it
Re: Security through kittens, was Solving password problems
James A. Donald jam...@echeque.com writes: The interesting thing is that it and similar phishes do not seem to have been all that successful - few people seemed to notice at all, the general reaction being to simply hit the spam key reflexively, much as people click away popup warnings reflexively, and are unaware that there ever was a popup. Why the attack resistance? I conjecture that: 1. User normally enters his password in an environment that looks nothing like a web page, so being asked to do so in a web page automatically makes him suspicious - it is a deviation from normal workflow 2. Blizzard never communicates by email, so receiving email from blizzard automatically makes the user suspicious. You'd really need to perform a controlled experiment to see which factors actually affect this. For example another factor could be that the gamer demographic is more aware of phishing than Joe Sixpack and therefore less likely to become a target. Or that they're more interested in gaming than account management and just ignore the message. It'd be interesting to see what the contributing factors are (although if it's more interested in gaming than account management then it doesn't translate to other areas much). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Activation protocol for tracking devices
I'm afraid this email will probably will be a) flamed away (because it's not from a cryptographer, but forced to do crypto-things, and I do know your opinion about this matter...) b) ignored (same reason!). I'm sending it anyway because any kind of feedback would be welcomed ;), and the situation is, in my opinion, dire... As I wrote in my last email, in Brazil they are devising a protocol to activate tracking/blocking devices to be installed from factory in *every* vehicle, starting progressively from august 2009. The idea is that a service operator (SO) can activate a device to work with it, by first asking a centralized agency, the DENATRAN (department of transit), that must authorize the activation request. Once activated, the device keeps in that state until the SO deactivates it or until DENATRAN reconfigures the device SIM card remotely to change it IMSI to a special network operated by DENATRAN. We are trying to suggest options for this activation protocol, and for our current one I have some questions I would like to confirm with knowledgeable people like you ;): * Is there any standard cryptographic hash function with an output of about 64 bits? It's OK for our scenario if finding a preimage for a particular signature takes 5 days. Not if it takes 5 minutes. * Suppose a cryptographically secure random number is stored on the device from factory, could I use the output of a block cipher applied to this number as a way to generate new random numbers (since the output from the cipher should not be distinguishable from random data)? In case yes, could I do this with a hash instead of a cipher? For those interested, this is what we are proposing at the time: Every TCU (the device) comes pre-installed from factory with a Kt known to the device and DENATRAN. SO- TCU (device): sends a SMS with GPRS connection information (apn, user, pass, server IPs/ports). The mechanism so that this first SMS is not a big issue have been, reasonably, covered. TCU-SO: challenge SO-DENATRAN: challenge, SO_id DENATRAN-SO: H(Kt, challenge, SO_id), Kc=H(Kt, challenge) SO-TCU: H(Kt, challenge, SO_id), SO_id From that point, Kc is stored in SO and TCU, and every message interchanged between the SO and TCU goes signed with Kc (for this we need a H with max. 64 bits output...). The SO is connected thru an authenticated connection to DENATRAN (ie. vpn). Reply attacks could be possible, we are proposing to include and additional incremental 4 byte numbers to use as nonce. In the activation protocol H can be much stronger than the one used later. I'm aware that the way of applying the hash function must be carefully studied, but at this point we need a reasonable idea to discuss over (I would love if this message gets bashed to the ground ;)). Message encryption has been outright discarded by the working groups. I'm not asking for anyone here to actually provide a solution (it would be stupid to do so), it's just that by looking at how things are progressing at Brazil, if nothing comes out, things will just be ignored and the implemented solution will probably be quite catastrophic At this time, in Brazil there are thousands of tracking companies, each with their own protocols and devices, but this regulation will impose a government dictated monoculture that creates a very fertile ground for massive exploits. Thanks! Regards, Santiago. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
[Fwd: New W3C XML Security Specifications]
FYI. Original Message Subject: New W3C XML Security Specifications Date: Fri, 27 Feb 2009 14:10:04 -0500 From: Sean Mullan sean.mul...@sun.com Reply-To: security-...@xml.apache.org To: security-...@xml.apache.org The W3C XML Security Working Group has just released 7 first public working drafts of new XML Signature and Encryption specifications. Please try to review them and send any comments you have to the XML Security working group. These drafts include revisions to XML Signature and Encryption to support new algorithms, a new document proposing simplifications to the XML Signature Transform model to enhance performance and security, and several other new specifications. Here is the announcement from the W3C Working Group chair: The W3C XML Security Working Group [1] has published [2] First Public Working Drafts related to XML Security and requests feedback on these documents. Comment may be sent to the list public-xmlsec-comme...@w3.org . If possible please indicate the document in the subject line. (1) XML Signature Syntax and Processing Version 1.1 http://www.w3.org/TR/2009/WD-xmldsig-core1-20090226/ (2) XML Encryption Syntax and Processing Version 1.1 http://www.w3.org/TR/2009/WD-xmlenc-core1-20090226/ (3) XML Signature Transform Simplification: Requirements and Design http://www.w3.org/TR/2009/WD-xmldsig-simplify-20090226/ (4) XML Security Use Cases and Requirements http://www.w3.org/TR/2009/WD-xmlsec-reqs-20090226/ (5) XML Security Derived Keys http://www.w3.org/TR/2009/WD-xmlsec-derivedkeys-20090226/ (6) XML Signature Properties http://www.w3.org/TR/2009/WD-xmldsig-properties-20090226/ (7) XML Security Algorithm Cross-Reference http://www.w3.org/TR/2009/WD-xmlsec-algorithms-20090226/ The Working Group has also published an updated working draft of XML Signature Best Practices: (8) XML Signature Best Practices http://www.w3.org/TR/2009/WD-xmldsig-bestpractices-20090226/ The Working Group would appreciate review of these documents, with special attention to the algorithms listed in XML Signature 1.1 and XML Encryption 1.1, the proposed 2.0 changes in the Transform Simplification document and Use Cases and Requirements. Again, comment may be sent to the list public-xmlsec-comme...@w3.org . Thank you regards, Frederick Frederick Hirsch, Nokia Chair XML Security WG [1] http://www.w3.org/2008/xmlsec/ [2] http://www.w3.org/News/2009#item25 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
X.509 certificate overview + status
Hello, Recently I set up certificates for my server's SSL, SMTP, IMAP, XMPP, and OpenVPN services. Actually, I created my own CA for some of the certificates, and in other cases I used self-signed. It took me substantially more time than I had anticipated, and I'm left with feelings of unease. It seems the way to do this revolves around openssl, but while I was able to find instructions*, they were cookbook-style, and didn't really give me as complete an understanding as I had hoped. [*] http://sial.org/howto/openssl/ I experimented with tinyca2, which appears only to create certificates with passphrases, which is obnoxious. Only some applications (e.g. dovecot) allow you to specify passphrases, and in most cases the config file with the passphrase is protected the same way as the key itself, using filesystem permissions, making it pointless. However, I still have problems with dovecot. Whenever I connect to IMAPS, it complains that the certificate is for '' (empty string), and I'm not sure what I did wrong in the certificate creation. In other cases, such as openvpn, there are some scripts there (easy-rsa) which take care of it for you. I couldn't, in particular, find comprehensive information on the openssl.cnf file, particularly the v3 extensions. In some cases, such as OpenBSD's isakmpd, I had to abandon my plans completely because they had requirements that the certificates have some fields (subjectAltName, I think) that weren't well documented. I can't remember exactly if I couldn't create this field, or merely didn't know what to put in it. However, in this case, the main problem I found was that the Linux port of isakmpd was not reliable, and nearly impossible to debug. It just would work 50% of the time, and not the other 50%. OpenBSD's isakmpd is pretty sexy - it detects NAT traversal and automagically encapsulates in UDP - but apart from the Linux reliability issue, I also had issues with multiple tunnels going through the same NAT/fw box that was itself running IPSec. Whereas by contrast, OpenVPN handles that situation well, and has support for MS-Windows should I ever want it. Further, trying to dig into ASN.1 was extremely difficult. The specs are full of obtuse language, using terms like object without defining them first. Are there any tools that will dump certificates in human-readable formats? I would really like something that could take a PEM file of a cert and display it in XML or something of the sort. Although I have it all working, I am considering redoing all the work, hopefully all under one CA cert that I control. But I'm not sure if that's wise. I'm plowing through the O'Reilly OpenSSL book, but are there other resources out there that could help me, or others like me? -- Obama Nation | It's not like I'm encrypting... it's more like I've developed a massive entropy deficiency | http://www.subsubpacefield.org/~travis/ If you are a spammer, please email j...@subspacefield.org to get blacklisted. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: X.509 certificate overview + status
Travis wrote: Recently I set up certificates for my server's SSL, SMTP, IMAP, XMPP, and OpenVPN services. Actually, I created my own CA for some of the certificates, and in other cases I used self-signed. It took me substantially more time than I had anticipated, and I'm left with feelings of unease. Welcome to the club! Further, trying to dig into ASN.1 was extremely difficult. The specs are full of obtuse language, using terms like object without defining them first. Are there any tools that will dump certificates in human-readable formats? I would really like something that could take a PEM file of a cert and display it in XML or something of the sort. Ubuntu comes with dumpasn1. There are also quite a few libraries. I'm plowing through the O'Reilly OpenSSL book, but are there other resources out there that could help me, or others like me? You should be aware of Peter Gutmann's style guide: http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt Thanks, Marcus - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Activation protocol for tracking devices
On Feb 27, 2009, at 2:13 PM, Santiago Aguiar wrote: * Is there any standard cryptographic hash function with an output of about 64 bits? It's OK for our scenario if finding a preimage for a particular signature takes 5 days. Not if it takes 5 minutes. Not specifically, but you can simply take the first 64 bits from a larger cryptographically secure hash function. If the nature of your usage is that an attack requires finding a preimage to an externally specified hash value, 64 bits is reasonably secure. (If being able to find a pair of values with the same hash value, 64 bits is way too short.) * Suppose a cryptographically secure random number is stored on the device from factory, could I use the output of a block cipher applied to this number as a way to generate new random numbers (since the output from the cipher should not be distinguishable from random data)? In case yes, could I do this with a hash instead of a cipher? Both of these techniques have been used. If you want a simple security argument for the block cipher case, use the pre-stored random number as the key and encrypt 0, 1, 2, and so on. If some can use this output to get the key; or if given encryptions up to n, they can guess the encryption at n+1, then the cipher could not be used in counter mode (since what you are getting is exactly the counter-mode encryption of an all-0-bits message). Obviously, you'll have to store the counter across boots, since otherwise you repeat values. With a hash, you need to be a bit fancier since, in and of itself, the hash has no secret information. This can be done, but it would be trickier; I'd go with the block cipher. Note that there are published algorithms - even part of FIPS standards - that do exactly what you need: Take a single random seed and safely stretch it into a large number of random values. The ones in the standards - and perhaps most of the ones out there - are old and probably not up to contemporary standards. For those interested, this is what we are proposing at the time: Every TCU (the device) comes pre-installed from factory with a Kt known to the device and DENATRAN. SO- TCU (device): sends a SMS with GPRS connection information (apn, user, pass, server IPs/ports). The mechanism so that this first SMS is not a big issue have been, reasonably, covered. TCU-SO: challenge SO-DENATRAN: challenge, SO_id DENATRAN-SO: H(Kt, challenge, SO_id), Kc=H(Kt, challenge) SO-TCU: H(Kt, challenge, SO_id), SO_id You're trying to produce a keyed hash function (or MAC) from a non- keyed hash function. Just pre-pending the secret key is not necessarily secure. I'd suggest using HMAC (with Kt the key, of course). From that point, Kc is stored in SO and TCU, and every message interchanged between the SO and TCU goes signed with Kc (for this we need a H with max. 64 bits output...). Signed? How? I don't understand the 64-bit limitation. I'm not sure a 64-bit signing key is sufficient these days. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Activation protocol for tracking devices
Hi, Jerry Leichter wrote: Not specifically, but you can simply take the first 64 bits from a larger cryptographically secure hash function. OK, I didn't know if it was right to do just that. We were thinking to use that hash in an HMAC so the TCU and SO can know that they were originated from someone who knows Kc and to protect it's integrity (see below). With a hash, you need to be a bit fancier since, in and of itself, the hash has no secret information. This can be done, but it would be trickier; I'd go with the block cipher. Best if we can avoid trickier things!. I was thinking of a hash so maybe we could reuse the ones we were using on other parts of the protocol (since probably asking to include support for a larger set of primitives on all devices would be resisted); but we can, of course, just require that the TCU generates a random challenge and leave the mechanism to be defined by each implementation. Note that there are published algorithms - even part of FIPS standards - that do exactly what you need: Take a single random seed and safely stretch it into a large number of random values. The ones in the standards - and perhaps most of the ones out there - are old and probably not up to contemporary standards. Will take a look at them, thanks. You're trying to produce a keyed hash function (or MAC) from a non-keyed hash function. Just pre-pending the secret key is not necessarily secure. I'd suggest using HMAC (with Kt the key, of course). Yes, I was aware of this, the H should be an HMAC. AFAIK it shouldn't be a problem, just some extra cycles and doing it the right way, right? From that point, Kc is stored in SO and TCU, and every message interchanged between the SO and TCU goes signed with Kc (for this we need a H with max. 64 bits output...). Signed? How? I don't understand the 64-bit limitation. I'm not sure a 64-bit signing key is sufficient these days. The 64 bits limitation is because the protocol only has 1 slot to include *some* auth information, and it's a 64 bits field (yes, it has been defined without knowing what exactly will go there ;)). The protocol was defined by a working group and trying to changing it can be... complicated... unless we have obvious arguments to show that it's insufficient. By signed I meant doing a HMAC(Kc, body of message (with auth field in 0, sic)). Would it be OK in this case to truncate the output of ie. a HMAC-SHA1 to 64 bits? My crypto/math is not good enough to understand how hard would be in this case to modify a msg to reuse a previous signature. Thanks for your comments Jerry! Regards, -- Santiago - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: X.509 certificate overview + status
On Mon, Mar 02, 2009 at 05:35:20PM +0100, Marcus Brinkmann wrote: Travis wrote: Further, trying to dig into ASN.1 was extremely difficult. The specs are full of obtuse language, using terms like object without defining them first. Are there any tools that will dump certificates in human-readable formats? I would really like something that could take a PEM file of a cert and display it in XML or something of the sort. Ubuntu comes with dumpasn1. There are also quite a few libraries. openssl will print certs in a more human readable but slightly less complete format than dumpasn1: % openssl x509 -text cert dumpasn1 does not read PEM, so you need to do % openssl enc -d -c cert cert.der; dumpasn1 cert.der It's a little old but RFC3280 is the most concise and easiest to understand description of X.509 et. al. that I have found. Eric - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
How to Share without Spilling the Beans
A new protocol aims to protect privacy while allowing organizations to share valuable information: http://www.technologyreview.com/communications/22238/?a=f saqib http://www.capital-punishment.net - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: X.509 certificate overview + status
Travis wrote: Hello, Recently I set up certificates for my server's SSL, SMTP, IMAP, XMPP, and OpenVPN services. Actually, I created my own CA for some of the certificates, and in other cases I used self-signed. It took me substantially more time than I had anticipated, and I'm left with feelings of unease. odd. the openssl installations I am familiar with came with example config files that were perfectly functional, took me about ten minutes to figure out what needed doing purely from the man pages and the example config. if ten minutes is too long, just go with xca (http://sourceforge.net/projects/xca) which does it all in a nice, pretty gui for you. A few distros (suse, for example) also have a gui for certificate issuing in their central admin tool. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Activation protocol for tracking devices
As it has been pointed out numerous times on this and other places, this is a singularly bad idea. The crypto isn't even the hardest part (and it's hard enough). Just don't do it. If you are going to spend your energy on anything, it should be to work against such a plan. /ji - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Activation protocol for tracking devices
John Ioannidis wrote: Just don't do it. If you are going to spend your energy on anything, it should be to work against such a plan. I would agree, but I fear that a this is never going to work, drop it will be less heard than any effort in at least trying to raise the bar for an attack. The previous proposed solution at the work group was that the service provider 'configured' the device with an authentication 'word' upon activation an made sure that that 'word' was always present on each message to authenticate it. The only benefit I can see in it (that could very likely been accepted if no one objected) is that is so simple that all bugs are obvious... But I accept that the false sense of security of a complex scheme that is broken somewhere _maybe_ worse than an obviously wrong solution... Santiago. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: How to Share without Spilling the Beans
Ali, Saqib wrote: A new protocol aims to protect privacy while allowing organizations to share valuable information: http://www.technologyreview.com/communications/22238/?a=f Any links to the actual protocol itself? The article is a little vague on details. Thanks. I did not see any discussion of the application that compares the two encrypted objects. Assuming the application has to decrypt it (or there would be no point in sending the secret-key to the other party), what prevents the application developer from writing out the plaintext once decrypted? Would it not have been simpler to just send out the database with message-digests of the names? All one party would have to do is indicate the layout of the plaintext and the digest algorithm. The other party would then digest their own database and compare digested records. There would be no need to send out secret-keys and no possibility of someone writing out plaintext when comparing decrypted objects. Am I missing something? Arshad Noor StrongAuth, Inc. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Activation protocol for tracking devices
On Mar 2, 2009, at 12:56 PM, Santiago Aguiar wrote: Hi, Jerry Leichter wrote: Not specifically, but you can simply take the first 64 bits from a larger cryptographically secure hash function. OK, I didn't know if it was right to do just that. We were thinking to use that hash in an HMAC so the TCU and SO can know that they were originated from someone who knows Kc and to protect it's integrity (see below). All the bits in a cryptographically secure hash function are equally good. So, yes, you can construct a shorter hash by simply discarding bits from a longer one. I would suggest that if you're going to build an HMAC, that you shrink the result as the very last step: Do the internal calculations using the full hash function. I don't see an obvious attack from doing it the other way, but it just seems riskier. With a hash, you need to be a bit fancier since, in and of itself, the hash has no secret information. This can be done, but it would be trickier; I'd go with the block cipher. Best if we can avoid trickier things!. I was thinking of a hash so maybe we could reuse the ones we were using on other parts of the protocol (since probably asking to include support for a larger set of primitives on all devices would be resisted); but we can, of course, just require that the TCU generates a random challenge and leave the mechanism to be defined by each implementation. Note that there are published algorithms - even part of FIPS standards - that do exactly what you need: Take a single random seed and safely stretch it into a large number of random values. The ones in the standards - and perhaps most of the ones out there - are old and probably not up to contemporary standards. Will take a look at them, thanks. Look around for deterministic random number generators or something like that. I'm sure you know this, but do *not* attempt to use a generator designed for statistical purposes - those have good randomness properties but are not secure against deliberate attack. You're trying to produce a keyed hash function (or MAC) from a non- keyed hash function. Just pre-pending the secret key is not necessarily secure. I'd suggest using HMAC (with Kt the key, of course). Yes, I was aware of this, the H should be an HMAC. AFAIK it shouldn't be a problem, just some extra cycles and doing it the right way, right? Yes. From that point, Kc is stored in SO and TCU, and every message interchanged between the SO and TCU goes signed with Kc (for this we need a H with max. 64 bits output...). Signed? How? I don't understand the 64-bit limitation. I'm not sure a 64-bit signing key is sufficient these days. The 64 bits limitation is because the protocol only has 1 slot to include *some* auth information, and it's a 64 bits field (yes, it has been defined without knowing what exactly will go there ;)). The protocol was defined by a working group and trying to changing it can be... complicated... unless we have obvious arguments to show that it's insufficient. By signed I meant doing a HMAC(Kc, body of message (with auth field in 0, sic)). Would it be OK in this case to truncate the output of ie. a HMAC-SHA1 to 64 bits? My crypto/math is not good enough to understand how hard would be in this case to modify a msg to reuse a previous signature. OK, there is a distinction between a signature and a MAC (Message Authentication Code). The significant difference is that it's possible to prove to a third party that someone signed something without actually having the ability to sign things yourself. (Think RSA signatures: The public key is all you need to prove that something was signed with the corresponding private key; but it's insufficient to sign anything.) A MAC is sufficient for your purpose. It's fine to truncate the output of a MAC computation. In fact, there good reasons for doing so in some situations, independent of the available space: By discarding information, it makes certain attacks harder. You'll see people immediately jump in with but the birthday paradox says you lose half your bits, which is true for a hash, but *not* for a MAC, where the attacker doesn't have access to the key. Thanks for your comments Jerry! You're welcome. I hope they're helpful, but don't rely on them too much - my quick response on a mailing list isn't a serious security analysis of the protocol and implementation. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: How to Share without Spilling the Beans
On Mon, 2 Mar 2009, Arshad Noor wrote: Ali, Saqib wrote: A new protocol aims to protect privacy while allowing organizations to share valuable information: http://www.technologyreview.com/communications/22238/?a=f Any links to the actual protocol itself? The article is a little vague on details. Thanks. I believe this is the paper describing the protocol in question: http://eprint.iacr.org/2009/036 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
