Re: crypto for the average programmer

2005-12-27 Thread Ben Laurie
Jack Lloyd wrote:
 On Fri, Dec 16, 2005 at 05:41:48PM +, Ben Laurie wrote:
 
 No, OpenSSL is self-contained. There is, IIRC, an engine that uses GMP
 if you want, but its entirely optional; OpenSSL has its own bignum
 implementation that's just as good.
 
 Last I checked, public key operations in OpenSSL were significantly faster
 using the GNU MP engine - so just as good is perhaps not entirely
 accurate. OpenSSL's BN library is still very fast compared to many other MPI
 implementations, of course.

Apparently this rather depends on platform and compiler options. I am
reliably informed that GMP is not always faster.

For those that really care it'd be cool if someone did a careful
comparison. It would also be interesting to know why they differ.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

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


Re: crypto for the average programmer

2005-12-27 Thread Jack Lloyd
On Tue, Dec 27, 2005 at 02:28:07PM +, Ben Laurie wrote:

 Apparently this rather depends on platform and compiler options. I am
 reliably informed that GMP is not always faster.
 
 For those that really care it'd be cool if someone did a careful
 comparison. It would also be interesting to know why they differ.

Thank you for the correction. My statement was primarily on the basis of some
benchmarks I ran at the time I wrote some backend code in Botan to dump crypto
operations to GNU MP and/or OpenSSL when available, and at the time GNU MP
outperformed OpenSSL by a fairly large margin on x86 and Alpha machines (up to
50% on large RSA private key operations; as the keys got smaller the
performance difference reduced, down to basically nothing at 512 bit
keys). However I have since checked my changelogs and realized I must have run
those tests almost two years ago now (which surprised me a bit!), so I'm sure
those results are not particularly reflective of current performance. I'll have
to revisit this and see how things stack up these days on the platforms I care
about.

-Jack

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


Re: crypto for the average programmer

2005-12-19 Thread Richard Levitte - VMS Whacker
In message [EMAIL PROTECTED] on Sun, 18 Dec 2005 21:56:11 -0600, Travis H. 
[EMAIL PROTECTED] said:

solinym Anytime someone wants to rewrite a C library in a language
solinym less prone to buffer overflows, I'm totally for it.  Some say
solinym that it's not the library, it's the programmer, but I think
solinym that denies human factors.  C simply requires too much
solinym machinery on top of it to use it securely.
[...]
solinym And yet cryptographers continue to write in C.

C has three really strong points:

 - portability.  It's one of the most wide-spread and portable
   compiled languages that I know of.
 - speed.  Most languages with the same level of portability as C that
   I know of are interpreted.  They will probably never get to the
   level of speed you can get with C.
 - simple or compatible ABI.  C++ could be a good candidate if handled
   properly (yeah, yeah, I know), but I've yet to see that the ABI
   used by different compilers on the same platform not differ so
   much.  Most all, I'm thinking of name mangling (uhm, not really
   sure if that an ABI issue or not :-)).

As soon as there's a more secure language that fills those criteria, I
see not reason why you'd want to stay with C.  In the mean time, we'll
probably have to keep on living with its' defficiencies (I do agree
with you about those).

Cheers,
Richard

-
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte [EMAIL PROTECTED]
http://richard.levitte.org/

When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up.
-- C.S. Lewis

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


Re: crypto for the average programmer

2005-12-19 Thread Travis H.
On 12/19/05, Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote:
 C has three really strong points:

  - portability.  It's one of the most wide-spread and portable
   compiled languages that I know of.

I beg your pardon?  If I want to store 128 bits of information, and
access the 8 most significant bits, what portable data type would I
use? :)

The only way C is even remotely portable is with 30 years of #include
and typedef machinery, and POSIX, and many other standards.

  - speed.  Most languages with the same level of portability as C that
   I know of are interpreted.  They will probably never get to the
   level of speed you can get with C.

The old joke is that C combines the speed and power of assembly
language with the portability of assembly language.

Ocaml can outperform C in some cases.  Java is within an order of 
magnitude-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: crypto for the average programmer

2005-12-19 Thread Richard Levitte - VMS Whacker
In message [EMAIL PROTECTED] on Mon, 19 Dec 2005 01:19:37 -0600, Travis H. 
[EMAIL PROTECTED] said:

