### 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
...

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

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
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\
A73559C283C4F281FBF82FA292E6BC1DC5DF5773AFFC3EA2425CE95AC779E7D790F5\
9D11E3527D5645D9580BBF68909C2A1C4672204859CF46CAA247186D917241A79224\
C9B695499644AEEA43DAEFDC5438E9B96952771F1FBC809655EF5A5A5A148FFD4719\
7369F4A854983220596A
m
C68C6FEA9A08822C1DA79D4D975F95BF9EB56A906A66F7B63AF7CFC5B7A43012DDB4\
56CA2106F196D0E6E8DE2D95D300935F5942638220073E311EB59FE9E2D7F84E\
F753A415E47E42604175F4B7F1AF52838B0BBA5769120B8DAFA1FFB5C96D961BA1E5\
20717202DE09379F34960F03FE196F0A97704BFE32A5DF0D81445E8DDBAF750B5213\
3EBF07D4859032AE392F161544BE5860579ABA6A6F34395D44754DC24C5C37D90F7F\
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\
CF0134CB61352E9CE6CB3D847C7F3D9AFA74E8E19DD1ED7923270E310A5D91E97EF1\
98694465950715AA066ACB06FAEC0BA64FCCCA155104852EFD41346F75D1ACB8574B\
42B8E643B74B8746B594866C7CBDAB8FEA954FDEE7C44B9C5D6B9E19B49082D65B51\
7EA7DBFEF5CA1EEA39AB2283CDB854C8B246F2B8EFE51895349640248A3248EC65F6\
4A89CA5AB194B444DF676B015AFBCACE13697CEEB5268F5E9AA674A83DD1B0CE4DC8\
3603CFFB801DB669216FC647CD7A6A84831E421D9676C7AAC44411B2AB3E901A7139\
B3519B58EBAEEC20B
s
7FFF\
\
AC5D20CF08046814578C2B994E1DBD8413A43C05640
bits(m)
BF1
bits(s^3)
BF1
m - s^3
-27AE2AEB7CBA9F90A796CA2DD832A3080FB076F53AFDBE8745A0B117A288696E73C\
2385A6AE367AAC634DBF1D745B53C5041F0914CEAE5F245029793DCB5CF2F82A6F29\
E5AB8BB6E40F2971E53806B3236763E63D1DA4DDB1E7E900E10140D0269B4003F3C2\
7EACDEB5C1035A4765F029AF59AB74B1A6C2A091E14405AA4BB6321B36E4BF62A465\
6796BB9A6DA29467C54B41AC61C95E3785A9F85D4578F21C056D03ECF9128580717D\
563B5F437FEB9CDCAAE7E01D6C84F908AF5336EC3D710D6DF1F282A270E150F32438\
31826C7843300F514A6B799383425470156AB021183BB4637CBCB87B1902C4D519D7\
52B7C10EC94263DF2E26A5466F17150A2E4E2745BD967E5CC8352D58EE7A5237E637\
4BD35CE67B61094E6292B8E8BA5005F3D0F436A6C0EE1F47EDAFD37F94C16FE58EC6\
4CAE64A7145113DF5

modexp(s, 3, m)
27AE2AEB7CBA9F90A796CA2DD832A3080FB076F53AFDBE8745A0B117A288696E73C2\
385A6AE367AAC634DBF1D745B53C5041F0914CEAE5F245029793DCB5CF2F82A6F29E\
5AB8BB6E40F2971E53806B3236763E63D1DA4DDB1E7E900E10140D0269B4003F3C27\
EACDEB5C1035A4765F029AF59AB74B1A6C2A091E14405AA4BB6321B36E4BF62A4653\
796BB9A6DA29467C54B41AC61C95E3785A9F85D4578F21C056D03ECF9128580717D5\
63B5F437FEB9CDCAAE7E01D6C84F908AF5336EC3D710D6DF1F282A270E150F324383\
1826C7843300F514A6B799383425470156AB021183BB4637CBCB87B1902C4D519D75\
2B7C10EC94263DF2E26A5466F17150A2E4E2745BD967E5CC8352D58EE7A5237E6373\
BD35CE67B61094E6292B8E8BA5005F3D0F436A6C0EE1F47EDAFD37F94C16FE58EC64\
CAE64A7145113DF5
modexp(s/100, 3, m)
1FFF\
\
FFF003021300906052B0E03021A05000\
4145D89B46034E0F41A920B2FA964E230EBB2D040B00\
\
02A9AA11CBB60CB35CB569DDD576C272967D774B02AE385C6EE43238C8C9\
1477DBD0ED06ECF8BC4B8D3DC4D566FA65939092D09D13E0ED8F8BE5D5CB9E72C47C\
743B52BBFA7B9697DA285694CD9347AB7528\
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:
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 dont 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 dont 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
b12fc1b0b8d5d32db50395374aeb3c215c2bc566328d2f03bf043068c5c9abc649ba1767e97d
f32b6aa734594ee22fffe7fb06ea3b77030e79bd6fe7683ab7ffce462abfba5777b3914de466
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
AEB3C215C2BC566328D2F03BF043068C5C9ABC649BA1767E97DF32B6AA734594EE22FFFE7FB0
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
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
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

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).

-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.

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

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]

```

### New IBM Thinkpad includes biometrics

```

