RE: Intuitive cryptography that's also practical and secure.
I am not convinced that we need intuitive cryptography. Many things in life are not understood by the general public. How does a car really work: most people don't know but they still drive one. How does a microwave oven work? People don't need to understand the details, but the high level concept should be simple: If that is what you are trying to convey, I agree with you. I guess we could very well do with some cryptographic simplifications. Hash functions are one example. We have security against arbitrary collisions, 2nd pre-image resistance, preimage resistance. Most of our hash functions today don't satisfy all of these properties: Oh SHA1 is vulnerable to aribitrary collisions attacks, but it is still safe agains 2nd pre-image attacks, so don't worry! Why do we need all of these properties? In most cases, we don't. Mathematical masturbation might be to blame? Block cipher encryption. How many modes of operations exist? Some use a counter, others need a random non predictable IV, others just need a non repeatable IV? Do we need all of this? I often find myself explain these concepts to non-cryptographers. I'm often taken for a crazy mathematician. What is the length of a private key? In 1024-bit RSA, your d is about 1024 bits. But is d your private key, or is it (d,N), in which case there is more than 1024 bits! No, N is public, the known modulus, but you need it to decrypt, you can't just use d by itself. Oh, in DSA the private key is much shorter. You actually also need a random k, which you can think of as part of your key, but it's just a one time value. Are we talking about key lengths, of modulus lengths really? When you encrypt with RSA, you need padding. With Elgamal, you don't need any, complicated story. And don't use just any padding. You would be foolish to use PKCS#1 v1.5 padding, everybody knows that right? Use OAEP. It is provably broken, but works like a charm when you encrypt with RSA! Going back to the million dollar paranormal challenges: Something like a Windows SAM file containing the NTLM v2 hash of the passphrase consisting of the answer might be something to consider? Not perfect but... --Anton -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Blaze Sent: January 26, 2007 5:58 PM To: Cryptography Subject: Intuitive cryptography that's also practical and secure. I was surprised to discover that one of James Randi's million dollar paranormal challenges is protected by a surprisingly weak (dictionary- based) commitment scheme that is easily reversed and that suffers from collisions. For details, see my blog entry about it: http://www.crypto.com/blog/psychic_cryptanalysis/ I had hoped to be able to suggest a better scheme to Randi (e.g., one based on a published, scrutinized bit commitment protocol). Unfortunately I don't know of any that meets all his requirements, the most important (aside from security) being that his audience (non-cryptographers who believe in magic) be able to understand and have confidence in it. It occurs to me that the lack of secure, practical crypto primitives and protocols that are intuitively clear to ordinary people may be why cryptography has had so little impact on an even more important problem than psychic debunking, namely electronic voting. I think intuitive cryptography is a very important open problem for our field. -matt - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Private Key Generation from Passwords/phrases
Bill Stewart wrote: Salt is designed to address a couple of threats - Pre-computing password dictionaries for attacking wimpy passwords ... Yes indeed. The rainbow-tables style attacks are important to protect against, and a salt does the trick. This is why you can find rainbow tables for LanMan and NTLMv1 hashed passwords, but not for NTLMv2. This to me is the most important property achieved with a salt, and the salt doesn't have to be that big to be effective. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Exponent 3 damage spreads...
O.k., thanks to Hal Finney for pointing out to me in a private email that my modulus wasn't in fact the right size. I have had some problems with the openssl key generation (doesn't always seem to generate the exact modulus size I ask for). In attachment, the forged signature opensslB-fake-bin.sig on messageBunicode.txt which can be validated using the new key I generated bellow. I took the same s that I computed beforehand, without reducing it this time. The value s is independent of the value of the modulus of the public key (only dependency is the size) So here are the instructions, once again (but I bit simplified): I followed the instructions of Hal Finney's excellent post: http://www.mail-archive.com/cryptography@metzdowd.com/msg06537.html I started out by generating 3072 RSA key pair, with public exponent e = 3. openssl genrsa -des3 -3 -out my.key 3072 (make sure that the modulus is really 3072 bits, no less no more). the resulting key can be found at the end of this post, the passwords is test if you ever want to use it. I also included the public key certificate by itself. All in PEM format. I created a plaintext message messageBunicode.txt on which I want to forge a signature. The file can be found in attachment, it is in Unicode because I wanted to also try this out with a VBscript implementing a signature function using CAPICOM, in which all plaintext is transformed into UNICODE (pretty annoying!). The hash of this file is openssl dgst -sha1 messageBunicode.txt SHA1(messageBunicode.txt)= 5d89b46034e0f41a920b2fa964e230ebb2d040b0 Now, let's create a valid signature over messageBunicode.txt using the private key, just to see what the output looks like: openssl dgst -hex -sha1 -sign my.key messageBunicode.txt Enter pass phrase for my.key: SHA1(..\messageBunicode.txt)= bb029c611d34e98188eb23bd1a836ec7305e94fc726577a59c8dab927fb6c5b3fce549be389f 6b15d8608c15a256f4209c7e76ed1186d8382242d53ee36e47b2d8ccb09be0440dcdcb373e37 967cfbe9d38b12a16dc9aa78e20e1303f8033f27b4c679dc215ac56b4bf33edc2c50f73d3da9 424bc072de81674b1905020546a9e57e3f96ceef7932751b94883f0409577ed7c0aa8cbed272 8dabf2a6df334357df2cabf7f5282107b6ec99e2bf0f65cd992a97f2f3e004e35739a368823c 4c0cebe4fdff53a9f039c2d85e57feff81284c7db97823359d9982da23707c8a48923e16e09e 13803cb5da3d87b94d32b5241198d91d490a3d1b343448b528e853d2add80679054e39e2e21c 1096ba66100ea73559c283c4f281fbf82fa292e6bc1dc5df5773affc3ea2425ce95ac779e7d7 90f59d11e3527d5645d9580bbf68909c2a1c4672204859cf46caa247186d917241a79224c9b6 95499644aeea43daefdc5438e9b96952771f1fbc809655ef5a5a5a148ffd47197369f4a85498 3220596a Now, let's do some bignumber math. I wanted to look at the value obtained when you verify a signature (RSA encrypt the signature with exponent 3). I use BC, a bignumber calculator I like allot: http://www.gnu.org/software/bc/ A version that can be installed on Windows: http://gnuwin32.sourceforge.net/packages/bc.htm I use a fast modexp function I implemented for BC, available at http://crypto.cs.mcgill.ca/~stiglic/Programming/modgroup.bc You can load it by simply calling bc like this: bc modgroup.bc I did all the calculations in hex, so typed the following in bc obase=16 ibase=16 Now, denote by sp the signature given above, e = 3 and m is the modulus in the public key certificate I generated. When pasting the values into BC, the hex digits need to be in capital letters. You can get the value of the modulus by using an ASN.1 interpreter, such as ASN.1 Editor or Peter Gutmann's dumpASN1 program. Here are the BC calculations: sp BB029C611D34E98188EB23BD1A836EC7305E94FC726577A59C8DAB927FB6C5B3FCE5\ 49BE389F6B15D8608C15A256F4209C7E76ED1186D8382242D53EE36E47B2D8CCB09B\ E0440DCDCB373E37967CFBE9D38B12A16DC9AA78E20E1303F8033F27B4C679DC215A\ C56B4BF33EDC2C50F73D3DA9424BC072DE81674B1905020546A9E57E3F96CEEF7932\ 751B94883F0409577ED7C0AA8CBED2728DABF2A6DF334357DF2CABF7F5282107B6EC\ 99E2BF0F65CD992A97F2F3E004E35739A368823C4C0CEBE4FDFF53A9F039C2D85E57\ FEFF81284C7DB97823359D9982DA23707C8A48923E16E09E13803CB5DA3D87B94D32\ B5241198D91D490A3D1B343448B528E853D2ADD80679054E39E2E21C1096BA66100E\ A73559C283C4F281FBF82FA292E6BC1DC5DF5773AFFC3EA2425CE95AC779E7D790F5\ 9D11E3527D5645D9580BBF68909C2A1C4672204859CF46CAA247186D917241A79224\ C9B695499644AEEA43DAEFDC5438E9B96952771F1FBC809655EF5A5A5A148FFD4719\ 7369F4A854983220596A m C68C6FEA9A08822C1DA79D4D975F95BF9EB56A906A66F7B63AF7CFC5B7A43012DDB4\ 2779002AFE4109922FA7B98CECDED22CADDBF1B1F116C79E9068D62A3B371318EA1C\ 56CA2106F196D0E6E8DE2D95D300935F5942638220073E311EB59FE9E2D7F84E\ F753A415E47E42604175F4B7F1AF52838B0BBA5769120B8DAFA1FFB5C96D961BA1E5\ 20717202DE09379F34960F03FE196F0A97704BFE32A5DF0D81445E8DDBAF750B5213\ 3EBF07D4859032AE392F161544BE5860579ABA6A6F34395D44754DC24C5C37D90F7F\ 017F7225F4EA20D4EADD7BEAFA9025D6D58B49DB151FB6C5C5F2CF6BE9175DCFE96D\ 5B752C00D71F032C6E89DEE85514816C50AC70D53A6417B30E93EA640E0E274BE926\ 4E94C9D1BE835EE252EB9550AFB7E26DCD3E42407F0797332562C2CA202A5A7C200A\
RE: Exponent 3 damage spreads...
Thanks for taking the time to look at this. But I recounted, and I count 765 hex (with the formatting I get in my mail, 11 lines of 68 hex + 17 hex at the end), which gives 3060 bits. Considering that the first hex is 1 and can be represented in 1 bit, not for, that would give 3060 - 3 = 3057 bits. The modulus is the same size, but starts with 1D instead of 1F (the beginning of s^3), so s^3 is bigger. My bc library has a function called bits which returns the number of bits, I get 3057 in both cases, see bellow (also look at the value of m - s, which is negative, and modexp(s, 3, m) which doesn't have the form we want, but modexp(s/100, 3, m) does). But I seem to remember now that in openssl, mod(x, y) doesn't always return a value which is between 0 and y, maybe it would accept my s. Will try it. --Anton m 1D851D5148345606F586935D227CD5CF7F04F890AC5024178BA5F4EE85D7796918C3\ DC7A5951C985539CB240E28BA4AC3AFBE0F6EB3151A0DBAFD686C234A30D07D590D6\ 1A5474491BF0D68E1AC7F94CDC989C19C2E25B12511A29FFAF5F11E0B994E19C5C3D\ C298F9E584FFF3C7DBB8F703A0EAD97167F88C7229BBFA55B449CDE4C91B409D5B9A\ CF0134CB61352E9CE6CB3D847C7F3D9AFA74E8E19DD1ED7923270E310A5D91E97EF1\ 98694465950715AA066ACB06FAEC0BA64FCCCA155104852EFD41346F75D1ACB8574B\ BE3C7C8D6D1B501C1163AD2058506DF1B64059A6932C0672FB9D094364EA4D7FA044\ 42B8E643B74B8746B594866C7CBDAB8FEA954FDEE7C44B9C5D6B9E19B49082D65B51\ 7EA7DBFEF5CA1EEA39AB2283CDB854C8B246F2B8EFE51895349640248A3248EC65F6\ 4A89CA5AB194B444DF676B015AFBCACE13697CEEB5268F5E9AA674A83DD1B0CE4DC8\ 3603CFFB801DB669216FC647CD7A6A84831E421D9676C7AAC44411B2AB3E901A7139\ B3519B58EBAEEC20B s 7FFF\ \ FFEAAEAD6EAB6B2B18EBD595822B1555\ AC5D20CF08046814578C2B994E1DBD8413A43C05640 bits(m) BF1 bits(s^3) BF1 m - s^3 -27AE2AEB7CBA9F90A796CA2DD832A3080FB076F53AFDBE8745A0B117A288696E73C\ 2385A6AE367AAC634DBF1D745B53C5041F0914CEAE5F245029793DCB5CF2F82A6F29\ E5AB8BB6E40F2971E53806B3236763E63D1DA4DDB1E7E900E10140D0269B4003F3C2\ 7EACDEB5C1035A4765F029AF59AB74B1A6C2A091E14405AA4BB6321B36E4BF62A465\ 30FECB349ECAD1631934C27B8380C265058B171E622E1286DCD8F1CEF5A26E16810E\ 6796BB9A6DA29467C54B41AC61C95E3785A9F85D4578F21C056D03ECF9128580717D\ 563B5F437FEB9CDCAAE7E01D6C84F908AF5336EC3D710D6DF1F282A270E150F32438\ 31826C7843300F514A6B799383425470156AB021183BB4637CBCB87B1902C4D519D7\ 52B7C10EC94263DF2E26A5466F17150A2E4E2745BD967E5CC8352D58EE7A5237E637\ 3B36C59357EE1C3BCBBAE5A3EBFA812347B2D71FF03ECAD84A80E22419EA004D6C73\ 4BD35CE67B61094E6292B8E8BA5005F3D0F436A6C0EE1F47EDAFD37F94C16FE58EC6\ 4CAE64A7145113DF5 modexp(s, 3, m) 27AE2AEB7CBA9F90A796CA2DD832A3080FB076F53AFDBE8745A0B117A288696E73C2\ 385A6AE367AAC634DBF1D745B53C5041F0914CEAE5F245029793DCB5CF2F82A6F29E\ 5AB8BB6E40F2971E53806B3236763E63D1DA4DDB1E7E900E10140D0269B4003F3C27\ EACDEB5C1035A4765F029AF59AB74B1A6C2A091E14405AA4BB6321B36E4BF62A4653\ 0FECB349ECAD1631934C27B8380C265058B171E622E1286DCD8F1CEF5A26E16810E6\ 796BB9A6DA29467C54B41AC61C95E3785A9F85D4578F21C056D03ECF9128580717D5\ 63B5F437FEB9CDCAAE7E01D6C84F908AF5336EC3D710D6DF1F282A270E150F324383\ 1826C7843300F514A6B799383425470156AB021183BB4637CBCB87B1902C4D519D75\ 2B7C10EC94263DF2E26A5466F17150A2E4E2745BD967E5CC8352D58EE7A5237E6373\ B36C59357EE1C3BCBBAE5A3EBFA812347B2D71FF03ECAD84A80E22419EA004D6C734\ BD35CE67B61094E6292B8E8BA5005F3D0F436A6C0EE1F47EDAFD37F94C16FE58EC64\ CAE64A7145113DF5 modexp(s/100, 3, m) 1FFF\ \ FFF003021300906052B0E03021A05000\ 4145D89B46034E0F41A920B2FA964E230EBB2D040B00\ \ 02A9AA11CBB60CB35CB569DDD576C272967D774B02AE385C6EE43238C8C9\ 1477DBD0ED06ECF8BC4B8D3DC4D566FA65939092D09D13E0ED8F8BE5D5CB9E72C47C\ 743B52BBFA7B9697DA285694CD9347AB7528\ D15F9D0DBF0C82C967D1C7CA3CCF69D2E09519FEAD7B96F1FCCB6D7D78AC9B244C2D\ 85C08FEE0982D080AB2250A546F64BF15B1C540EA5655A36E52756CC57BBB11BBA3B\ 81D72CE1FB7EBFB784027F3087CA7078541278C45764E6F2B1F3E5324000\ 000 -Original Message- From: Hal Finney [mailto:[EMAIL PROTECTED] Sent: September 20, 2006 6:21 PM To: [EMAIL PROTECTED]; cryptography@metzdowd.com Subject: RE: Exponent 3 damage spreads... Anton Stiglic writes: I tried coming up with my own forged signature that could be validated with OpenSSL (which I intended to use to test other libraries). ... Now let's look at s^3 1FFF\ \ FFF003021300906052B0E03021A05000\ 4145D89B46034E0F41A920B2FA964E230EBB2D040B00
Re: Why the exponent 3 error happened:
As other's have mentioned, I don't believe the small RSA exponent (e = 3) is to blame in Bleichenbacher's attack. Indeed, the mathematical problem of computing the cubic root of m modulo an rsa modulus n, for a *fixed*, arbitrary m, is still considered to be hard (no one has shown the opposite). What Bleichenbacher demonstrated is that computing the cubic root of m' || G, where G can be any value, garbage, and is sufficiently large, is easy. These are two different problems, and the vulnerability is due to the fact that these libraries allow for the variant G part. I don't see ASN.1 as being faulty either. The ASN.1 simply acts as a value that allows you to determine what hash algorithm to use. If the encrypted signature would be of the form: What-ever-padding, hash, header and implementations would directly go to the least significant bits in order to retrieve the header (which should be of fixed size), and then retrieve the hash, we wouldn't have this problem. I believe you should put the most sensitive information in the least significant bytes, which are harder to manipulate (Bleichenbacher's attack plays with the most significant bytes, the least significant bytes are basically random in his calculations, he doesn't have control over them). This reminds me of the RSA lsb hardness problem theorem http://www.wisdom.weizmann.ac.il/~oded/annot/node17.html I have notes explaining it right here, section 8.4.1: http://crypto.cs.mcgill.ca/~stiglic/Papers/crypto2.ps The theorem basically says that if you can predict the least significant bit of the plaintext given the corresponding RSA ciphertext, than you can compute the whole plaintext. The theorem doesn't directly apply however (RSA signature verification uses the encryption operation, not decryption), but may be of some insight. The problem is that we (crypto community) still don't have a good way of writing specs. This is in fact a hard problem. And the problem doesn't get easier with the increasing complexity of the specs. We need simple algorithms and protocols, which allow just enough flexibility, and we need a good and precise way to write specs for these. On one side you have theoretical cryptographers / mathematicians who work in an abstract level, develop algorithms and protocols, but dont have much interest in implementing these other than possibly in a prototype form. On the other end, you have developers who excel in coding and system integration but dont necessarily understand the theoretical background in all its details. Specifications act as a bridge between these two worlds, but this bridge is not very solid today. We need to do allot more effort into building stronger bridges. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Exponent 3 damage spreads...
I tried coming up with my own forged signature that could be validated with OpenSSL (which I intended to use to test other libraries). I haven't succeeded, either because in the particular example I came up with OpenSSL does something that catches the invalid signature, or I messed up somewhere (the likelihood of which is far from negligible). Unfortunately, I don't have much more time to play with this. I decided to share the methodology I used with those of you who are interested in case the info is helpful to anyone, or someone can tell me why the signature I produced doesn't get validated by OpenSSL. I followed the instructions of Hal Finney's excellent post: http://www.mail-archive.com/cryptography@metzdowd.com/msg06537.html I started out by generating 3072 RSA key pair, with public exponent e = 3. openssl genrsa -des3 -3 -out my.key 3072 the resulting key can be found bellow, the passwords is test if you ever want to use it. Then I created the corresponding public key certificate: openssl req -new -x509 -days 1001 -key my.key -out my.cer The public key certificate can be found bellow as well. You can import this in Windows key store, for example. I then created a plaintext file, messageAunicode.txt, for which I computed a signature on (a valid signature). The idea was then to forge a signature on an alternate messageBunicode.txt, without using the private key of course. The two files can be found in attachment, they are in Unicode because I wanted to also try this out with a VBscript implementing a signature function using CAPICOM. (you can get a file in Unicode by opening it with a simple text editor that allows you to save as Unicode, such as notepad, and erase any extra bytes (header) with a hex editor such as XVI32). The hashes of these files are openssl dgst -sha1 messageAunicode.txt SHA1(messageAunicode.txt)= eb8302606217ae549fe6ab1345f0b4c804195367 openssl dgst -sha1 messageBunicode.txt SHA1(messageBunicode.txt)= 5d89b46034e0f41a920b2fa964e230ebb2d040b0 Now, create the valid signature over messageAunicode.txt to see what the output looks like: openssl dgst -hex -sha1 -sign my.key messageAunicode.txt Enter pass phrase for my.key: SHA1(messageAunicode.txt)=00d3cda91b578b6df29aeb140272bd9198759f79fa10dc410b 5d10362048ac7abe5df7fe0d94a6646e791c5b95b29f2c6384a570769dc888ed0b7ad510ccd3 c758cebeb648511620490e0fd54162badb1ed05411acc853509b62a4c1b242e1e2f737a1e7e4 340f5a79b05ec3475d7ba6fc73b3302f1258abac1079f11e8dfb9fc09d42716ba4054add460b b12fc1b0b8d5d32db50395374aeb3c215c2bc566328d2f03bf043068c5c9abc649ba1767e97d f32b6aa734594ee22fffe7fb06ea3b77030e79bd6fe7683ab7ffce462abfba5777b3914de466 5b86c1ec203feb6fccb3dadb8ba51fd87a7457c62385418e65d17809c4256e3d27dc2017d7a0 93c8bd193a09168f34d522dd7d3afb95fc61c9f4339091cf25d78bf461b4ea5620eed722ab7d 3eff99cea4a4f546bff6ce338d7763aff20a9b61452da07179590d3316bbce63b06b43d996d7 75d6843f46633ff107a3c866e3b0a8aaaea31f4a2048c9fcb448958287f8e961c9f3393e18fc 9a05460d51a286737aec14a1a7b27a51 Now, let's do some bignumber math. I wanted to look at the value obtained when you verify a signature (RSA encrypt the signature with exponent 3). I use BC, a bignumber calculator I like allot: http://www.gnu.org/software/bc/ A version that can be installed on Windows: http://gnuwin32.sourceforge.net/packages/bc.htm I use a fast modexp function I implemented for BC, available at http://crypto.cs.mcgill.ca/~stiglic/Programming/modgroup.bc You can load it by simply calling bc like this: bc modgroup.bc I did the calculations all in hex, so typed the following in bc obase=16 ibase=16 Now, denote by s the signature given above, e = 3 and m is the modulus in the public key certificate I generated. When pasting the values into BC, the hex digits need to be in capital letters. You can get the value of the modulus by using a ASN.1 viewer, such as ASN.1 Editor or Peter Gutmann's ASN1dump. Here are the BC calculations: s=00D3CDA91B578B6DF29AEB140272BD9198759F79FA10DC410B5D10362048AC7ABE5DF7FE0D 94A6646E791C5B95B29F2C6384A570769DC888ED0B7AD510CCD3C758CEBEB648511620490E0F D54162BADB1ED05411ACC853509B62A4C1B242E1E2F737A1E7E4340F5A79B05EC3475D7BA6FC 7B3302F1258ABAC1079F11E8DFB9FC09D42716BA4054ADD460BB12FC1B0B8D5D32DB50395374 AEB3C215C2BC566328D2F03BF043068C5C9ABC649BA1767E97DF32B6AA734594EE22FFFE7FB0 6EA3B77030E79BD6FE7683AB7FFCE462ABFBA5777B3914DE4665B86C1EC203FEB6FCCB3DADB8 BA51FD87A7457C62385418E65D17809C4256E3D27DC2017D7A093C8BD193A09168F34D522DD7 D3AFB95FC61C9F4339091CF25D78BF461B4EA5620EED722AB7D3EFF99CEA4A4F546BFF6CE338 D7763AFF20A9B61452DA07179590D3316BBCE63B06B43D996D775D6843F46633FF107A3C866E 3B0A8AAAEA31F4A2048C9FCB448958287F8E961C9F3393E18FC9A05460D51A286737AEC14A1A 7B27A51 m=01D851D5148345606F586935D227CD5CF7F04F890AC5024178BA5F4EE85D7796918C3DC7A5 951C985539CB240E28BA4AC3AFBE0F6EB3151A0DBAFD686C234A30D07D590D61A5474491BF0D 68E1AC7F94CDC989C19C2E25B12511A29FFAF5F11E0B994E19C5C3DC298F9E584FFF3C7DBB8F
Re: Interesting bit of a quote
David Wagner writes: SB1386 says that if a company conducts business in Caliornia and has a system that includes personal information stored in unencrypted from and if that company discovers or is notified of a breach of the security that system, then the company must notify any California resident whose unencrypted personal information was, or is reasonably believed to have been, acquired by an unauthorized person. [*] [*] This is pretty close to an direct quote from Section 1798.82(a) of California law. See for yourself: http://info.sen.ca.gov/pub/01-02/bill/sen/sb_1351-1400/sb_1386_bill_20020926_chaptered.html Does that mean that you (the company) are safe if all of the personal information in the database is simply encrypted with the decryption key laying right there alongside the data? Alot of solutions do this, some go to different lengths in trying to obfuscate the key. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: NPR : E-Mail Encryption Rare in Everyday Use
More strongly, if we've never met, and you are not in the habit of routinely signing email, thereby tying a key to your e-persona, it makes no sense to speak of *secure* communication to *you*. Regularly signing email is not necessarily a good idea. I like to be able to repudiate most emails I send... --Anton -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 268.1.2/274 - Release Date: 03/03/2006 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: general defensive crypto coding principles
I don't believe MtE is good advice, and I have yet to see a decent reason why one would want to use that instead of EtM. Of course when we talk about EtM, the MAC should be applied over all plaintext headers and trailers (including IV used for encryption, algorithm identifier, protocol version, whatever). Allot of attacks could have been prevented with EtM, including the Vaudenay padding attack, the Chosen-Ciphertext Attacks against PGP and other email encryption protocols described by Schneier, Katz and Jallad http://www.schneier.com/paper-pgp.pdf as well as the attacks on Host Security Modules key blocks (well in this case the bad was simply that their were to integrity checks, 2 key Triple-DES keys were protected by a master triple-DES key by encrypted the left part and right part independently) and other such types as described by Clulow and others http://www.cl.cam.ac.uk/~jc407/Chap3.pdf Ferguson gave an explanation why in his book with Schneier they recommend MtE http://groups.google.ca/group/sci.crypt/msg/1a0e0165c48e4fe4?q=g:thl19936885 73ddq=hl=enlr=ie=UTF-8oe=UTF-8 But the arguments he gives pertain to other problems; see for example the comments given by Wagner which I agree with http://groups.google.ca/group/sci.crypt/msg/532fdfb5edca19a8?q=g:thl24955674 08ddq=hl=enlr=ie=UTF-8oe=UTF-8 I had come up with a list of advices for crypto implementation some time ago myself. These included (from memory) - Use good RNGs, even for things other than the generation of keys (such as for generating IVs, challenges, etc.) - Use standard algorithms, and use them in secure ways (choose a good mode of encryption, adequate key sizes, pick the IVs the way you are supposed to securely, usually either randomly or for counters make sure you have no repeats) - Use standard protocols (don't try to re-invent TLS or IPSec) - Encrypt then authenticate over ciphertext and all plaintext headers and trailers. - Use independent keys for different functionalities. If needed, derive independent keys based on a single secret using a good key derivation function. - Limit the amount of time you handle secrets (zeroize after use...) - Don't let yourself be used as a random oracle (I think Ross Anderson said it this way first), this includes limiting information that is leaked about errors, avoiding timing attacks and such (this is hard to do in practice). --Anton -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.15.1/250 - Release Date: 03/02/2006 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: another feature RNGs could provide
Actually, by definition, a cipher should be a permutation from the set of plaintexts to the set of ciphertexts. It has to be 1 to 1 bijective or it isn't an encryption algorithm. Therefore, if you want an ergodic sequence of size 2^N, a counter encrypted under an N bit block cipher will do it. Perry Yes, and the set of keys define a subset of all of the possible permutations (working on the same size input as the block cipher). The set of all permutations is a group, but a subset of that is not necessarily a subgroup. Most security proofs of modes of operations, and others, model a block cipher as a random permutation. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Fermat's primality test vs. Miller-Rabin
Ok after making that change, and a few others. Selecting only odd numbers (which acts as a small seive) I'm not getting much useful information. It appears to be such that at 512 bits if it passes once it passes 128 times, and it appears to fail on average about 120-130 times, so the sieve amplifies the values more than expected. Granted this is only a test of the generation of 128 numbers, but I got 128 primes (based on 128 MR rounds). O.k., so if I read this right, your new results concord with the analysis of Pomerance et al. That would make much more sense. When you say on average about 120-130 times the test fails, out of how many is that? --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Encryption using password-derived keys
It can be useful to derive a key encryption key from the password, and not use the key derived from the password to directly encrypt data you want to protect, when the resulting ciphertext can be found in different places where your encrypted key won't necessarly also be found. For example, to encrypt files, when the encrypted files found themselves on a backup disk, but the key is stored somewhere else (encrypted with a password based key). This can prevent someone who has access to the ciphertext from executing a brute force attack. If however your ciphertext always travers with your encrypted key, you don't gain much of an advantage (the weak point is the password-based key which can be brute forced or dictionary attacked). I don't recommend just XORing for the protection of the key. If ever your Key Derivation Function doesn't really act like a good pseudo-random function, or if you use the same password and salt to derive the same key to protect two different keys, you will be screwed. I rather recommend encrypting with something like AES, and I also recommend to compute a MAC over the ciphertext to turn it into a strong encryption, and avoid attacks such as what have been found with the HSM and the way they stored keys outside the HSM. For further details on that point, see for example section 4.3 of the following paper (follow the references given there) http://crypto.cs.mcgill.ca/~stiglic/Papers/tripleDES.pdf --Anton -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jack Lloyd Sent: November 29, 2005 11:09 AM To: cryptography@metzdowd.com Subject: Encryption using password-derived keys The basic scenario I'm looking at is encrypting some data using a password-derived key (using PBKDF2 with sane salt sizes and iteration counts). I am not sure if what I'm doing is sound practice or just pointless overengineering and wanted to get a sanity check. My inclination is to use the PBKDF2 output as a key encryption key, rather than using it to directly key the cipher (with the key used for the cipher itself being created by a good PRNG). For some reason the idea of using it directly makes me nervous, but not in a way I can articulate, leading me to suspect I'm worried over nothing. So, assuming using it as a KEK makes sense: At first I thought to use XOR to combine the two keys, but realized that could lead to related key attacks (by just flipping bits in the field containing the encrypted key). That is probably not a problem with good algorithms, but, then again, why take the chance; so I was thinking instead using NIST's AES-wrap (or perhaps a less weirdly designed variant of it that uses HMAC for integrity checking and AES in CBC mode for confidentiality). Am I thinking about this far harder than I should? -Jack - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Fermat's primality test vs. Miller-Rabin
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joseph Ashwood Sent: November 18, 2005 3:18 AM To: cryptography@metzdowd.com Subject: Re: Fermat's primality test vs. Miller-Rabin Look at table 4.3 of the Handbook of applied cryptography: for t = 1 (one iteration) and for a 500-bit candidate, we have probability p(X | Y_1) = 2^-56, which is better than what you concluded. (X representing the event that the candidate n is composite, Y_t representing the event that Miller-Rabin(n, t) declares n to be prime). The results in table 4.3 and 4.4 of HAC are for randomly (uniform) chosen candidates, and I think you need to do a basic sieving (don't remeber if that is necessary, but I think it is). The result is due to the fact that under these conditions, the strong pseudoprime test does in fact much better than 1/4 probability of error ( value of P(Y_t | X) is very low ), this result is due to Damgard, Landrock and Pomerance, based on earlier work of Erdos and Pomerance. I think much of the problem is the way the number is being applied. Giving a stream of random numbers that have passed a single round of MR you will find that very close to 50% of them are not prime, this does not mean that it passes 50% of the numbers (the 2^-80 probability given above is of this type). Do you do an initial sieving to get rid of the more obvious primes? I'm guessing you don't since you seem to have a result contradictory to what has been proven by Damgard, Landrock and Pomerance. If you look at table 4.3 of HAC (which comes from Damgard al. paper), it says that if your candidates come from a uniform random distribution, then for 500 bit candidate, the probability that a candidate n is composite when one round of miller-Rabin said it was prime is = (1/2)^56. You are finding that the probability is about 1/2, that seems very wrong (unless you are not doing the sieving, which is very important). Am I misunderstanding something? In fact it appears that integers fall on a continuum of difficulty for MR, where some numbers will always fail (easy composites), and other numbers will always pass (primes). The problem comes when trying to denote which type of probability you are discussing. Well I think I explained it pretty clearly. I can try to re-iterate. Let X represent the event that a candidate n is composite, and let Y_n denote the event that Miller-Rabin(n,t) declares n to be prime, where Miller-Rabin(n,t) means you apply t iterations of Miller-Rabin on n. Now the basic theorem that we all know is that P(Y_t | X) = (1/4)^t (this is problem in one of Koblitz basic textbooks on cryptography, for example). But this is not the probability that we are interested in, we are (at least I am) more interested in P(X | Y_t). In other words, what is the probability that n is in fact composite when Miller-Rabin(n, t) declared n to be prime? Do we agree that this is the probability that we are interested in? What are the odds that a random 512-bit composite will be detected as composite by MR in one round? I don't think anyone has dependably answered that question, but the answer is very different from 1-(probability that MR-* says it's a prime)^-k. Any discussion needs to be more accurately phrased. You are looking for P( Comp Y_t | X), where Comp Z is the complementary event of Z. In our case, Comp Y_t is the event that Miller-Rabin(n,t) proves n to be composite. Is that what you are looking for? For example, my phrasing is that in the tests that I performed 50% (+/- experimental noise) of those numbers that passed a single round of MR also passed 128 rounds, leading me to conclude that 50% of the numbers that passed a single round of MR are in fact prime. Since each number that passed a single round was subjected to 127 additional rounds, a number of additional statistics can be drawn, in particular that of those that failed at least one round none failed less than 40 rounds, and that few passed less than 40 rounds. Due to the fact that this was only iterated 65536 times there is still substantial experimental error available. These pieces of information combined indicate that for 512-bits it is necessary to have 80 rounds of MR to verify a prime. I don't understand what you are trying to point out. If you chose your candidates uniformly at random, do the sieving before applying the Miller-Rabin tests, then for 512 bit number it is sufficient to apply 5 rounds to get probability of error lower than (1/2)^80. You should take a look at Damgard al's paper, they did a very good analysis. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Fermat's primality test vs. Miller-Rabin
The general consensus is that for 500-bit numbers one needs only 6 MR
tests for 2^{-80} error probability [1]:
...
and thus a single test gives ~2^{-13}.
If you just took the exponent 80 and divided it by 6 to get ~13, I don't
think that is the right reasoning. Look at table 4.3 of the Handbook of
applied cryptography: for t = 1 (one iteration) and for a 500-bit candidate,
we have probability p(X | Y_1) = 2^-56, which is better than what you
concluded. (X representing the event that the candidate n is composite, Y_t
representing the event that Miller-Rabin(n, t) declares n to be prime).
The results in table 4.3 and 4.4 of HAC are for randomly (uniform) chosen
candidates, and I think you need to do a basic sieving (don't remeber if
that is necessary, but I think it is). The result is due to the fact that
under these conditions, the strong pseudoprime test does in fact much better
than 1/4 probability of error ( value of P(Y_t | X) is very low ), this
result is due to Damgard, Landrock and Pomerance, based on earlier work of
Erdos and Pomerance.
--Anton
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fermat's primality test vs. Miller-Rabin
I guess the small increase in efficiency would not be worth additional
program code.
That depends on the size of the numbers you're working with...
Considering the research that goes into fast implementations of
PowerMod I don't think the required computation is trivial.
Although the Carmichael numbers fool the Fermat test
(that is, $a^{n-1} = 1 (n)$) for *all* a, there are no such things for
the Miller-Rabin test: for any odd composite n at least 3/4 of a's
fail the test, that is if you made m MR tests with random a's then you
are mistaken with probability at most (1/4)^m.
That is true but is not the result of a direct conclusion. Let X
represent the event that n is composite, and Y_t the event that
MILLER-RABIN(n,t) declares n to be prime. Because for a composite n there
is at least 3/4 of a's that fail the test, we can conclude that Pr(Y_t |
X) = (1/4)^t.
But the probability I think you are referring to (the one that is usually
considered the most interesting) is P(X | Y_t). It happens to be the case
that P(X | Y_t) is in fact = (1/4)^t when using uniform random
candidates, but to come to that conclusion you need to consider the fact
that the error probability of Miller-Rabin is usually far smaller than
(1/4)^t (and apply Bayes theorem and a theorem on the distribution of
prime numbers). See Note 4.47 in the Handbook of applied cryptography, or
the following paper:
http://www.cs.mcgill.ca/~crepeau/PS/BBC+87.ps
--Anton
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fermat's primality test vs. Miller-Rabin
Although the Carmichael numbers fool the Fermat test
(that is, $a^{n-1} = 1 (n)$) for *all* a, there are no such things for
the Miller-Rabin test: for any odd composite n at least 3/4 of a's
fail the test, that is if you made m MR tests with random a's then you
are mistaken with probability at most (1/4)^m.
Yes I guess the difference is that with MR you are trying to find a
number that is *likely* a prime, whereas with Fermat you are testing
primality. But MR will still fail when given a Carmichael number,
since elsewhere MR is defined as iterated application of the Fermat
test [1].
That is not true, in several counts.
Firstly Miller-Rabin probabilistic primality test doesn't generate a
number, it verifies a number for primality.
Secondly, the Miller-Rabin probabilistic primality test is not based on
Fermat's Little theorem, or so called pseudoprime test, but rather on the
strong pseudoprime test, which derives from a theorem that says that if n
is an odd prime, n-1 = 2^s * r with r odd, then for any a such that
gcd(a,n) = 1 either a^r == 1 (mod n) or a^(r*2^j) == -1 (mod n) for some
j, 0 = j = s-1. See Handbook of a applied cryptography fact 4.20.
I'm affraid the reference you gave is incorrect.
--Anton
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: SSL/TLS passive sniffing
This sounds very confused. Certs are public. How would knowing a copy of the server cert help me to decrypt SSL traffic that I have intercepted? I found allot of people mistakenly use the term certificate to mean something like a pkcs12 file containing public key certificate and private key. Maybe if comes from crypto software sales people that oversimplify or don't really understand the technology. I don't know, but it's a rant I have. Now if I had a copy of the server's private key, that would help, but such private keys are supposed to be closely held. Or are you perhaps talking about some kind of active man-in-the-middle attack, perhaps exploiting DNS spoofing? It doesn't sound like it, since you mentioned passive sniffing. I guess the threat would be something like an adversary getting access to a web server, getting a hold of the private key (which in most cases is just stored in a file, allot of servers need to be bootable without intervention as well so there is a password somewhere in the clear that allows one to unlock the private key), and then using it from a distance, say on a router near the server where the adversary can sniff the connections. A malicious ISP admin could pull off something like that, law authority that wants to read your messages, etc. Is that a threat worth mentioning? Well, it might be. In any case, forward-secrecy is what can protect us here. Half-certified (or fully certified) ephemeral Diffie-Hellman provides us with that property. Of course, if someone could get the private signature key, he could then do a man-in-the-middle attack and decrypt all messages as well. It wouldn't really be that harder to pull off. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Maths holy grail could bring disaster for internet
Mathematicians could be on the verge of solving two separate million dollar problems. If they are right - still a big if - and somebody really has cracked the so-called Riemann hypothesis, financial disaster might follow. Suddenly all cryptic codes could be breakable. No internet transaction would be safe. Looks like they are saying that if one can disprove the Riemann hypothesis, then one could break (presumably) public key crypto, (presumably) by factoring or computing DL. But I am not aware of any factoring or DL algorithm that can be drastically sped up if Riemann hypothesis is proven to be false? Here the author quotes the mathematician: The whole of e-commerce depends on prime numbers. I have described the primes as atoms: what mathematicians are missing is a kind of mathematical prime spectrometer. Chemists have a machine that, if you give it a molecule, will tell you the atoms that it is built from. Mathematicians haven't invented a mathematical version of this. That is what we are after. If the Riemann hypothesis is true, it won't produce a prime number spectrometer. But the proof should give us more understanding of how the primes work, and therefore the proof might be translated into something * that might produce this prime spectrometer. If it does, it will bring the * whole of e-commerce to its knees, overnight. So there are very big implications. This wording, with the word *might*, is more accurate, and not at all equivalent to the assertion the author makes at the beginning. Another bad article. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Microsoft .NET PRNG (fwd)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gerck Sent: 10 août 2004 13:42 To: [EMAIL PROTECTED] Subject: Re: Microsoft .NET PRNG (fwd) The PRNG should be the least concern when using MSFT's cryptographic provider. The MSFT report 140sp238.pdf says: RSAENH stores keys in the file system, but relies upon Microsoft Windows XP for the encryption of the keys prior to storage. Yes that's true. The security policy explains that the safeguarding of private keys is done outside the crypto boundary. (as someone mentioned to me in personal email you need to have a look at the fine print of such accreditations, this is an example of a fine print). Note however that the OS uses the crypto provider to encrypt the private key using a secret that is generated based on (or protected by a key generated based on, don't remember off the top of my head) the user's password. The strength of the system is based on the user's Windows password, which I think is reasonable (anyone who can login as the user can use his private keys, stored in his container, anyways)... --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Microsoft .NET PRNG (fwd)
There is some detail in the FIPS 140 security policy of Microsoft's cryptographic provider, for Windows XP and Windows 2000. See for example http://csrc.nist.gov/cryptval/140-1/140sp/140sp238.pdf where they say the RNG is based on FIPS 186 RNG using SHS. The seed is based on the collection of allot of data, enumerated in the security policy. I would guess that what is written is true, less NIST would look very bad if someone reversed engineered the code and showed that what they certified was wrong. So based on that it would seem that the PRNG in recent Microsoft cryptographic providers is o.k. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: dual-use digital signature vulnerability
About using a signature key to only sign contents presented in a meaningful way that the user supposedly read, and not random challenges: The X.509 PoP (proof-of-possession) doesn't help things out, since a public key certificate is given to a user by the CA only after the user has demonstrated to the CA possession of the corresponding private key by signing a challenge. I suspect most implementation use a random challenge. For things to be clean, the challenge would need to be a content that is readable, and that is clearly only used for proving possession of the private key in order to obtain the corresponding public key certificate. X.509 PoP gets even more twisted when you want to certify encryption keys (I don't know what ietf-pkix finally decided upon for this..., best solution seems to be to encrypt the public key certificate and send that to the user, so the private key is only ever used to decrypt messages...) --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Verifying Anonymity
[...] I find it hard to imagine how you can even know whether it seems to work, let alone has some subtle problem. That's clearly a much harder problem--and indeed I suspect it's behind the general lack of interest that the public has shown in anonymous systems. -Ekr The lack of understanding of how a solution works applies to most security products and in general to all computer products. Most people don't have a clue how an SSL encrypted session really protects your credit card number in transit, but allot of people are starting to realize that they should use it (they understand to some extent the problem SSL attempts to solve). With anonymity systems, I don't think understanding how a solution works is a problem to its wide-spread use, the problem is more that of understanding the *problem the solution attempts to solve*. People still don't understand the consequences of privacy invasion on the Internet (the problem). Once they do, they will be willing to pay for a solution from any trusted company, without needing to understand how the solution actually works. IMHO... --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: New Attack on Secure Browsing
You stated that http://www.pgp.com is an SSL-protected page, but did you mean https://www.pgp.com? On my Powerbook, with all the browsers I get an error that the certificate is wrong and they end up at http://www.pgp.com. What I get is a bad certificate, and this is due to the fact that the certificate is issued to store.pgp.com and not www.pgp.com. Interestingly (maybe?), when you go and browse on their on-line store, and check something out to buy, the session is secured but with another certificate, one issued to secure.pgpstore.com. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: 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 article says The weaknesses of SSL implementations have been well known amongst security professionals, but their argument has been that SSL is the best tool currently on offer. The fact that it can be spoofed and is open to man in the middle attacks is played down. O.k., so if there is a vulnerability in a particular implementation there might be a possible MITM attack. Also possible to do MITM if user doesn't do proper verification. But I wouldn't say that SSL implementations in general are suspect to MITM attacks. Later in the article it is written: What we can be certain of is that it is not possible to have a man-in-the-middle attack with FormsAssurity - encryption ensures that the form has really come from the claimed web site, the form has not been altered, and the only person that can read the information filled in on the form is the authorized site. O.k., so how do they achieve such assurances? Eric's comment about condoms being effective is right, so bad analogy as well! --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: identification + Re: authentication and authorization
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gerck Sent: 7 juillet 2004 14:46 To: [EMAIL PROTECTED] Subject: identification + Re: authentication and authorization I believe that a significant part of the problems discussed here is that the three concepts named in the subject line are not well-defined. This is not a question of semantics, it's a question of logical conditions that are at present overlapping and inconsistent. For example, much of what is called identity theft is actually authentication theft -- the stolen credentials (SSN, driver's license number, address, etc) are used to falsely *authenticate* a fraudster (much like a stolen password), not to identify. Yes and no. The problem is that most authentication and authorisation schemes today are actually identification and authentication and authorisation schemes. Even when you read CISSP study guides, they always describe it in 3 steps, identification, authentication and authorisation. The thing is that we can do without identification. Identification is not necessary, even if you want accountability. In Identification-authentication-authorisation schemes, identification is the process of pin-pointing an exact individual from a set of individuals (e.g. SSN allows you to define a unique united-states citizen), authentication is the process of verifying that the individual claiming to be who he identified himself as, is really that individual. But most systems don't really need identification, all they need is a proof that the individual possesses a certain attribute. It is possible to do authentication and authorisation, without doing the identification part! For example, it is possible to prove that you are a united-states citizen that has a valid SSN number, without actually giving out information about SSN. Why is identity theft a bad thing? Usually, you don't want your identity to be stolen because you could be accused of something due to accountability that is associated with your identity. The problem is not that someone can authenticate himself to a system he is not suppose to have access to, the problem is that a thief can identify himself as you and authenticate himself as you, and than do bad things (like transfer your money). The problem is not really authentication theft, its identity theft, or if you want to put it even more precisely, it's identity theft and authenticating as the individual to whom the identity belongs to. But the latte doesn't make for a good buz-word :) Here is another way of seeing it. Consider a system where you need to authenticate yourself as a citizen, of some region, that is 18 years of age or older, in order to participate in some gambling thing say. One way to implement the authentication and authorisation in the system is to have each individual identify themselves, and then authenticate themselves. If the individual is part of a set of individuals that are known to be over 18, then the individual is given access. Another way to implement it is to have each individual prove that they are over 18 without identifying themselves, using Stefan Brands digital credentials say. If the authentication is successful, the un-identified individual is given access. In the latter case, you don't really care about authentication theft unless there is some sort of accountability (with Stefan's digital credentials, you can embed the identity in the tokens that are presented for authentication, the identity can only be revealed under certain circumstances, for example excessive use or if require by a law, it could be revealed by a third party). I do agree that stronger authentication does help, preferably authentication based on zero-knowledge protocols, since these reveal less information about the individual's identity that can be used to impersonate the individual. --Anton Once we understand this, a solution, thus, to what is called identity theft is to improve the *authentication mechanisms*, for example by using two-factor authentication. Which has nothing to do with identification, impersonation, or even the security of identification data. In further clarifying the issue, it seems that what we need first is a non-circular definition for identity. And, of course, we need a definition that can be applied on the Internet. Another important goal is to permit a safe automatic processing of identification, authentication and authorization [1]. Let me share with you my conclusion on this, in revisiting the concept of identification some time ago. I found it useful to ask the meta question -- what is identification, that we can identify it? In short, a useful definition of identification should also work reflexively and self-consistently [2]. In this context, what is to identify? I think that to identify is to look for connections. Thus, in identification we should look for logical and/or natural connections. For example: - between a
RE: authentication and authorization (was: Question on the state of the security industry)
However, in some scenarios http://www.garlic.com/~lynn/2001h.html#61 the common use of static data is so pervasive that an individual's information is found at thousands of institutions. The value of the information to the criminal is that the same information can be used to perpetrate fraud across all institutions and so the criminal value is enormous. However the value to each individual institution may be minimal. As a result there can be situations where an individual institution hasn't the infrastructure or the funding to provide the countermeasures necessary to keep the criminals away from the information (they simply don't have the resources to provide security proportional to the risk). The value of the static data authentication information to a criminal is far greater than the value of the information to the institution ... or the cost to the criminal to acquire the information is possibly orders of magnitude less than the value of the information (for criminal purposes). Agreed. This is where federated identity management becomes a tricky problem to solve. It is important to get something like the Liberty Alliance right. A solution that I like can be found here (there is also a ppt presentation that can be found on the site): http://middleware.internet2.edu/pki04/proceedings/cross_domain_identity.pdf Given such a situation the infrastructures simply don't have the resources to provide the countermeasures adequate to meet the attacks they are going to experience (there is such a huge mismatch between the value of the information to the individual institutions and the value of the information to the criminal). Which results in my assertion that there has to be a drastic move away from the existing static data authentication paradigm because there is such a mismatch between the value to secure the information verses the value of attacks to obtain the information. It isn't that theory can't provide mechanisms to protect the information it that the information is spread far and wide and is in constant use by thousands of business processes, and that protection problem is analogous to the problem of having people memorize a hundred different 8+character passwords that change every month (which is also a shortcoming of the static data authenticaton paradigm). Yes, theory is far more advanced than what is used in practice. With Zeroknowledge proofs and attribute authentication, based on secrets stored on smart cards held by the proper owners, and possibility to delegate part of the computation to a server (so clients can authenticate on low powered devices), without revealing information about the secret, etc... I agree that what you call static data authentication paradigm is the cause of many problems, including identity theft. It is one reason why Identity Management is a hot topic these days; businesses are loosing control of all these static data associated to the various systems they have, and when an employee leaves a company he often has an active account on some system even months after his departure. This is the de-provisioning problem. Not to sure about the wording however, if you take a zeroknowledge Proof to authenticate possession of an attribute, prover will hold some static data (some sort of secret), the only difference is that the verifier doesn't need to know the secret, and in fact you can't learn anything from looking at the communication link when the proof is executed. You can't learn anything either by modifying the protocol from the verifier's point (malicious verifier). But if you can steal the secret that the prover possesses, than you can impersonate her. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: authentication and authorization (was: Question on the state of the security industry)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Denker Sent: 1 juillet 2004 14:27 To: [EMAIL PROTECTED] Cc: Ian Grigg Subject: Re: authentication and authorization (was: Question on the state of the security industry) 1) For starters, identity theft is a misnomer. My identity is my identity, and cannot be stolen. The current epidemic involves something else, namely theft of an authenticator ... Identity has many meanings. In a typical dictionary you will find several definitions for the word identity. When we are talking about information systems, we usually talk about a digital identity, which has other meanings as well. If you are in the field of psychology, philosophy, or computer science, identity won't mean the same thing. One definition that relates to computer science that I like is the following: the individual characteristics by which a thing or person is recognized or known. A digital identity is usually composed of a set of identifiers (e.g. Unix ID, email address, X.500 DN, etc.) and other information associated to an entity (an entity can be an individual, computer machine, service, etc.). Other information may include usage profiles, employee profiles, security profiles, cryptographic keys, passwords, etc. Identity can be stolen in the sense that this information can be copied, revealed to someone, and that someone can use it in order to identify and authenticate himself to a system and get authorization to access resources he wouldn't normally be allowed to. The following document has a nice diagram on the first page of appendix A: http://www.ec3.org/Downloads/2002/id_management.pdf I came up with a similar diagram for a presentation I recently gave, but instead of talking about primary and secondary identifying documents I mention primary and secondary identifying information in general, and I also have an identifiers circle situated beside the bigger circle, containing identifiers that belong to an entity but are not linkable to the entity (talking about nyms and pseudonyms). Recall that there are basically 3 types of authentication: individual authentication (such as via biometrics, where you use primary identifying information to authenticate someone), identity authentication (where the identity may or may not be linkable to an individual), and attribute authentication (where you need reveal nothing more than the possession of a certain attribute, such as can be done with Stefan Brands digital credentials). --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: authentication and authorization
-Original Message- From: John Denker [mailto:[EMAIL PROTECTED] Sent: 5 juillet 2004 18:28 To: Anton Stiglic Cc: [EMAIL PROTECTED]; 'Ian Grigg' Subject: Re: authentication and authorization [...] We should assume that the participants on this list have a goodly amount of technical expertise. We should use the established technical definitions, unless there is a good reason not to. Well, there is nt established technical definition for digital identity, but most definitions seem to focus to what I defined it as. [...] A digital identity is usually composed of a set of identifiers (e.g. Unix ID, email address, X.500 DN, etc.) and other information associated to an entity (an entity can be an individual, computer machine, service, etc.). Other information may include usage profiles, employee profiles, security profiles, cryptographic keys, passwords, etc. That is very unhelpful, because it lumps together two types of things that really ought to be treated differently. -- I want my email address to be widely known. I want my public keys to be widely known. -- I want my password to be secret. I want my private keys to be secret. The term digital identity is not intended to help you solve the problem. In a digital identity there are parts that an individual wants to keep private, other parts can be public (others should be divulged to only certain individuals, possibly via a zero-knowledge proof that will convince the verifier, without giving him enough information to be able to prove the property to someone else). You can refer to the different parts of a digital identity using different terms if you want, but the term digital identity usually includes all of those parts. Relating to the real world, you might have a fetish for high-healed pink leather boots, which is part of your identity (something that characterizes you), but not want others to know about that. But its still part of your identity, just as your SSN number is. Identity can be stolen in the sense that this information can be copied, revealed to someone, and that someone can use it in order to identify and authenticate himself to a system and get authorization to access resources he wouldn't normally be allowed to. The following document has a nice diagram on the first page of appendix A: http://www.ec3.org/Downloads/2002/id_management.pdf Again that (including the reference) misses the point and blurs things that really need to be kept distinct. You are mixing up two problems, that of defining digital identity, and that of preventing unauthorized individuals to access resources that they are not supposed to (via identity theft for example), as well as privacy. The focus _must_ be on the transaction, not on the ID. Suppose I carry out a transaction with the jewellery store. Did I authorize a $3.00 payment for a new watch battery, or a $30,000.00 payment for diamond necklace? You are talking about the problem of non-repudiation here... [...] Collecting more and more ID information about me is at best marginally helpful to the relying party; ID might tell the RP whether I *could* have authorized a particular transaction (was it within my account limit?) but ID cannot possibly tell the RP whether I *did* authorize a particular transaction. And (!!) don't forget the converse: If the transaction is legit, there is no reason why my ID needs to be involved. Cash transactions are still legal! I agree with that last part. It relates to the whole thing about attribute, vs identity vs individual authentication that I mentioned. I favour attribute authentication in most cases. And with stuff like Digital Credentials you can also have accountability even with attribute authentication (for example if forced by law). The proper use of _identification_ is obvious: In some exceptional circumstances it is important to be able to connect a real meat-space _identity_ with a particular event. For instance, if there is a hit-and-run accident, it really helps if a witness notes the license number of the car. (Been there, done that.) Again, this relates exactly to my discussion about attribute, identity and individual authentication. Things like Digital Credentials is what is going to help you out, not re-defining the term digital identity. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: recommendations/evaluations of free / low-cost crypto libraries
-Original Message- From: [EMAIL PROTECTED] [mailto:owner-[EMAIL PROTECTED] On Behalf Of Peter Gutmann Sent: 29 juin 2004 09:49 To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: recommendations/evaluations of free / low-cost crypto libraries Anton Stiglic [EMAIL PROTECTED] writes: A list can be found here http://www.homeport.org/~adam/crypto/ Hmm, that list is somewhat out of date (several years in some cases). Indeed. Adam started that list in 1996, but I don't think he put allot of time updating it in recent years. Still, I think it's a good list for someone who is starting to look for crypto libraries. It would be nice gift to the community if someone came up with a similar, updated list. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL accel cards
Does anyone know of an SSL acceleration card that actually works under Linux/*BSD? I successfully used a Broadcom PCI card on a Linux (don't remember what Linux and kernel version, this was close to 2 years ago). If I remember correctly it was the BCM5820 processor I used http://www.broadcom.com/collateral/pb/5820-PB04-R.pdf (the product sheet mentions support for Linux, Win98, Win2000, FreeBSD, VxWorks, Solaris). I was able to use it on a Linux and on a Windows (where I offloaded modexp operation from MSCAPI crypto provider). The Linux drivers where available from Broadcom upon request, there was also a crypto library that called the card via the drivers, but at the time I looked at it the code wasn't very stable (e.g. I had to debug the RSA key generation and send patches since it did not work at all, later versions had the key generation part working properly). The library might be stable by now. I also made the Broadcom chip work with OpenCryptoki on a Linux, I submitted the code for supporting Broadcom in OpenCryptoki. http://www-124.ibm.com/developerworks/oss/cvs/opencryptoki/ [] and certainly they don't (gasp) make updated versions available for download. Because someone might... what, steal the driver? Anyway... [] No, but they might find out how poorly written they are??? Don't know the reason... --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is there a Brands certificate reference implementation?
Stefan Brands started his own company, http://www.credentica.com/ There isn't much on the web site yet, but if you click on the image you get the info email address. The code that was developed for Brands credentials at ZKS was never released. There was also code written during the ESPRIT project called CAFE. A description of protocols for Brands credentials can be found here http://crypto.cs.mcgill.ca/~stiglic/Papers/brands.pdf A more elaborate reference is the technical paper that can be found here http://www.credentica.com/technology/technology.html --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Mac_crypto] Apple should use SHA! (or stronger) to authenticate software releases
The attacks by Dobbertin on MD5 only allow to find collisions in the compression function, not the whole MD5 hash. But it is a sign that something might be fishy about MD5. MD5 output is 128 bits. There are two types of collision finding attacks that can be applied. In the first you are given a hash value y = H(x), for some x, and try to find a different input x' that hashes to the same output: H(x) = H(x') = y. This relates to 2nd-preimage resistance. This can be done on MD5 in 2^128 work factor. The other attack is to find to arbitrary inputs x, x' such that H(x) = H(x'). This relates to collision resistance. This can be done with good probability in 2^64 work factor. Now, the problem of having a malicious source code hash to the same value as good/valid source code seems to be related more to the former, that is you have some code that is checked-in, that gives some hash value Y, and you want to find a different code (malicious one) that hashes to the same value. You might be able to play with the valid code as well, giving you more flexibility for the search of a collision, but you can't play to much without having this noticed by other developers. I think that there are many other problems that are more of concern. For example hacking a web site (or mirror site) that contains code for download, and changing the code along with the hash value of the code, or preventing a developer from inserting some kind of trap door or Trojan. But if you are given the choice between using MD5 and SHA1, I'd prefer SHA1, but I wouldn't be concerned with someone using MD5 isntead of SHA1 for the time being. In other words, if I were to do a risk analysis, I would identify the use of MD5 instead of SHA1 as one of the major risks. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
- Original Message - From: Jerrold Leichter [EMAIL PROTECTED] Cc: Cryptography [EMAIL PROTECTED] Sent: Wednesday, January 07, 2004 7:14 AM Subject: Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)] Now that we've trashed non-repudiation ... just how is it different from authentication? I don't think the word authentication has the same problem as non-repudiation, but you do need to be careful how you define it. So here we are talking about entity authentication (as opposed to data authentication, the latter really has a unambiguous definition, at least I hope it does!). The way you should define entity authentication is by stating that it is a process of verifying that an entity possesses the authentication credentials associated to a user that entity claims to be. This entity might be the rightful user, or it might be someone who stole the credentials from the rightful user. If someone stole my ATM card and my PIN, he/she can successfully authenticate him/herself to an ATM and withdraw money. The word authenticate is appropriate in this last phrase. But I see that most definitions that have been collected here: http://www.garlic.com/~lynn/secgloss.htm#t523 are not careful about this. The thing about non-repudiation is that it is something that even most laws do not permit. See for example: http://www.firstmonday.dk/issues/issue5_8/mccullagh/ Non-repudiation applied to digital signatures implies that the definition states that only one person possibly had possession of the private signing key and was conscious about the fact that it was used to sign something. In most jurisdictions a person has the right to repudiate a signature (had-written or electronic), and thus non-repudiation does not work. People have the right to repudiate signatures since it might be the result of a forgery, fraud, the signer might have been drunk or something at the time of signing or forced to sign (like with a gun to his head).Repudiation is possible but non-repudiation is not. I know some people who use the term accountability instead of non-repudiation to express the property needed in certain systems (commercial infrastructures where users login and need to be accountable for their acts). This seems like a better term to be used in certain contexts, but I'm still thinking about it... --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CIA - the cryptographer's intelligent aid?
The thing about CIA is that it is commonly used in security (not cryptography) courses to mean Confidentiality, Integrity (of systems) and Availability (instead of Authentication). Availability of systems, services and information. For crypto I always talked about CAIN or PAIN (like in no PAIN no gain, or cryptography is allot of PAIN). -- note, I also prefer the word Confidentiality over Privacy, the latter being to high level and I usually reserve it to mean the hiding of who is communicating with who (anonymity systems...). When introducing digital signatures I always state that they provide integrity (as do MACs, which I introduce beforehand) but also the possibility of non-repudiation. And then I go on stating that it is very hard, if not impossible, to in fact implement non-repudiation. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Any good books or URLs for WinXP crypto security?
NSA Windows hardening guides: http://nsa2.www.conxion.com/ --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Zero Knowledge Authentication? (was Cryptolog Unicity Software-Only Digital Certificates)
Previously used primarily in scientific/academic applications, zero knowledge authentication is a method of proving a user's identity without revealing his password to the verifier. So anybody knows exactly what this zero-knowledge authentication is that they use? Using this technology, Unicity allows companies to issue digital certificates securely on a software-only basis, eliminating the need to supply employees, partners and clients with special hardware, or to require them to locally store certificates on their computers. The private data is never stored on the user's hard drive, and is erased from the RAM as soon as the user no longer needs it. This part about storing private keys on a server is not novel. The company that I work for has a similar solution with respect to this, it's called HotSign: http://www.okiok.com/index.jsp?page=Hot+Sign --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: yahoo to use public key technology for anti-spam
- Original Message - From: Carl Ellison [EMAIL PROTECTED] To: 'Will Rodger' [EMAIL PROTECTED]; 'Steve Bellovin' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, December 07, 2003 8:44 AM Subject: RE: yahoo to use public key technology for anti-spam I, for one, hate the idea. My From address should be [EMAIL PROTECTED] That's my remailer where I receive all my incoming e-mail. However, my outgoing SMTP server depends on which cable modem provider or hot spot I happen to be at the moment. It would be that SMTP machine that signs my outgoing mail, not acm.org who never sees my outgoing mail. But you should be sending mails via *your* SMTP server, and should be connecting to that SMTP server using SSL and authentication. Open relays encourage spam. People shouldn't be relaying mail via just any SMTP server. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Problems with GPG El Gamal signing keys?
- Original Message - From: Ralf Senderek [EMAIL PROTECTED] To: Werner Koch [EMAIL PROTECTED]; cryptography [EMAIL PROTECTED] Sent: Thursday, November 27, 2003 11:23 AM Subject: Re: Problems with GPG El Gamal signing keys? On Thu, 27 Nov 2003, Werner Koch wrote: Yes, yes, I should have removed ElGamal signing key support back in 1998 when there was no more need for it. I recall that some folks begged me not to do that and I took the wrong decision. I think no-one will blame you for this, you couldn't have known the effects. But what are we going to learn? Heading for far less complexity is the future! Maybe we can learn that code re-use is tricky in cryptography: indeed, if the signing function and encryption function did not use the same gen_k function, the author of the code would have done the optimization that causes the vulnerability in the signing function because this has never been recommended (while for encryption it is a well known recommendation). Maybe we can learn that using the same key for two different things is really really not a good idea! If the vulnerability was restricted to signatures it would have been less severe, being able to decrypt all confidential messages that were created in the past is much more severe. Allot of applications use one single key for both signing and encryption, while this doesn't seem to be immediately dangerous I don't think it's a good idea. For example when I receive an email from someone that is signed, Outlook will save the public signature key that comes with the message and use it to encrypt if I decide to send an encrypted message to that person. I never understood why having separate keys for signing and encrypting was so complicated to implement?Also in the PoP protocol of X.509, a signature using the private key is used to prove possession of the private key corresponding to a public encryption key. While the different padding used in signature and encryption schemes make it difficult to find an obvious vulnerability with this, I don't think it's a good idea. You have to be very careful when using the same key pair for encrypting and signing. The subtle error found in GnuPG about using small k is a good example. Another thing to consider is that ElGamal encryption with base g = 2 is safe but insecure for signatures... It's just simpler to have two distinct pairs of keys. By the way, is the paper by Phong Q. Nguyen describing the vulnerability available somewhere? Or maybe someone could describe the cryptanalysis steps to retrieving the private key from the signature when using smaller random k, I would appreciate. ElGamal with smaller k looks allot like DSA, exept in DSA you work with a generator of a smaller subgroup and your k is chosen in this smaller subgroup... Thanks. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Problems with GPG El Gamal signing keys?
- Original Message - From: Perry E.Metzger [EMAIL PROTECTED] Some notes have been floating around claiming that there are bugs in GPG's use of El Gamal keys. For example, see: http://groups.google.com/groups?selm=E1AOvTM-0001nY-00%40alberti.g10code.deoe=UTF-8output=gplain Can anyone confirm these reports? The note talks about GPG Elgamal encryption and signature schemes using small value of k (where k is the random value that you pick for each signature, each encryption). For encryption choosing a small k is o.k. (by small I mean something like 160 bits when you have a 1024 bit prime), but this was never recommended for the signature scheme, and the note states that this would in fact be a security vulnerability. The note says that with one signature using a certain private key x, generated using a small random k, you can compute the private key x. So if you are also using this key for decryption, the private key found could also be used to decrypt everything that was encrypted to you. I haven't put any taught yet in how you would retrieve the private key given the signature (I just read this email), but it sounds plausible. One thing I can confirm however is that GnuPG 1.2.3 (the latest version available from the GnuPG we site) indeed has is that both the encryption and signature schemes use a small k. If you have the source code, just take a look at cipher/elgamal.c, there is a function gen_k( MPI p ) that is called by both do_encrypt(...) and sign(...) functions. In the function gen_k, k is chosen to be of size nbits, where nbits is smaller than the size of the prime. Look at the comment in the code: /* IMO using a k much lesser than p is sufficient and it greatly * improves the encryption performance. We use Wiener's table * and add a large safety margin. */ nbits = wiener_map( orig_nbits ) * 3 / 2; wiener_map maps sizes of primes to sizes for k and q. For example, for a 1024 bit prime, the function will return 165, so in this case nbits would be 165*3/2 = 247. I give credit to Phong Nguyen which the note says was the person who observed this and came up with the attack. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A-B-a-b encryption
- Original Message - From: Jeremiah Rogers [EMAIL PROTECTED] To: crypto list [EMAIL PROTECTED] Sent: Sunday, November 16, 2003 12:50 PM Subject: Re: A-B-a-b encryption This is Shamir's Three-Pass Protocol, described in section 22.3 of Schneier. It requires a commutative cryptosystem. - Jeremiah Rogers Also described in HAC, protocol 12.22. It's like basic DH, except it provides key transport instead of key agreement. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Are there...one-way encryption algorithms
David Wagner [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] martin f krafft wrote: it came up lately in a discussion, and I couldn't put a name to it: a means to use symmetric crypto without exchanging keys: - Alice encrypts M with key A and sends it to Bob - Bob encrypts A(M) with key B and sends it to Alice - Alice decrypts B(A(M)) with key A, leaving B(M), sends it to Bob - Bob decrypts B(M) with key B leaving him with M. Are there algorithms for this already? What's the scheme called? It's called Pollig-Hellman. If I'm not mistaken you are wrong. Pohlig-Hellman proposed an encryption scheme based on discret log, the description of the OP was for a key transport protocol. In Pohlig-Hellman, what you do is have Alice and Bob share secret keys k and d such that k*d == 1 mod (p-1), where p is some prime. To encrypt a message M Alice computes M^k mod p, and Bob can decrypt by computing (M^k)^d mod p == M mod p. This is commonly referred to as the Pohlig-Hellman symmetric-key exponentiation cipher. It is described in patent 4,424,414 which you can find here http://patft.uspto.gov/netahtml/search-bool.html Also mentioned in HAC, chapter 15, section 15.2.3, (iii). The algorithm that was described by the OP is really Shamir's three-pass algorithm, also known as Shamir's no-key protocol. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL, client certs, and MITM (was WYTM?)
- Original Message - From: Tom Otvos [EMAIL PROTECTED] As far as I can glean, the general consensus in WYTM is that MITM attacks are very low (read: inconsequential) probability. I'm not certain this was the consensus. We should look at the scenarios in which this is possible, and the tools that are available to accomplish the attack. I would say that the attack is more easily done inside a local network (outside the network you have to get control of the ISP or some node, and this is more for the elite). But statistics show that most exploits are accomplished because of employees within a company (either because they are not aware of basic security principals, or because the malicious person was an employee within), so I find this scenario (attack from inside the network) to be plausible. Take for an example a large corporation of 100 or more employees, there has got to be a couple of people that do on-line purchasing from work, on-line banking, etc... I would say that it is possible that an employee (just curious, or really malicious) would want to intercept these communications So how difficult is it to launch an MITM attack on https? Very simple it seems. My hacker friends pointed out to me two softwares, ettercap and Cain: http://ettercap.sourceforge.net/ http://www.oxid.it/cain.html Cain is the newest I think, and remarkably simple to use. It has a very nice GUI and it doesn't take much hacking ability to use it. I've been using it recently for educational purposes and find it very easy to use, and I don't consider myself a hacker. Cain allows you to do MITM (in HTTPS, DNS and SSHv1) on a local network. It can generate certificates in real time with the same common name as the original. The only thing is that the certificate will probably not be signed by a trusted CA, but most users are not security aware and will just continue despite the warning. So given this information, I think MITM threats are real. Are these attacks being done in practice? I don't know, but I don't think they would easily be reported if they were, so you can guess what my conclusion is... --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL, client certs, and MITM (was WYTM?)
I'm not sure how you come to that conclusion. Simply use TLS with self-signed certs. Save the cost of the cert, and save the cost of the re-evaluation. If we could do that on a widespread basis, then it would be worth going to the next step, which is caching the self-signed certs, and we'd get our MITM protection back! Albeit with a bootstrap weakness, but at real zero cost. I know of some environments where this is done. For example to protect the connection to a corporate mail server, so that employees can read their mail from outside of work. The caching problem is easily solved in this case by having the administrator distribute the self-signed cert to all employees and having them import it and trust it. This costs no more than 1 man day per year. This is near 0 cost however, and gives some weight to Perry's argument. Any merchant who wants more, well, there *will* be ten offers in his mailbox to upgrade the self-signed cert to a better one. Vendors of certs may not be the smartest cookies in the jar, but they aren't so dumb that they'll miss the financial benefit of self- signed certs once it's been explained to them. I have a hard time believing that a merchant (who plans to make $ by providing the possibility to purchase on-line) cannot spend something like 1000$ [1] a year for an SSL certificate, and that the administrator is not capable of properly installing it within 1-2 man days. If he can't install it, just get a consultant to do it, you can probably get one that does it within a day and charges no more than 1000$. So that would make the total around 2000$ a year, let's generously round it up to 10K$ annum. I think your 10-100 million $ annum estimate is a bit exaggerated... [1] this is the price I saw at Verisign http://www.verisign.com/products/site/commerce/index.html I'm sure you can get it for cheaper. This was already discussed on this list I think... --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Internal format of RSA private keys in microsoft keystore.
- Original Message - From: R.Sriram [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 10, 2003 1:20 AM Subject: Internal format of RSA private keys in microsoft keystore. Greetings, In the process of trying to work around some of the limitations of the m$-CAPI API, I'm trying to decipher the internal representation of private keys in the default m$ key store, in order to extract the private key out. If you could acquire a context, you could export the private key into a blob and then read it from that, but you can't acquire a context. As Tom mentioned, the keys are encrypted in the container. The FIPS 140 security policies for M$'s CSPs say that the task of protecting the keys in the system is delegated to Data Protection API (DPAPI). There is a brief explanation in the security policies, see for example http://csrc.nist.gov/cryptval/140-1/140sp/140sp241.pdf section Key Storage. You might be able to find more detailed information somewhere else... Good luck! --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NCipher Takes Hardware Security To Network Level
- Original Message - From: Peter Gutmann [EMAIL PROTECTED] [...] The problem is that what we really need to be able to evaluate is how committed a vendor is to creating a truly secure product. [...] I agree 100% with what you said. Your 3 group classification seems accurate. But the problem is how can people who know nothing about security evaluate which vendor is most committed to security? For the moment, FIPS 140 and CC type certifications seem to be the only means for these people... Unfortunately these are still to general and don't always give you an accurate measurement of how dedicated to security the vendor was... This seems to be a big open-problem in practical security! --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymity +- credentials
- Original Message - From: Ian Grigg [EMAIL PROTECTED] [...] In terms of actual practical systems, ones that implement to Brands' level don't exist, as far as I know? There were however several projects that implemented and tested the credentials system. There was CAFE, an ESPRIT project. At Zeroknowledge there was working implementation written in Java, with a client that ran on a blackberry. There was also the implementation at ZKS of a library in C that implemented Brands's stuff, of which I participated in. The library implemented issuing and showing of credentials, with a limit on the number of possible showing (if you passed the limit, identity was revealed, thus allowing for off-line verification of payments for example. If you did not pass the limit, no information about your identity was revealed). The underlying math was modular, you could work in a subgroup of Z*p for prime p, or use Elliptic curves, or base it on the RSA problem. We plugged in OpenSSL library to test all of these cases. Basically we implemented the protocols described in [1], with some of the extensions mentioned in the conclusion. The library was presented by Ulf Moller at some coding conference which I don't recall the name of... It was to be used in Freedom, for payment of services, but you know what happended to that projet. Also, the use of Brands work would need to consider that he holds a swag of patents over it all (as also applies to all of the Chaum concepts). Yes, most of the stuff is patented, as is Chaum's stuff. Somebody had suggested that to build an ecash system for example, you could start out by implementing David Wagner's suggestion as described in Lucre [2], and then if you sell and want extra features and flexibility get the patents and implement Brands stuff. Similar strategy would seem to apply for digital credentials in general. There is an alternate approach, the E/capabilities world. Capabilities probably easily support the development of psuedonyms and credentials, probably more easily than any other system. But, it would seem that the E development is still a research project, showing lots of promise, not yet breaking out into the wider applications space. A further alternate is what could be called the hard-coded psuedonym approach as characterised by SOX. (That's the protocol that my company wrote, so normal biases expected.) This approach builds psuedonyms from the ground up, which results in a capabilities model like E, but every separate use of the capability must be then re-coded in hard lines by hardened coders. Do you have any references on this? Thanks. --Anton [1] http://crypto.cs.mcgill.ca/~stiglic/Papers/brands.pdf [2] http://anoncvs.aldigital.co.uk/lucre/theory2.pdf - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NCipher Takes Hardware Security To Network Level
- Original Message - From: Peter Gutmann [EMAIL PROTECTED] [...] If you think that's scary, look at Microsoft's CryptoAPI for Windows XP FIPS 140 certification. As with physical security certifications like BS 7799, you start by defining your security perimeter, defining everything inside it to be SECURE, and ignoring everything outside it. Microsoft defined their perimeter as the case of the PC. Everything inside the PC is defined to be SECURE. Everything outside is ignored. I believe that is typical of most software crypto modules that are FIPS 140 certified, isn't it? It classifies the module as multi-chip standalone. This is why you get requirements of the type that it should run on Windows in single-user mode, which I take to mean have only an admin account. This prevents privilege escalation attacks (regular user to root) that are easily done. I think this is reasonable, since you really are relying on the OS and the PC for the security of the module. More scary to me is stuff like DSSENH does not provide persistent storage of keys. While it is possible to store keys in the file system, this functionality is outside the scope of this validation. This is where Microsoft's CSPs do the dirty work, and use what is called the Data Protection API (DPAPI) to somehow safeguard keys somewhere in your system. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NCipher Takes Hardware Security To Network Level
- Original Message - From: Peter Gutmann [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 11:07 AM Subject: Re: NCipher Takes Hardware Security To Network Level Anton Stiglic [EMAIL PROTECTED] writes: This is why you get requirements of the type that it should run on Windows in single-user mode, which I take to mean have only an admin account. This prevents privilege escalation attacks (regular user to root) that are easily done. I think this is reasonable, since you really are relying on the OS and the PC for the security of the module. Uhh, so you're avoiding privilege escalation attacks by having everyone run as root, from which you couldn't escalate if you wanted to. This doesn't strike me as a very secure way to do things (and it would still get MSDOS certified, because you've now turned your machine into a DOS box protection-wise). Did you read the security policy of Netscape Security Module? Basically, if you want to get the configuration that is FIPS 140 certified, you need to install the module on a PC and add tamper resistant seals over appropriate interfaces, junctions and fasteners of all doors and covers in the enclosure of the PC, so that you can't open the cover without the fact being physically noticeable. I suggest adding some duct tape in strategic positions for additional security :). By reasonable I mean in the framework of having a general purpose software cryptographic library be certified FIPS. I'm not saying I find this secure. When I see a software library being certified FIPS 140, I say to myself it must implement the cryptographic algorithms in a descent way, has a descent random number generator, and stuff like that. I don`t care much about the physical boundary that they artificially determine. If I want high security, I will go with hardware. At the end of the line, what you want to protect is your secret keys, and if you don't have a tamper resistant hardware (that zeroizes your secrets when someone tries to poke at it) to do that it is difficult if not impossible. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
- Original Message - From: Tim Dierks [EMAIL PROTECTED] I think it's a tautology: there's no such thing as MITM if there's no such thing as identity. You're talking to the person you're talking to, and that's all you know. That seems to make sense. In anonymity providing systems often you want one side to be anonymous, and the other to identify itself (like in anonymous web surfing). In this case, if you are using DH to exchange keys, what you want is something like half-certified DH (see for example section 2.3 of [1]), where the web server authenticates itself. With half certified DH, Alice (the user that is browsing in my example) can be assured that she is really talking to Bob (web server she wanted to communicate with), and not a MITM. [1] http://crypto.cs.mcgill.ca/~stiglic/Papers/dhfull.pdf --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DH with shared secret
- Original Message - From: Jack Lloyd [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 03, 2003 5:13 AM Subject: DH with shared secret This was just something that popped into my head a while back, and I was wondering if this works like I think it does. And who came up with it before me, because it's was too obvious. It's just that I've never heard of something alone these lines before. Basically, you share some secret with someone else (call it S). Then you do a standard issue DH exchange, but instead of the shared key being g^(xy), it's g^(xyS) Not exactly the same thing, but you get the same properties: SKEME. See section 3.3.2, Pre-shared key and PFS, of SKEME: A Versatile Secure Key Exchange Mechanism for internet, Hugo Krawczyk. http://citeseer.nj.nec.com/krawczyk96skeme.html --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
- Original Message - From: Jerrold Leichter [EMAIL PROTECTED] [...] | I think it's a tautology: there's no such thing as MITM if there's no such | thing as identity. You're talking to the person you're talking to, and | that's all you know. | | That seems to make sense No; it's false. If Alice and Bob can create a secure channel between them- selves, it's reasonable to say that they are protected from MITM attacks if they can be sure that no third party can read their messages. How do they create the secure channel in the first place? We are talking about MITM that takes place during the key agreement protocol. That is: If Alice and Bob are anonymous, they can't say *who* can read the messages they are sending, but they might be able to say that, assuming that their peer is following the protocol exactly (and in particular is not releasing the shared secret) *exactly one other party* can read the message. That's false. Alice and Bob can follow the basic DH protocol, exactly, but Mallory is in the middle, and what you end up with is a shared key between Alice and Bob and Mallory. The property you are talking about, concerning the *exactly one other party* can read the message is related to the *key authentication* property, discussed in [1] (among other places), which enables you to construct authenticated key agreements. Note that if you have this, you can readily bootstrap pseudonymity: Alice and Bob simply use their secure channel to agree on a shared secret, or on pseudonyms they will henceforth use between themselves. If there were a MITM, he could of course impersonate each to the other ever afterward. But how do they share the initial secret? And with true anonymity you don't want linkability. Pseudonymity is a different thing, with pseudonymity you have linkability. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: VeriSign tapped to secure Internet voting
Schu stressed that several layers of security will prevent hackers from accessing the system. VeriSign will house the security servers in its own hosting centers. The company will ask military personnel to use their Common Access Cards--the latest form of ID for the military--to access the system and cast a vote. Civilians will use digital signatures. So how will these civilians get a certified public key, and how will the private key be protected? Is there a special policy for the issuance of these kind of certificates? --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: End of the line for Ireland's dotcom star
Why is it that none of those 100-odd companies with keys in the browsers are doing anything with them? Verisign has such a central role in the infrastructure, but any one of those other companies could compete. Why isn't anyone undercutting Verisign's prices? Look what happened with Thawte when it adopted this strategy: Mark Shuttleworth got to visit Mir! And Thawte got bought by Verisign, so no more competition... Interestingly, last time I checked, it was cheaper to buy from Thawte than it was from Verisign directly. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OpenSSL *source* to get FIPS 140-2 Level 1 certification
Really exiting news. If I'm not mistaken, this would be the first free, open-source, crypto library that has FIPS 140 module certification! Other free open-source libraries have algorithms that have been FIPS 140 certified, but the whole module hasn't been certified (exemple Cryptlib and Crypto++). And OpenSSL crypto module runs on all kinds of platforms. Really nice! --Anton - Original Message - From: Rich Salz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 05, 2003 10:50 AM Subject: OpenSSL *source* to get FIPS 140-2 Level 1 certification This is termendously exciting. For the first time ever, NIST will be certifying a FIPS 140 implementation based on the source code. As long as the pedigree of the source is tracked, and checked at run-time, then applications can claim FIPS certification. For details: http://groups.google.com/groups?dq=hl=enlr=ie=UTF-8threadm=bj9mos%242tbt%241%40FreeBSD.csie.NCTU.edu.twprev=/groups%3Fgroup%3Dmailing.openssl.users /r$ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Looking for an N -out-of-M split algorithm
Does anyone have any idea where I might learn about this algorithm - or indeed any algorithm which does the job. Just as Perry mentioned, look into Shamir Secret Sharing. There are also implementations of this, see for example http://www.astro.gla.ac.uk/users/norman/distrib/tontine.html (I'm not certain if I ever used that one in particular, so I don't know if it's good, but I'll let you do the research...). --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fwd: [IP] A Simpler, More Personal Key to Protect Online Messages
- Original Message - From: Whyte, William [EMAIL PROTECTED] [...] But you don't have to contact the CA to get someone's certificate. A standard way is to send them an email saying can you send me a signed message? Yes, that works. When I want someone to send me confidential email, and that someone doesn't know much or anything about crypto, I usually just send an S/MIME signed email, and let his MUA (usually Outlook or Outlook Express) do the work of saving the certificate and all. This also ensures you have the right public key. I haven't studied the details of IBE, but I assume that (a) there may be multiple IBE-based CAs, with different parameters, and The way I see IBE being useful is as a corporate solution for encrypting messages. Inside a corporation everyone will use the same public parameter (which could probably come with the software installation). And in most corporate crypto solutions you want key escrow, which IBE gives you as well for free :) The benefit is that you don't need to deal with users public keys: you don't need to get them from some repository or ask the person to send it to you by email and stuff. So say that you are with your laptop away, and don't have the persons public key certificate, you can still send him/here email directly (without asking anyone to send you his/her public key). I admit the feature is of limted value however. (b) the identity that's used to encrypt will be not just a name, but a name and a date (to ensure that some revocation-like capability exists). In either case, you can't simply pick the email address and use it as the public key; you need to establish some additional information first. This seems to put us back in the same place as with standard PKI, usability-wise. (Or, rather, there may be a usability delta for IBE, but it's very small). In the Boneh-Franklin paper one suggestion is to use [EMAIL PROTECTED] || current-year which would make public keys good for one year (which sounds reasonable, especially within a corporation). Of course, the software will include the year when creating the public key, the users wouldn't need to do it explicitly. If you really want to be able to revoke public keys, you need more granularity and use something like [EMAIL PROTECTED] || current-date, and that does become anoying for the users (need to fetch your private key everyday). One interesting thing about IBE is that you can transform any such scheme into a Non-interactive forward-secret cryptosystem as Adam Back pointed out: http://www.cypherspace.org/~adam/nifs/ (his web server might be down, but you can look at the cached version on Google...). --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: replay integrity
Integrity: Financial protocols that use crypto (as opposed to ones abused by crypto) generally include signed messages. The signature provides for its own integrity, as well as a few other things. I don't believe that is enough. Take for example the SSL 2.0 ciphersuite rollback vulnerability or the SSL 3.0 key-exchange algorithm vulnerability . Any kind of rollback attack is serious, and won't be protected by signatures in the bulk data (and those signature might be weakened by forcing a rollback to a possible weaker version/implementation). Replay: One of the commonest problems in HTTPS sites is replay failure. The solution is well known out in the real world - you have to have replay prevention at the higher layers. (Credit card processors have replay prevention too!) So, some protocols don't need replay prevention from lower layers because they have sufficient checks built in. This would apply to any protocols that have financial significance; in general, no protocol should be without its own unique Ids. So maybe I can't replay a complete financial transaction, because at some high layer there is replay prevention, what about replaying some init protocol request? Is that not annoying? Would a bank not care that their ATMs are not working for a day because someone is executing a DoS attack on the lower layers of the protocols of their system? I think not, you need replay protection on both levels. How can a secure socket be dubbed secure if it doesn't protect against these basic attacks? To quote from Wagner and Schneier`s paper, Analysis of the SSL 3.0 protocol: Replay attacks are a legitimate concern, and as they are so easy to protect against, it would be irresponsible to fail to address these threats. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Security of DH key exchange
- Original Message -
From: Jaap-Henk Hoepman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, June 20, 2003 5:02 AM
Subject: Security of DH key exchange
In practice the following method of exchanging keys using DH is used, to
ensure
bit security of the resulting session key. If alice and bob exchange g^a
and
g^b, the session key is defined as h(g^{ab}). This is mentioned in many
textbooks, but i can't find a reference to a paper discussing the security
of
this in the following sense. If g^a etc. are computed over a field F of
order
p, and h hashes F to {0,1}^n, under which conditions is h(g^{ab}) given
g^a and
g^b indistinguishable from a randomly selected session key k? (where
indistinguishable would mean that the advantage of the adversary of
distinguishing h(g^{ab}) from k is negligible in _n_).
I don't know of any references that will explain this explicitly, but the
reasoning is simple: You model h as a random oracle, which would imply that
if the minimum entropy of g^(ab) is at least n bits, then h(g^{ab}) will be
indistinguishable from a value chosen randomly for the set of n-bit strings.
For information on general about DH, you can look at the following
manuscript:
http://crypto.cs.mcgill.ca/~stiglic/Papers/dhfull.pdf
--Anton
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