solinym On 12/19/05, Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote:
solinym  C has three really strong points:
solinym 
solinym   - portability.  It's one of the most wide-spread and
solinym portable compiled languages that I know of.
solinym 
solinym I beg your pardon?  If I want to store 128 bits of
solinym information, and access the 8 most significant bits, what
solinym portable data type would I use? :)

unsigned char foo[8];

(no, it isn't fool proof, but close enough after 1 second of thought).

solinym The only way C is even remotely portable is with 30 years of
solinym #include and typedef machinery, and POSIX, and many other
solinym standards.

You tell me what other language combines the wide spread (which is
important for portability) and speed of C.  Maybe I should have
mentioned availability as well...

solinym   - speed.  Most languages with the same level of
solinym portability as C that I know of are interpreted.  They
solinym will probably never get to the level of speed you can
solinym get with C.
solinym 
solinym The old joke is that C combines the speed and power of
solinym assembly language with the portability of assembly language.

Yeah, I've heard it before, and it's a lot of bull, at least the part
about portability.  I'd like to see you run an assembly program for a
68K on a VAX, or a VAX MACRO program on anything else, or...  Oh, and
for fairly modern stuff, try porting assembler between, say, an Alpha
and a Pentium...  Yeah, you probably got it by now.

solinym Ocaml can outperform C in some cases.  Java is within an
solinym order of magnitude.

Show me that ocaml is available on all current major platforms, and
I'll start looking at it.  And please, look outside the Unix family
sandbox.  For me, VMS is one of the must-be platforms.

solinym I mean, technically, the python interpreter is written in C,
solinym right?  So technically I am using C code when I write a
solinym python script.  And the C is implemented in assembler, which
solinym are implemented as microinstructions which are implemented as
solinym gates.  The point is, pick good expressive primitives, then
solinym analyze and re-use that low level stuff to write things at a
solinym higher level.  Minimize the amount you do in an unsafe way.

For some things, I'd agree.  It all depends on what we're talking
about, and from the subject, I'd gather we're mostly talking about
crypto algorithms, which is fairly low level stuff in the security
hierarchy.  I dunno about you, but it seems like most people are a bit
obsessed with speed at that level, like how many AES operations you
can do per second.  Unfortunately, the higher you go, the more complex
your operations become, and if we're talking interpreted languages,
there will always be the cost of interpretation, dispatching into the
underlying C routines, conversion of results, and so on.  I can't see
any way to get around that part.

Cheers,
Richard

-
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte [EMAIL PROTECTED]
http://richard.levitte.org/

When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up.
-- C.S. Lewis

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


Re: crypto for the average programmer

2005-12-19 Thread Travis H.
On 12/19/05, Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote:
 unsigned char foo[8];

 (no, it isn't fool proof, but close enough after 1 second of thought).

I think C guarantees that a char is a byte, but exactly how wide that
is is processor-dependent.  IIRC, some of the machines it was
developed on had less than 8 bits per byte, but I could be wrong. 
Surely a smaller byte is antiquated, but a wider char is certainly
conceivable.  Things don't really get messy until you start converting
types or communicating them to another machine.  At that point, you
really want to know if your int is 32 bits or 64, big or little
endian, etc.

OTOH, if C was truly as portable as is claimed, GNU autoconf wouldn't
exist.  Scripts are fairly portable; I can run bash scripts in cygwin,
I can run perl scripts using activeperl.  None have required
modification so far, though some use libraries (modules) that aren't
available on the target.

I realized halfway through this that I was thinking of applications
that use crypto, and not crypto algorithms per se.  But pretty much we
sound like we're in agreement on most things.
--
http://www.lightconsulting.com/~travis/  -- P=NP if (P=0 or N=1)
My love for mathematics is like 1/x as x approaches 0.
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B

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


Re: crypto for the average programmer

2005-12-19 Thread Richard Levitte - VMS Whacker
In message [EMAIL PROTECTED] on Mon, 19 Dec 2005 03:12:16 -0600, Travis H. 
[EMAIL PROTECTED] said:

solinym On 12/19/05, Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote:
solinym  unsigned char foo[8];
solinym 
solinym  (no, it isn't fool proof, but close enough after 1 second
solinym  of thought).
solinym 
solinym I think C guarantees that a char is a byte, but exactly how
solinym wide that is is processor-dependent.  IIRC, some of the
solinym machines it was developed on had less than 8 bits per byte,
solinym but I could be wrong.

Nope, you're right.  For example, on old PDP-10 and DEC-20, you'd have
5 7-bit chars in each 36-bit int.  Not entirely sure how unsigned
chars were implemented, though...

solinym Surely a smaller byte is antiquated, but a wider char is
solinym certainly conceivable.

Yup, I realised all that, hence it isn't fool proof.

solinym OTOH, if C was truly as portable as is claimed, GNU autoconf
solinym wouldn't exist.

It's true that the proliferation of incompatible header standards and
platform specific libraries have made things harder, as well as the
differing size and characteristics of some of the types.  Still,
because there's a way to build conditional code in a way that works on
all platforms, I still think it's among the more portable languages.
Not saying it's perfect, far from it, but I've yet to see another
language that has similar characteristics.

solinym Scripts are fairly portable; I can run bash scripts in
solinym cygwin,  I can run perl scripts using activeperl.  None have
solinym required modification so far,

Yeah, for crypto stuff, I must say that I don't find bash or perl to
be strong candidates, at least at the lowest level.

solinym though some use libraries (modules) that aren't available
solinym on the target.

Uhmm, isn't that what you'd use GNU autoconf for?  In my experience,
GNU autoconf is mostly used to figure out what the environment is
composed of, what libraries are available and things like that.

solinym I realized halfway through this that I was thinking of
solinym applications that use crypto, and not crypto algorithms per
solinym se.

Oh...  when you started this thread with talking about rewriting C
libraries to something less error prone, I didn't imagine you were
talking about the higher levels of functionality.  I believe a lot of
languages have a layer to interface with the lower level C libraries,
and I know that at least Perl, Python and Ocaml have interfaces to the
crypto algorithms in OpenSSL.

solinym But pretty much we sound like we're in agreement on most
solinym things.

Well, at least that C sucks :-).

Cheers,
Richard

-
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte [EMAIL PROTECTED]
http://richard.levitte.org/

When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up.
-- C.S. Lewis

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


Re: crypto for the average programmer

2005-12-18 Thread Bill Stewart

At 03:34 PM 12/14/2005, [EMAIL PROTECTED] wrote:

An application programmer who is using PKCS1 doesn't even need to
know the small amount of ASN.1 in the spec... libraries that
implement RSA PKCS1 take care of the ASN.1 for the programmer.


This is in fact one reason that ASN.1 exploits
have been so wide-ranging when they've happened.
ASN.1 is a horrendously ugly mess, even uglier than PGP,
so almost everybody uses an existing library instead of
rolling their own or writing a new library for other users.
Major bugs aren't discovered often,
but everybody's pretty much using the same C code,
whether for SNMP or X.509 or whatever.
I don't know how many of the Java et al. versions
have rewritten it natively as opposed to importing
C libraries, which is probably more convenient.



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


Re: crypto for the average programmer

2005-12-18 Thread Travis H.
Anytime someone wants to rewrite a C library in a language less prone
to buffer overflows, I'm totally for it.  Some say that it's not the
library, it's the programmer, but I think that denies human factors. 
C simply requires too much machinery on top of it to use it securely.

It is possible to write secure C code, much as it is possible to write
portable C code, but it requires discipline, and C makes it marginally
harder to use new constructs than native ones.  C's string libraries
in particular are so complex to use securely that OpenBSD rewrote
them.  And unlike portability, one cannot create a test that assures
that you have coded securely.

And yet cryptographers continue to write in C.

HHLs have their problems; in an interpreted language with immutable
strings, it may be hard to overwrite a crypto key.  However, these
kinds of problems do not account for 50% of the current
vulnerabilities the way buffer overflows do.
--
http://www.lightconsulting.com/~travis/  -- P=NP if (P=0 or N=1)
My love for mathematics is like 1/x as x approaches 0.
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B

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


Re: crypto for the average programmer

2005-12-17 Thread Jack Lloyd
On Fri, Dec 16, 2005 at 05:41:48PM +, Ben Laurie wrote:

 No, OpenSSL is self-contained. There is, IIRC, an engine that uses GMP
 if you want, but its entirely optional; OpenSSL has its own bignum
 implementation that's just as good.

Last I checked, public key operations in OpenSSL were significantly faster
using the GNU MP engine - so just as good is perhaps not entirely
accurate. OpenSSL's BN library is still very fast compared to many other MPI
implementations, of course.

-Jack

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


Re: crypto for the average programmer

2005-12-16 Thread Ben Laurie
[EMAIL PROTECTED] wrote:
 On Mon, 12 Dec 2005, Steve Furlong wrote:
 |  My question is, what is the layperson supposed to do, if they must use
 |  crypto and can't use an off-the-shelf product?
 | 
 | When would that be the case?
 | 
 | The only defensible situations I can think of in which a
 | non-crypto-specialist programmer would need to write crypto routines
 | would be an uncommon OS or hardware, or a new or rare programming
 | language which doesn't have libraries available from SourceForge etc.
 | Or maybe implementing an algorithm that's new enough it doesn't have a
 | decent free implementation, but I'm not sure such an algorithm should
 | be used in production code.
 I can tell you a situation that applied in one system I worked on:  You
 could 
 go with SSL, which gets you into GPL'ed code, not to mention the known

Eh? OpenSSL is BSD, not GPL.

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


Re: crypto for the average programmer

2005-12-16 Thread Ben Laurie
[EMAIL PROTECTED] wrote:
 |  |  My question is, what is the layperson supposed to do, if they must
 use
 |  |  crypto and can't use an off-the-shelf product?
 |  | 
 |  | When would that be the case?
 |  | 
 |  | The only defensible situations I can think of in which a
 |  | non-crypto-specialist programmer would need to write crypto routines
 |  | would be an uncommon OS or hardware, or a new or rare programming
 |  | language which doesn't have libraries available from SourceForge etc.
 |  | Or maybe implementing an algorithm that's new enough it doesn't have a
 |  | decent free implementation, but I'm not sure such an algorithm should
 |  | be used in production code.
 |  I can tell you a situation that applied in one system I worked on:  You
 |  could 
 |  go with SSL, which gets you into GPL'ed code, not to mention the known
 | 
 | Eh? OpenSSL is BSD, not GPL.
 When I last looked at this, OpenSSL was BSD, but it required some libraries 
 (GMP?) that were GPL.

No, OpenSSL is self-contained. There is, IIRC, an engine that uses GMP
if you want, but its entirely optional; OpenSSL has its own bignum
implementation that's just as good.

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


Re: crypto for the average programmer

2005-12-14 Thread Peter Gutmann
Travis H. [EMAIL PROTECTED] writes:

In Peter Gutmann's godzilla cryptography tutorial, he has some really good
(though terse) advice on subtle gotchas in using DH/RSA/Elgamal. I learned a
few no-nos, such as not sending the same message to 3 seperate users in RSA
(if using 3 as an encryption exponent).

I should point out that what's in the tutorial isn't an exhaustive list of
potential pitfalls, it simply contains examples of some of the easiest-to-
explain ones.  The reason for adding that section was that I've seen a number
of cases of people using raw PKC ops (e.g. raw, unpadded RSA) because their
boss told them Use RSA encryption and their crypto toolkit provides an
rsaEncrypt() function, the result being that they encrypt a 10MB file with RSA
in ECB mode.  Java is the main offender here, they make it pretty trivial to
do this even though it makes no sense, so people who are told to encrypt this
with RSA end up using the RSA-ECB that their tools give them.

My question is, what is the layperson supposed to do, if they must use crypto
and can't use an off-the-shelf product?  Is there any site tracking such
gotchas as they show up in the literature?

I don't know if there's any site tracking this, but (as the tutorial says) you
can either go with PKCS #1 (the de facto standard, easy to implement and
widely used) or if you want to put in the effort of tracking things through
the literature to see which one is currently in fashion, take your pick of
OAEP, RSA-PSS, Simple RSA, and so on ad nauseum.  The P1363 work tracks
progress in this area pretty closely, although you'll need some sort of P1363-
to-english phrasebook to figure out what they're saying.