I wonder how well it can counter the attacks discussed by researchers in the
last few years.  Like reactivating a fingerprint authentication by breathing
on the sensor's surface containing residue fat traces of the finger, or
placing a bag of water.  Or the jelly finger trick.
The biometric authentication might very well make the laptop less secure

--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.

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

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

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

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:

I came up with a similar diagram for a presentation I recently gave, but
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,

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

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

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

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
(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
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

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

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
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
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: safety of Pohlig-Hellman with a common modulus?

```
- Original Message -
From: Peter Fairbrother [EMAIL PROTECTED]
To: David Wagner [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Saturday, December 06, 2003 7:58 PM
Subject: Re: safety of Pohlig-Hellman with a common modulus?

David Wagner wrote:

Steve Bellovin  wrote:
Is it safe to use Pohlig-Hellman encryption with a common modulus?
That is, I want various parties to have their own exponents, but share
the same prime modulus.  In my application, a chosen plaintext attack
will be possible.  (I know that RSA with common modulus is not safe.)

Yes, I believe so.  The security of Pohlig-Hellman rests on the
difficulty
of the discrete log problem.

Nope. In P-H there is no g. A ciphertext is M^k mod p. An attacker won't
know k, and usually won't know M, but see below. I don't know what the
problem is called, but it isn't DLP. Anyone?

If you don`t know M and k, there are several values M', k' such that
M'^k' mod p == M^k mod p.   For example, if M is a generator of the
group mod p, than all other generators M' will have a corresponding k'
that will give you this value.

Think about known plaintext attack or chosen plaintext attack.  A symmetric
cipher should be secure against these attacks and much more...
In these attacks you know the bases of several values...

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

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
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: Ian Grigg [EMAIL PROTECTED]

* In contrast, someone who knows little about cars,
can objectively evaluate a car.  They can take it
for a test drive and see if it feels right.  Using
it is proving it.

I'm not totally convinced of this...  Someone with little knowledge about
cars might see the difference between a KIA and a Mercedes in one test
drive, but I would think that most affordable cars seem to drive the same
in a simple test drive (at least from my experience).  But what
a person will do is talk to his friends and get feedback, he'll learn that
some type of cars have a bad reputation and others seem to be good.
This is also done in security, take for example host security modules used
by banks, most banks make their choice  based on the vendors reputation.
Unfortunately this choice is often influenced by publicity (and the more a
certain company sells, the more money it makes, the more publicity it can
afford, the more it will sell, even if their product is not the best).

There is a marketing rule that state that there is one product that
dominates
its field in every category and gets about 80% of all sells, then there are
1-3
other products that battle for second place, all others get almost nothing.
(example for cola Coke is number 1, with Pepsi
coming second).  I don't think security products make an exception to
this.

Another way people choose products is if they are recommended.  For
example, I buy a certain toothpaste because it is recognized by the
Canadian dental association.  This is a sort of certification.  There are
certainly other example of products in everyday life that get this type
of certification that influence people's choices.  Of course, publicity
also has some degree of influence here as well.

There are no official security associations recognized by the government
that include most of the security experts we know, rather what exists is
certain standards that the government itself decides upon and are used
(FIPS 140, CC).  This lack of an independent security association to
which any security expert can become a member of is maybe the root
of the problem?

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

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

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

/r\$
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

```

### Re: PRNG design document?

``` Allow me to clarify my problem a little. I'm commonly engaged to review
source code for a security audit, some such programs include a random
number generator, many of which are of ad-hoc design. The nature of such
audits is that it's much more appealing to be able to say here are three
accepted guidelines that your generator violates rather than I haven't
seen that before and I don't like it, you should replace it with something
else.

Here are two references that might also be helpful:

http://www.cryptography.com/resources/whitepapers/VIA_rng.pdf
http://www.cryptography.com/resources/whitepapers/IntelRNG.pdf

These are reports on the analysis of two RNGs, I found them well written.

--Anton

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

```

### Re: Looking for an N -out-of-M split algorithm

```
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
(his web server might be down, but you can look at the cached version

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

--Anton

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

```

### Re: pubkeys for p and g

```I'm not certain I understand your questions, but here are some answers (I
think).
In the DH protocol you have what we call public parameters, p and g.
p is a large prime integer, which defines a group Z*p, g is a generator
which
defines a subgroup in Z*p.
You can use fix values for p an g.
Now, participants will choose private and public keys.  The private key
is simply chosen as a random number x, whose value is between 1 and
p-1.   The public key associated to x will be y = g^x mod p.
Participants keep x secret and y is public.
You can say that (y, g, p) is the public key, or simply say that y is the
public
key if g and p (the public parameters) are implicitly known.
Participants can choose a different x and associated y on each execution
of the protocol, or have long term private public key pairs.

--Anton

The Check Point Firewall-1 Docs insist, that the public keys be used
for p and g for the Oakley key exchange. I ask you: is this
possible?

- which of the two pubkeys will be p, which g?
- are they both always primes?
- are they both always suitable generators mod p?

It just seems to me that Check Point isn't entirely sure themselves
here. I'd appreciate a short cleanup...

To my knowledge, g and p are globally defined, either in DH Groups
(which are nothing but pre-defined g's and p's, right?), or

Thanks.

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

```