Re: Symmetric ciphers as hash functions
On 10/30/05, Arash Partow [EMAIL PROTECTED] wrote: How does one properly use a symmetric cipher as a cryptographic hash function? I seem to be going around in circles. The usual method is to feed the data into the key slot of the cipher, and to use a fixed IV in the plaintext slot. Then, add the IV to the output ciphertext. If the data is too big, break it up into pieces and chain these constructions together. The output of one block becomes the input IV of the next block. To prevent length extension attacks, pad with an unambiguous final suffix that includes the message length. This is basically the Merkle/Damgard construction. CP - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: On Digital Cash-like Payment Systems
By my calculations, it looks like you could take a keypair n,e,d and some integer x and let e'=e^x and d'=d^x, and RSA would still work, albeit slowly. Reminds me of blinding, to some extent, except we're working with key material and not plaintext/ciphertext. Since I'm on the topic, does doing exponentiation in a finite field make taking discrete logarithms more difficult (I suspect so), and if so, by how much? Is there any similar property that could be used on e' and d' to make computing e and d more difficult? Of course whatever algorithm is used, one would need to feed e' and d' to it en toto, but a really clever attacker might be able to take the xth root prior to exfiltrating them. Also, application of a random pad using something like XOR would be useful; could be done as a postprocessing stage independently of the main algorithm used to encrypt the data, or done as a preprocessing stage to the plaintext. I prefer the latter as it makes breaking the superencryption much more difficult, and fixed headers in the ciphertext could give away some OTP material. However, the preliminary encryption in something like gpg would suffer, so it would have the effect of making the ciphertext bigger. Perhaps this is an advantage in your world. An alternate technique relies in specifying, say, 256 bits of key, then using a cryptographically strong PRNG to expand it to an arbitrary length, and storing that for use. Pilfering it then takes more bandwidth, but it could be reconstructed based on the 256-bit seed alone, if one knew the details of the PRNG. So the key could be compressed for transfer, if you know the secret seed. Search for the seed would still be expensive, even if PRNG details are known. Alternately, in a message encrypted with gpg-like hybrid ciphering, one could apply a secret, implicit PRNG to the message key seed before using it as a symmetric key. For example, you could take a 256-bit message key, run it through the PRNG, create 3x256 bits, then use triple-AES to encrypt the message. In this case, the PRNG buys forgery resistance without the use of PK techniques. The PRNG expander could not be attacked without breaking the PK encryption (which supports arbitrarily large keys) of the seed or the triple-AES symmetric encryption of the message. You know, they specify maximum bandwidth of covert channels in bits per second, I wonder if you could use techniques like this to prove some interesting property vis-a-vis covert channel leakage. It's remarkably difficult to get rid of covert channels, but if you inflate whatever you're trying to protect, and monitor flows over a certain size, then perhaps you can claim some kind of resilience against them. *shrug* -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
gonzo cryptography; how would you improve existing cryptosystems?
Hi folks, If one had the ability to create standards over, with reckless disregard for performance, how would you improve their security? Feel free to pick a protocol or system (e.g. gpg or isakmp) and let me know how it is done, and how it should have been done. For example, pgp doesn't hide the key IDs of the addressees. Many systems use hashes that are too small. DSA keys are too small compared to large ElG keys. How would you make a signature with a larger keyspace? Does the protocol wrap encryption in authentication instead of vice-versa? Does ISAKMP do encryption where the input is meant to be secret, instead of the key? Does it use a rinky-dink algorithm, now that much better ones are available? I've got a hankering to re-write something, and I want to know what can be improved the most. PS: There's a paper on cryptanalyzing CFS on my homepage below. I got to successfully use classical cryptanalysis on a relatively modern system! That is a rare joy. CFS really needs a re-write, there's no real good alternatives for cross-platform filesystem encryption to my knowledge. -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: gonzo cryptography; how would you improve existing cryptosystems?
Does ISAKMP do encryption where the input is meant to be secret, instead of the key? I meant MAC, not encryption, sorry. Of course encryption inputs are secret. -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: HTTPS mutual authentication alpha release - please test
On 10/31/05, Nick Owen [EMAIL PROTECTED] wrote: The system works this way: Each WiKID domain now can include a 'registered URL' field and a hash that website's SSL certificate. When a user wants to log onto a secure web site, they start the WiKID token and enter their PIN. The PIN is encrypted and sent to the WiKID server along with a one-time use AES key and the registered URL. The server responds with a hash of the website's SSL certificate. The token client fetches the SSL certificate of the website and compares it the hash. If the hashes don't match, the user gets an error. If they match, the user is presented with registered URL and the passcode. On supported systems, the token client will launch the default browser to the registered URL. What threat is this supposed to defend against? Is it phishing? I don't see how it will help, if the bogus site has a valid certificate. Most one-time-password systems suffer from man-in-the-middle attacks primarily due to difficulties users have with validating SSL certificates. The goal of this release is to validate certificates for the end user, providing an SSH-esque security for web-enabled applications such as online banking. What does it mean to validate a certificate? Aren't certs self-validating, based on the key of the issuer? Again, what is this protecting against? CP - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: HTTPS mutual authentication alpha release - please test
-- It seems to me that mutual authentication is pretty much irrelevant to HTTPS and certificates. You mutually authenticate by both knowing the password, as in SPEKE. Of course, SPEKE is patented, so is this scheme a way of getting around the patents? --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG a5RzA9UesxiZw+cjRsz+8yPLKwJdTMfUjcQq0iZf 4ybo9wAzZZNG5YyF69jzKw/oXw3fL7FGj86oXey46 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: HTTPS mutual authentication alpha release - please test
On Fri, Nov 04, 2005 at 09:16:16AM +, Nick Owen wrote: No, this is not it. It is this attack and similar: http://tinyurl.com/a3b89 The phishers are not using valid certificates, but users are so immune to warnings about certificates that they don't pay attention to them. It may be a DNS cache poison or the typical email; it could be any mechanism to send the user to a fraudulent site. What is being provided is a mechanism to route the users to the correct site by providing a way to validate the certificate for them. Mmmh, I'd have two questions about this: - It seems that you are not defending against an attack, but trying to protect the user against his own ignorance. The user ignores the warning label, so you want to replace it with a bigger warning label. But the bigger warning label doesn't contain any news or more information, or any protection that the smaller label doesn't provide. It's just that the bigger warning label is bigger (or more red, or more alerting letters...), hoping to wake the user up? But user ignorance is not a new type of attack. If the user pays attention to the browser warnings, then I don't see what advantage WIKD should have. Inventing new protocols and complexity, and trusting an additional party without good reason and reasonable advantage is never a good idea in security. - The authorized owner must be able to replace the server certificate with a new one at any time, e.g. when the secret key has been lost or compromised. case 1: If it is not possible to update the hash stored at WIKID, how would the authorized owner ever be able to replace the compromised key with a new one? Wouldn't this force him into continuing in using the compromised key? case 2: If it is possible to update the hash stored at WIKID, and if the attacker was already able to register a bogus certificate at an official CA, why shouldn't he be able to update the certificate at WIKID as well? In what way is WIKID's certificate verification procedure more reliable than the one of the trusted CAs ? Hadmut - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: On the orthogonality of anonymity to current market demand
I'd recommend DRM (I think what you really mean is Palladium, err, excuse me, the Trusted Computing Platform Alliance, see the web site and Ross Anderson's take on it) to my grandmother, because I don't trust her to understand the implications of clicking on something in an email (thank you active content!). Many OSes don't allow ordinary users the privileges of compromising their security so easily as Microsoft. I suppose we can rely on vendor-written code to do approximately what it claims to do, most of the time, but have you actually read the claims in EULAs and Privacy Policies lately? It seems like you'd be trading one set of problems for another. Personally, I'm less suprised by my own software (and, presumably, key-handling) than vendor software, most of the time. I think TCPA is about control, and call me paranoid, but ultimate control isn't something I'm willing to concede to any vendor, or for that matter any other person. I like knowing what my computer is doing, to the bit and byte level, or at least being able to find out. -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: HTTPS mutual authentication alpha release - please test
James A. Donald wrote: -- It seems to me that mutual authentication is pretty much irrelevant to HTTPS and certificates. You mutually authenticate by both knowing the password, as in SPEKE. Of course, SPEKE is patented, so is this scheme a way of getting around the patents? We're not that smart - well, perhaps I should speak only for myself. We originally developed WiKID to target corporate VPNs with the WiKID client running on a wireless device (the Wi in WiKID) with no thought of mutual authentication because phishing was only getting under way. Only after we added the client support for Windows, Mac linux and phishers started getting really active did we think about adding MA. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG a5RzA9UesxiZw+cjRsz+8yPLKwJdTMfUjcQq0iZf 4ybo9wAzZZNG5YyF69jzKw/oXw3fL7FGj86oXey46 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor Now open source: http://sourceforge.net/projects/wikid-twofactor/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[Clips] The Other Ester: Anonymity-- Here Today, Gone Tomorrow
--- begin forwarded text Delivered-To: [EMAIL PROTECTED] Date: Mon, 7 Nov 2005 14:43:46 -0500 To: Philodox Clips List [EMAIL PROTECTED] From: R.A. Hettinga [EMAIL PROTECTED] Subject: [Clips] The Other Ester: Anonymity-- Here Today, Gone Tomorrow Reply-To: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] http://www.release1-0.com/freshproduce/article.cfm?serialnum=FRP200511042301 Anonymity: Here Today, Gone Tomorrow Esther Dyson It's ironic that the Web once seemed to promise individuals new opportunities to explore the world without showing their face. Instead, it is turning out to be a powerful force against anonymity. Most information about people's online actions is traceable - if someone with resources cares to go to the trouble. But there will be much more to this trend than the familiar fear of governments spying on innocent victims, or even they-asked-for-it dissidents. The bigger questions revolve around the tolerance of societies for diversity and recognition of the human capacity for change. A free membership to Release 1.0 is required to view this item. Login below or register to join our community. User name: Password: -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' ___ Clips mailing list [EMAIL PROTECTED] http://www.philodox.com/mailman/listinfo/clips --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: On the orthogonality of anonymity to current market demand
On 11/6/05, Travis H. [EMAIL PROTECTED] wrote: Personally, I'm less suprised by my own software (and, presumably, key-handling) than vendor software, most of the time. I think TCPA is about control, and call me paranoid, but ultimate control isn't something I'm willing to concede to any vendor, or for that matter any other person. I like knowing what my computer is doing, to the bit and byte level, or at least being able to find out. I suggest that you're fooling yourself, or at least giving yourself a false sense of security. Software today is so complex and large that there is no way that you can be familiar with the vast bulk of what you are running (and it's only going to get worse in the future). It is an illusion that you have transparency into it. Water is transparent but an ocean of it is opaque and holds many secrets. CP - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: gonzo cryptography; how would you improve existing cryptosystems?
On Fri, 4 Nov 2005, Travis H. wrote: PS: There's a paper on cryptanalyzing CFS on my homepage below. I got to successfully use classical cryptanalysis on a relatively modern system! That is a rare joy. CFS really needs a re-write, there's no real good alternatives for cross-platform filesystem encryption to my knowledge. Take a look at ecryptfs before rewriting cfs: http://sourceforge.net/projects/ecryptfs -J - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: On Digital Cash-like Payment Systems
On 11/4/05, Travis H. [EMAIL PROTECTED] wrote: By my calculations, it looks like you could take a keypair n,e,d and some integer x and let e'=e^x and d'=d^x, and RSA would still work, albeit slowly. Reminds me of blinding, to some extent, except we're working with key material and not plaintext/ciphertext. Your point would be to make the encryption key very large? Unfortunately, making it large enough to present any kind of challenge to an attacker who is plucking files off a trojaned computer would make it far too large to be used, with this system. Since I'm on the topic, does doing exponentiation in a finite field make taking discrete logarithms more difficult (I suspect so), and if so, by how much? This doesn't make sense. The discrete log operation is the inverse of exponentiation. Doing exponentiation is a prerequisite for even considering discrete log operations. Hence it cannot make them more difficult. Is there any similar property that could be used on e' and d' to make computing e and d more difficult? Of course whatever algorithm is used, one would need to feed e' and d' to it en toto, but a really clever attacker might be able to take the xth root prior to exfiltrating them. That's a new word to me. What is your goal here, to make something that is even stronger than RSA? Or is it, as in the context of this thread, to inflate keys, making them bigger so that an attacker can't download them easily? Also, application of a random pad using something like XOR would be useful; could be done as a postprocessing stage independently of the main algorithm used to encrypt the data, or done as a preprocessing stage to the plaintext. I prefer the latter as it makes breaking the superencryption much more difficult, and fixed headers in the ciphertext could give away some OTP material. However, the preliminary encryption in something like gpg would suffer, so it would have the effect of making the ciphertext bigger. Perhaps this is an advantage in your world. That's not feasible in most cases. If you really have a OTP handy, why are you bothering with RSA? Or are you planning to use it as a two-time-pad? That generally doesn't work well. (The fact that you are worried about giving away OTP material is not a good sign!) An alternate technique relies in specifying, say, 256 bits of key, then using a cryptographically strong PRNG to expand it to an arbitrary length, and storing that for use. Pilfering it then takes more bandwidth, but it could be reconstructed based on the 256-bit seed alone, if one knew the details of the PRNG. So the key could be compressed for transfer, if you know the secret seed. Search for the seed would still be expensive, even if PRNG details are known. So where do you store this 256 bit seed? You want to distract the attacker with the smoke and mirrors of the big file for him to download, hoping he will ignore this little file which is all he really needs? I think we are assuming the attacker is smarter than this, otherwise you could just use regular key files but give them obscure names. Alternately, in a message encrypted with gpg-like hybrid ciphering, one could apply a secret, implicit PRNG to the message key seed before using it as a symmetric key. For example, you could take a 256-bit message key, run it through the PRNG, create 3x256 bits, then use triple-AES to encrypt the message. In this case, the PRNG buys forgery resistance without the use of PK techniques. The PRNG expander could not be attacked without breaking the PK encryption (which supports arbitrarily large keys) of the seed or the triple-AES symmetric encryption of the message. What is forgery resistance in this context? A public key encryption system, by definition, allows anyone to create new encrypted messages. Your technique is complicated but it is not clear how much security it adds. Fundamentally it is not too different from RSA + counter mode, where CTR can be thought of as a PRNG expanding a seed. This doesn't seem to have anything to do with the thread topic. Are you just tossing off random ideas because you don't think ordinary hybrid RSA encryption is good enough? You know, they specify maximum bandwidth of covert channels in bits per second, I wonder if you could use techniques like this to prove some interesting property vis-a-vis covert channel leakage. It's remarkably difficult to get rid of covert channels, but if you inflate whatever you're trying to protect, and monitor flows over a certain size, then perhaps you can claim some kind of resilience against them. *shrug* I'm not sure conventional covert-channel analysis is going to be that useful here, because the bandwidths we are looking at in this attack model are so much greater (kilobytes to megabytes per second). But broadly speaking, yes, this was Daniel Nagy's idea which started this thread, that making the key files big enough would make it more likely to catch someone
GnuTLS 1.2.9
I thought that this might be of some interest; I just released a new version of GnuTLS that disable RSA-MD5 for some X.509 uses by default. See announcements and details below. Feedback and suggestions are always welcome. Cheers, Simon From: Simon Josefsson [EMAIL PROTECTED] Subject: GnuTLS 1.2.9 Date: Mon, 07 Nov 2005 22:34:46 +0100 We are pleased to announce the availability of GnuTLS version 1.2.8. GnuTLS is a modern C library that implement the standard network security protocol Transport Layer Security (TLS), for use by network applications. This is the last non-bugfix release in the 1.2.x series. We will open the 1.3.x branch after this release. The goal of 1.3.x will be to merge work currently done on CVS branches, for TLS Pre-Shared-Keys and TLS Inner Application. Other planned improvements in 1.3.x are system-independent resume data structures, modularization of the bignum operations, and TLS OpenPGP improvements. This release disable the RSA-MD5 algorithm when verifying untrusted intermediary X.509 CA certificates. This decision was made based on the results in Lenstra, Wang and Weger's Colliding X.509 Certificates. This is discussed in more detail, including instructions on how to re-enable the algorithm for application's that need backwards compatibility, in: http://josefsson.org/gnutls/manual/html_node/Digital-signatures.html Noteworthy changes since version 1.2.8: - Documentation was updated and improved. - RSA-MD2 is now supported for verifying digital signatures. - Due to cryptographic advances, verifying untrusted X.509 certificates signed with RSA-MD2 or RSA-MD5 will now fail with a GNUTLS_CERT_INSECURE_ALGORITHM verification output. For applications that must remain interoperable, you can use the GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2 or GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5 flags when verifying certificates. Naturally, this is not recommended default behaviour for applications. To enable the broken algorithms, call gnutls_certificate_set_verify_flags with the proper flag, to change the verification mode used by gnutls_certificate_verify_peers2. - Make it possible to send empty data through gnutls_record_send, to align with the send(2) API. - Some changes in the certificate receiving part of handshake to prevent some possible errors with non-blocking servers. - Added numeric version symbols to permit simple CPP-based feature tests, suggested by Daniel Stenberg [EMAIL PROTECTED]. - The (experimental) low-level crypto alternative to libgcrypt used earlier (Nettle) has been replaced with crypto code from gnulib. This leads to easier re-use of these components in other projects, leading to more review and simpler maintenance. The new configure parameter --with-builtin-crypto replace the old --with-nettle, and must be used if you wish to enable this functionality. See README under Experimental for more information. Internally, GnuTLS has been updated to use the new Generic Crypto API in gl/gc.h. The API is similar to the old crypto/gc.h, because the gnulib code were based on GnuTLS's gc.h. - Fix compiler warning in the anonself self test. - API and ABI modifications: gnutls_x509_crt_list_verify: Added 'const' to prototype in gnutls/x509.h. This doesn't reflect a change in behaviour, so we don't break backwards compatibility. GNUTLS_MAC_MD2: New gnutls_mac_algorithm_t value. GNUTLS_DIG_MD2: New gnutls_digest_algorithm_t value. GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2, GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5: New gnutls_certificate_verify_flags values. Use when calling gnutls_x509_crt_list_verify, gnutls_x509_crt_verify, or gnutls_certificate_set_verify_flags. GNUTLS_CERT_INSECURE_ALGORITHM: New gnutls_certificate_status_t value, used when broken signature algorithms is used (currently RSA-MD2/MD5). LIBGNUTLS_VERSION_MAJOR, LIBGNUTLS_VERSION_MINOR, LIBGNUTLS_VERSION_PATCH, LIBGNUTLS_VERSION_NUMBER: New CPP symbols, indicating the GnuTLS version number, can be used for feature existence tests. Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. If you need help to use GnuTLS, or want to help others, you are invited to join our help-gnutls mailing list, see: http://lists.gnu.org/mailman/listinfo/help-gnutls. The