Are there APIs written specifically so that a crypto-naive programmer can
safely use them?

Uhh, do you want a non-off-the-shelf product or an off-the-shelf product?  If
off-the-shelf is OK, grab any crypto toolkit that handles this for you and use
that, you know that if it's used in any standard protocol and interoperates
with a pile of other software then there's a good chance they've got it right.

Peter.

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


Re: crypto for the average programmer

2005-12-14 Thread Travis H.
On 12/14/05, Peter Gutmann [EMAIL PROTECTED] wrote:
 I don't know if there's any site tracking this, but (as the tutorial says) you
 can either go with PKCS #1 (the de facto standard, easy to implement and
 widely used) ...

Actually, I'm embarassed to admit this but I've seen PKCS before but
never with enough context to know what it was; I thought it was some
kind of RSA proprietary mumbo-jumbo.  But, oh dear, it involves ASN.1.
 That rules out use by the layperson.  I've run into ASN.1 before with
regard to SNMP, and it struck me as infinitely more complex than
anything I'd ever need to query packet counts on my router.

MIBs, subtype constraints, multiple sets of encoding rules, schemata? 
Hopeless.  The descriptions of ASN.1 I've seen are more complicated
than any cryptographic primitive I've ever run across.  I'd trust an
ASN.1 codec library about as much as I'd trust a DCE/RPC codec, give
or take an order of magnitude.

