[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <569E01B3.8@mivargroup.nl>
Date: Tue, 19 Jan 2016 10:28:19 +0100
From: Bart van Tuil <bvantuil@...argroup.nl>
To: Scott Arciszewski <scott@...agonie.com>,
"fulldisclosure@...lists.org" <fulldisclosure@...lists.org>,
"oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Subject: Re: [FD] It essentially wins crypto vulnerability bingo!
gilfether/phpcrypt
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Scott,
I believe you are confusing implementation with technique: a good
framework to make use of a more low-level function is for the
mainstream developer the best part. In technology itself, an ECC vs
RSA is really up for discussion.
Though ECC is more performant, as well in terms of keylength vs
security and cpu/memory resources (depending on implementation) than
RSA, RSA has a legacy of being shot at for ages where ECC is
relatively new and may, with higher probability, still contain
undiscovered weaknesses. This is especially true for new constructions
now or recently introduced.
Frameworks/helper libraries around these relatively low-level
functions are a whole other story though - but both have in common
that the frameworks and helper libaries exist, which can be
implemented without knowing exactly what is going on in the background.
I am guessing, without knowing exactly what this EasyRSA library
features, you will still remain with a trade-off between factors like
performance and general support. Where ECC would be carried easier by
USA government, RSA would be more carried by devices like passes and
other (existing) constructions for personal authentication.
It feels a little short-sighted to immediately write off RSA with the
coming of something new, while ECC still has to largely prove itself
and RSA has its weaknesses widely known (and can be defended against).
Especially if there's libaries, as you mentioned before, that
implement correct OAEP (with SHA256), as well as there are for ECC.
I would love to continue this conversation, but i guess we should take
it to outside of the mailing list. This could well be something really
productive.
All the best,
Bart
Scott Arciszewski schreef:
> On Mon, Jan 18, 2016 at 4:17 AM, Bart van Tuil
> <bvantuil@...argroup.nl> wrote:
>>
> I don't get something:
>
>>>> 4. https://github.com/paragonie/EasyRSA (reluctantly included
>>>> for people that really believe they need RSA)
>
> ...What's, in your opinion ofcourse, t he wrong thing about
> implementing RSA in a decent web application? PHP is used for
> much, much more than building simple frontpages without a backend
> (where this might be a senseless complication). RSA is still the
> way to go about implementing accessible asymmetrical
> crypography...
>
> I do agree, wholeheartedly, that building your own cryptographic
> primitives is just an expensive way of ultimately fooling
> yourself.
>
> Just wondering...
>
>
> All the best,
>
>
> Bart
>
>
> <rant> PS: All this bashing on PHP really tires me - it's getting
> old and redundant. And no - im not a PHP developer. </rant>
>>
>>
>> This email and any attached files are confidential and intended
>> solely for the intended recipient(s). If you are not the named
>> recipient you should not read, distribute, copy or alter this
>> email. Any views or opinions expressed in this email are those of
>> the author and do not represent those of the company. Warning:
>> Although precautions have been taken to make sure no viruses are
>> present in this email, the company cannot accept responsibility
>> for any loss or damage that arise from the use of this email or
>> attachments.
>>
>
>> What's, in your opinion ofcourse, the wrong thing about
>> implementing RSA in a decent web application? ... RSA is still
>> the way to go about implementing accessible asymmetrical
>> crypography...
>
> No it's not. You should, in order of best to worst, choose:
>
> 1. ECDH/EdDSA over Curve25519 or Curve448. Use ECDH for determining
> a shared secret key for symmetric key cryptography (i.e. ChaCha20
> + Poly1305), use EdDSA for deterministic signatures. This is what
> libsodium's crypto_box() and crypto_sign() do.
>
> 2. ECDH/ECDSA over NIST P-256, if you really have to implement
> support for them.
>
> 3. 2048-bit e=65537 RSA, using OAEP for encryption and PSS for
> signatures, with MGF1+SHA256. You should also hire an expert to
> review your implementation and parameter choices.
>
> Most people who implement RSA implement PKCS1v1.5 padding, which
> has been publicly known to be vulnerable to a chosen-ciphertext +
> padding oracle attack. SINCE 1998. Also, e = 3 RSA signature with
> PKCS1v1.5 padding is what broke Firefox's certificate validation a
> few years back.
>
> That's a lot of land mines to overcome, and do you really expect a
> line-of-business web developer to dodge them all? Even if they
> succeed, the security of RSA hinges on the difficulty of prime
> factorization; something that improvements in index calculus
> attacks are weakening every year. It's a sinking ship.
>
> Contrast with libsodium. All you need is crypto_sign() and
> crypto_sign_open(). Or crypto_box() and crypto_box_open(). All of
> which uses modern, side-channel-resistant elliptic curve
> cryptography. It couldn't be much simpler while also being
> conservatively secure.
>
> Stop implementing RSA. You're setting yourself up for failure.
>
>> PHP is used for much, much more than building simple frontpages
>> without a backend (where this might be a senseless
>> complication).
>
> Of course.
>
> Scott Arciszewski Chief Development Officer Paragon Initiative
> Enterprises
>
- --
_________________________________________________________
Met vriendelijke groeten | With kind regards | Mit freundlichen Grüßen
Bart van Tuil | MivarGroup B.V. | De Hofstede 30a-c | 4033 BV Lienden
T +31 (0) 344 609 000
F +31 (0) 344 609 010
E bvantuil@...argroup.nl
I www.mivargroup.nl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJWngGyAAoJEEnUI2SRQ8182GoH/0bZcSGjBSd1VVFVG8Pq/pNn
KUfVDG2GCbTTFknuLxnjO4lUyvLwoIiZH6OOH3BnfHCGO2kjsvz17ucE/qMcmfqM
S1R/aHDq8z2/naEH+PkRPMyG1LqiNGBNMc/tRyKqcjLcZ89DB7at7eYAxQnN/9U7
+VTAERJCtFZDbumHx712UAD6BuRlTDUTmVrsXrBGIaCJLF2AaeymZlayT5qrBrg9
OgpzCKHbPykIOgSmQQWzNyp7imOPzLPhOjgr3+74ccnUFclBC5PCH8IyYklO7lS/
oJI6FREmZEHiMBKouX4TotT8Ohxv2iQzDwsSPGwJ6VCdXd6UO9vxN/F6mWTwhGI=
=xMh6
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