I'm not trying to be excessively curmudgeonly today, but I have to
note that the top google hit for ASN.1 has a list of myths about
ASN.1, of which the last two are true, a tutorial that begins with me
writing an ASN.1 specification with no guidance or introduction
whatsoever, and defines ASN.1 as a formalism for the specification of
abstract data types.  Oh, well that clears it up.  Does it help me
adopt new paradigms of data representation in a dynamic, fast-paced
environment?

And with that, I'm out.  :-P
--
http://www.lightconsulting.com/~travis/  -- P=NP if (P=0 or N=1)
My love for mathematics is like 1/x as x approaches 0.
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B

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


RE: crypto for the average programmer

2005-12-14 Thread Whyte, William

 On 12/14/05, Peter Gutmann [EMAIL PROTECTED] wrote:
  I don't know if there's any site tracking this, but (as the 
 tutorial says) you
  can either go with PKCS #1 (the de facto standard, easy to 
 implement and
  widely used) ...
 
 Actually, I'm embarassed to admit this but I've seen PKCS before but
 never with enough context to know what it was; I thought it was some
 kind of RSA proprietary mumbo-jumbo.  But, oh dear, it involves ASN.1.
  That rules out use by the layperson.  I've run into ASN.1 before with
 regard to SNMP, and it struck me as infinitely more complex than
 anything I'd ever need to query packet counts on my router.

Have a look at PKCS#1. There's hardly any ASN.1 in it at all and
the structures are relatively simple. There's also a PKCS examples
document that talks you through it.

William

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


Re: crypto for the average programmer

2005-12-12 Thread Steve Furlong
 My question is, what is the layperson supposed to do, if they must use
 crypto and can't use an off-the-shelf product?

When would that be the case?

The only defensible situations I can think of in which a
non-crypto-specialist programmer would need to write crypto routines
would be an uncommon OS or hardware, or a new or rare programming
language which doesn't have libraries available from SourceForge etc.
Or maybe implementing an algorithm that's new enough it doesn't have a
decent free implementation, but I'm not sure such an algorithm should
be used in production code.

Indefensible situations include the programmer wanting to write his
own crypto because it's cool or because he just knows he can do better
than all the specialists (in which case he's too arrogant or ignorant
to benefit from a common gotchas list) or the manager telling the
programmer to implement it himself for some bad reason (in which case
the programmer should explain why that's a bad idea).


--
Oooh, so Mother Nature needs a favor?! Well maybe she should have
thought of that when she was besetting us with droughts and floods and
poison monkeys! Nature started the fight for survival, and now she
wants to quit because she's losing. Well I say, hard cheese. --
Montgomery Burns

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


RE: crypto for the average programmer

2005-12-12 Thread Whyte, William

 In Peter Gutmann's godzilla cryptography tutorial, he has some really
 good (though terse) advice on subtle gotchas in using DH/RSA/Elgamal. 
 I learned a few no-nos, such as not sending the same message to 3
 seperate users in RSA (if using 3 as an encryption exponent).

 My question is, what is the layperson supposed to do, if they must use
 crypto and can't use an off-the-shelf product? 

Check the standards.

The RSA PKCS#1 standard, which are free, describe 
how to do RSA securely and summarize known security results. 
http://www.rsasecurity.com/rsalabs/node.asp?id=2124. Don't use
PKCS#3-style Diffie Hellman; it's been superseded by the 
versions in ASC X9.42 and IEEE Std 1363-2000.

The Standards for Efficient Cryptography Group (www.secg.org)
publishes SEC1, which describes how to do Elliptic curve algorithms
securely. The standard is free to download, but note that some 
techniques in it have licensing requirements.

NIST, in its series of FIPS standards and Special Publications, has defined 
federal standards for digital signatures and modes of operation for symmetric 
ciphers, and is moving towards standardizing key exchange mechanisms based
on public key algorithms. Those standards are also free, though they
sometimes reference non-free standards.

Other standards groups, such as the IEEE P1363 Working Group (which I chair
-- http://grouper.ieee.org/groups/1363/) and the ASC X9F1 working group 
for cryptographic techniques for the financial services industry, publish 
(for purchase) standards for secure use of other public-key algorithms. 
1363 is currently working on 
- Lattice-based cryptography, such as NTRU (who I work for)
- Password-based public key techniques such as SPEKE, SRP, etc
- A revision of the 1363-2000 standard.
A lot of the documents relevant to these projects are available for
free off the site. X9 is working on a wider range of projects, but
your company has to be an X9 member for you to access them.

 Is there any site
 tracking such gotchas as they show up in the literature?

Rather than tracking gotchas minute-by-minute it's probably best
to use existing standards.

Cheers,

William

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


RE: crypto for the average programmer

2005-12-12 Thread Whyte, William
 NIST, in its series of FIPS standards and Special Publications, has defined 
 federal standards for digital signatures and modes of operation for symmetric 
 ciphers, and is moving towards standardizing key exchange mechanisms based
 on public key algorithms. Those standards are also free, though they
 sometimes reference non-free standards.

Sorry, meant to include links for these:

Overall home page: http://csrc.nist.gov/focus_areas.html#csa

FIPS: http://csrc.nist.gov/publications/fips/index.html

Special Publications: http://csrc.nist.gov/publications/nistpubs/

Wiliam

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


Re: crypto for the average programmer

2005-12-12 Thread Alexander Klimov
On Mon, 12 Dec 2005, Travis H. wrote:
 In Peter Gutmann's godzilla cryptography tutorial, he has some really
 good (though terse) advice on subtle gotchas in using DH/RSA/Elgamal.
 I learned a few no-nos, such as not sending the same message to 3
 seperate users in RSA (if using 3 as an encryption exponent).

Probably you have misunderstood it: if you do it correctly (e.g.,
use some standard method like RSAES-OAEP or even RSAES-PKCS1-v1_5)
you can send the same message to 3 (or whatever) separate users
without any bad consequences. The problem appears if you use some
non-standard method, e.g., plain RSA (c = m^e \pmod n).

 My question is, what is the layperson supposed to do, if they must
 use crypto and can't use an off-the-shelf product?

This is quite simple: get some respected standard (see, e.g.,
NIST http://csrc.nist.gov/CryptoToolkit/ or
PKCS http://www.rsasecurity.com/rsalabs/node.asp?id=2124) and
implement it exactly. Interoperability is a bonus :-)

-- 
Regards,
ASK

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


Re: crypto for the average programmer

2005-12-12 Thread James A. Donald


Date sent:  Mon, 12 Dec 2005 00:41:13 -0600
From:   Travis H. [EMAIL PROTECTED]
To: cryptography@metzdowd.com
Subject:crypto for the average programmer

 In Peter Gutmann's godzilla cryptography tutorial, he has some really
 good (though terse) advice on subtle gotchas in using DH/RSA/Elgamal.
 I learned a few no-nos, such as not sending the same message to 3
 seperate users in RSA (if using 3 as an encryption exponent).
 
 My question is, what is the layperson supposed to do, if they must use
 crypto and can't use an off-the-shelf product?  Is there any site
 tracking such gotchas as they show up in the literature?  Are there
 APIs written specifically so that a crypto-naive programmer can safely
 use them?

It seems to me that if the only thing you use public key encryption 
for is to encrypt a single use randomly chosen symmetric key, and 
integrity bits for that key, and if you then use that symmetric key 
once and only once, to encrypt a message that already contains 
integrity checking and a unique random number, you don't need to 
worry about those issues.

Of course those issues reappear when using public keys for signature 
algorithms - so don't invent your own signature protocol.  Signatures 
are hard.


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


RE: crypto for the average programmer

2005-12-12 Thread James A. Donald
--
From: Whyte, William [EMAIL PROTECTED]
 Check the standards.

 The RSA PKCS#1 standard, which are free, describe how 
 to do RSA securely and summarize known security 
 results. 
 http://www.rsasecurity.com/rsalabs/node.asp?id=2124. 
 Don't use PKCS#3-style Diffie Hellman; it's been 
 superseded by the versions in ASC X9.42 and IEEE Std 
 1363-2000.

 The Standards for Efficient Cryptography Group 
 (www.secg.org) publishes SEC1, which describes how to 
 do Elliptic curve algorithms securely. The standard is 
 free to download, but note that some techniques in it 
 have licensing requirements.

 NIST, in its series of FIPS standards and Special 
 Publications, has defined federal standards for 
 digital signatures and modes of operation for 
 symmetric ciphers, and is moving towards standardizing 
 key exchange mechanisms based on public key 
 algorithms. Those standards are also free, though they 
 sometimes reference non-free standards.

Of course most of this has already been incorporated in 
standard crypto libraries, such as CryptoPP, and does 
not need to be rewritten.

Be warned, however, that if you faithfully follow a 
standard without comprehending why the standard is the 
way that it is, you will probably screw it up, because 
you will not really understand what faithfullness is.

In practice, it is frequently necessary to roll your own 
damned standards, and in practice, people who roll their 
own damned standard frequently get them wrong.  For 
example SSH had to be SSH, it could not be SSL, and the 
first version of SSH was, predictably, wrong.  Similarly 
the first version of Wifi used WEP, which contained 
errors that should have been spotted, but were not. They
had to roll their own, because they needed to solve a
particular problem which was not the same as the 
problems that other standards solve.

You should, however, never roll your own damned standard
without good reason. 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 TXXgVeLZjViyf6+f7NQt7WCs7MzxO/j25GYLXcEg
 4js14nleizkni3mC38n+4rk2r07+4mylYuP2+UnlI



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


Re: crypto for the average programmer

2005-12-12 Thread leichter_jerrold
On Mon, 12 Dec 2005, Steve Furlong wrote:
|  My question is, what is the layperson supposed to do, if they must use
|  crypto and can't use an off-the-shelf product?
| 
| When would that be the case?
| 
| The only defensible situations I can think of in which a
| non-crypto-specialist programmer would need to write crypto routines
| would be an uncommon OS or hardware, or a new or rare programming
| language which doesn't have libraries available from SourceForge etc.
| Or maybe implementing an algorithm that's new enough it doesn't have a
| decent free implementation, but I'm not sure such an algorithm should
| be used in production code.
I can tell you a situation that applied in one system I worked on:  You
could 
go with SSL, which gets you into GPL'ed code, not to mention the known
complexities of using the SSL libraries correctly (steep learning curve); or

we could go commercial code that had fairly steep license fees.  The
decision 
was to use off-the-shelf where completely unencumbered (e.g., Gladman's AES 
implementation), build the rest ourselves.

BTW, there are other issues with SSL.  We needed to fit this implementation
in 
to an already-running system with minimal effect - but try to get people to 
use it.  Having to get certificates for SSL was a big hurdle.  Even creating

self-signed certs was a hassle.  The existing code ran directly over TCP,
and 
assumed a byte stream.  SSL is record-oriented.  This shows up, for example,
when your 1-byte ACK (of which we send many) turns into a 32-byte block (or 
even larger).

We weren't interested in complete security - we just needed to raise the 
level considerably.  Given the nature of the application, message 
authentication was not *that* big a deal - it could be put off.

SSL is a fine protocol, and on theoretical terms, yes, you probably want 
everything it provides.  But in practice it's too much.

BTW, there are some interesting social issues.  Before we implemented our 
own crypto layer, we recommended people go through ssh tunnels.  The product

was set up to allow that.  I made the argument Do you really want us to 
provide your crypto?  We're not crypto experts.  But this was perceived as 
clunky, complicated ... it didn't make it look as if the *product*.  Those 
factors were ultimately seen as more important than the very highest level
of 
security.  You can *still* use ssh, of course  (In fact, I was in a 
discussion with a military contractor who wanted to use the product.  The 
question came up of exactly how our crypto worked, whether it would be 
approvable for their application, etc.  My comment was:  Isn't NSA providing

you guys with encrypted links anyway?  Answer - sure, you're right; we don't

need to do application-level encryption.  If IPSEC were actually out there,
all sorts of nasty issues would just magically go away.)

-- Jerry


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