Quantcast

Cryptography in ZF

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Cryptography in ZF

Enrico Zimuel-2
Hi all,

recently, I did some presentations about cryptography in PHP and I did
not realized that ZF don't has a good API for most of the use cases that
I presented during my talks (for instance,
http://www.slideshare.net/ZendTechnologies/cryptography-in-php-some-use-cases).
I think is important to offer to PHP developers a good cryptographic
tool in ZF, with a simple API, to encrypt/decrypt data following the
best practices of cryptographic engineering in order to build secure
applications.
I would like to improve the Zend\Crypt component of ZF2 with the
following features:

- add the encrypt/decrypt methods to Zend\Crypt using the simmetric
algorithms of Mcrypt (Blowfish, AES, DES, 3DES, Twofish, etc)
- add the encryptThenAuth, AuthThenEncrypt, encryptAndAuth methods to
Zend\Crypt, to implement a secure encryption + authentication schema
(more info: http://www.cryptopp.com/wiki/Authenticated_Encryption)
- add the bcrypt algorithm to Zend\Crypt using the crypt('$2a$',...)
function of PHP 5.3.0
- improve the randomness of Zend\Crypt\Math::rand

Moreover, in ZF we have other components that use cryptography: Zend
\Filter\Encrypt and Zend\Filter\Decrypt. I was thinking to do a refactor
of these classes using the Zend\Crypt, what do you think?

Comments, feedbacks?

Regards,
Enrico Zimuel

--
Enrico Zimuel
Senior PHP Engineer     | [hidden email]
Zend Framework Team     | http://framework.zend.com
Zend Technologies Ltd.
http://www.zend.com


--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cryptography in ZF

EvanDotPro
On Wed, Jan 4, 2012 at 9:17 AM, Enrico Zimuel <[hidden email]> wrote:

> Hi all,
>
> recently, I did some presentations about cryptography in PHP and I did
> not realized that ZF don't has a good API for most of the use cases that
> I presented during my talks (for instance,
> http://www.slideshare.net/ZendTechnologies/cryptography-in-php-some-use-cases).
> I think is important to offer to PHP developers a good cryptographic
> tool in ZF, with a simple API, to encrypt/decrypt data following the
> best practices of cryptographic engineering in order to build secure
> applications.
> I would like to improve the Zend\Crypt component of ZF2 with the
> following features:
>
> - add the encrypt/decrypt methods to Zend\Crypt using the simmetric
> algorithms of Mcrypt (Blowfish, AES, DES, 3DES, Twofish, etc)
> - add the encryptThenAuth, AuthThenEncrypt, encryptAndAuth methods to
> Zend\Crypt, to implement a secure encryption + authentication schema
> (more info: http://www.cryptopp.com/wiki/Authenticated_Encryption)
> - add the bcrypt algorithm to Zend\Crypt using the crypt('$2a$',...)
> function of PHP 5.3.0
> - improve the randomness of Zend\Crypt\Math::rand
>
> Moreover, in ZF we have other components that use cryptography: Zend
> \Filter\Encrypt and Zend\Filter\Decrypt. I was thinking to do a refactor
> of these classes using the Zend\Crypt, what do you think?
>
> Comments, feedbacks?

+1 to all of this. Absolutely. This would allow me to greatly simplify
/ eliminate a lot of the code in my EdpUser module and also help
encourage others to use best practices for password storage.

--
Evan Coury

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


bfp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cryptography in ZF

bfp
This post has NOT been accepted by the mailing list yet.
In reply to this post by Enrico Zimuel-2
I totally agree.
This is really a overdue missing feature.
I have seen that there is already a crypt component, but I could not find a documentation.
Regards
Bernhard
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cryptography in ZF

Dolf Schimmel
In reply to this post by EvanDotPro
Hi,

What would be the advantage of the added functionality? Wouldn't it just
become a wrapper around mcrypt?

Furthermore, methods named  encryptThenAuth, AuthThenEncrypt,and
encryptAndAuth don't sound descriptive enough to me. I suppose two separate
methods auth() and encrypt() would make more sense, where a developer could
just determine what order he calls them himself?

Lastly, a few months ago I've been busy with cryptography in php myself as
well. And what I found was that (also because of several existing mcrypt
wrappers) php developers have no clue what's actually happening when they
encrypt something (what comprises of a good IV, can the iv be public,
should you use the same iv everywhere, is ECB really the most secure out
there? Etc...). If anything, we should not make it harder for developers to
understand what actually happens in this respect.

Regards,

Dolf
-- Freeaqingme

On Wed, Jan 4, 2012 at 5:48 PM, Evan Coury <[hidden email]> wrote:

> On Wed, Jan 4, 2012 at 9:17 AM, Enrico Zimuel <[hidden email]> wrote:
> > Hi all,
> >
> > recently, I did some presentations about cryptography in PHP and I did
> > not realized that ZF don't has a good API for most of the use cases that
> > I presented during my talks (for instance,
> >
> http://www.slideshare.net/ZendTechnologies/cryptography-in-php-some-use-cases
> ).
> > I think is important to offer to PHP developers a good cryptographic
> > tool in ZF, with a simple API, to encrypt/decrypt data following the
> > best practices of cryptographic engineering in order to build secure
> > applications.
> > I would like to improve the Zend\Crypt component of ZF2 with the
> > following features:
> >
> > - add the encrypt/decrypt methods to Zend\Crypt using the simmetric
> > algorithms of Mcrypt (Blowfish, AES, DES, 3DES, Twofish, etc)
> > - add the encryptThenAuth, AuthThenEncrypt, encryptAndAuth methods to
> > Zend\Crypt, to implement a secure encryption + authentication schema
> > (more info: http://www.cryptopp.com/wiki/Authenticated_Encryption)
> > - add the bcrypt algorithm to Zend\Crypt using the crypt('$2a$',...)
> > function of PHP 5.3.0
> > - improve the randomness of Zend\Crypt\Math::rand
> >
> > Moreover, in ZF we have other components that use cryptography: Zend
> > \Filter\Encrypt and Zend\Filter\Decrypt. I was thinking to do a refactor
> > of these classes using the Zend\Crypt, what do you think?
> >
> > Comments, feedbacks?
>
> +1 to all of this. Absolutely. This would allow me to greatly simplify
> / eliminate a lot of the code in my EdpUser module and also help
> encourage others to use best practices for password storage.
>
> --
> Evan Coury
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cryptography in ZF

Artur Bodera
On Mon, Jan 9, 2012 at 2:29 AM, Dolf Schimmel <[hidden email]>wrote:

> wrappers) php developers have no clue what's actually happening when they
> encrypt something


Actually that's a very good point.

The bad news is, hiding that behind an API does not provide a better
security.
It conceals the problem as opposed to educating about it. Actually,
API is not meant to educate people at anything - it's supposed to be
practical,
concise, efficient etc.

We could create an API that wraps mcrypt (or any other adapter) and then
expose some dummy-friendly methods, such as:
     init() or prepare()  -- which generates any intermediary data
automatically
     encrypt()
     decrypt()

All parameters would be explained in depth via @phpdoc. The good thing
is that we could employ some automated practices that increase security.
Bad news is, that we take the responsibility _away_ from developers, so
they had no education and they will not any new, any time soon.

Other than than, such user-friendly encryption would be nice to have,
given that the component shows exemplary care in terms of internal
structure and security, given the tools that mcrypt provides.



--
      __
     /.)\   +48 695 600 936
     \(./   [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cryptography in ZF

Enrico Zimuel-2
In reply to this post by Dolf Schimmel
Hi Dolf,


> What would be the advantage of the added functionality? Wouldn't it
> just become a wrapper around mcrypt?
>
My idea is to improve the interface of mcrypt offering a better API with
some default mechanism to prevent bad usage. For instance, secure IV
random if not provided.
That means these functionality are not just a wrapper of mcrypt.
>
> Furthermore, methods named  encryptThenAuth, AuthThenEncrypt,and
> encryptAndAuth don't sound descriptive enough to me. I suppose two
> separate methods auth() and encrypt() would make more sense, where a
> developer could just determine what order he calls them himself?
>
These are the standard ways to encrypt data in a secure way. The idea
here is to offer an high level interface to encrypt information using
the best practice of the cryptography engineering.
I would like to write a documentation and a reference guide about these
topics so developers can use it with some background.
Maybe the name of these methods are the best for this aim but I think we
can find a solution for that.

>
> Lastly, a few months ago I've been busy with cryptography in php
> myself as well. And what I found was that (also because of several
> existing mcrypt wrappers) php developers have no clue what's actually
> happening when they encrypt something (what comprises of a good IV,
> can the iv be public, should you use the same iv everywhere, is ECB
> really the most secure out there? Etc...). If anything, we should not
> make it harder for developers to understand what actually happens in
> this respect.
>
Actually, my intent is to provide a simple and secure API to use
cryptography in PHP. Cryptography is a difficult topic, I know, and this
is why I would like to simplify the API and inform developers about best
practices.

I know, the aim of this proposal is very ambitious but I think we should
try to offer such tools in a framework like ZF.


>
> On Wed, Jan 4, 2012 at 5:48 PM, Evan Coury <[hidden email]> wrote:
>         On Wed, Jan 4, 2012 at 9:17 AM, Enrico Zimuel
>         <[hidden email]> wrote:
>         > Hi all,
>         >
>         > recently, I did some presentations about cryptography in PHP
>         and I did
>         > not realized that ZF don't has a good API for most of the
>         use cases that
>         > I presented during my talks (for instance,
>         >
>         http://www.slideshare.net/ZendTechnologies/cryptography-in-php-some-use-cases).
>         > I think is important to offer to PHP developers a good
>         cryptographic
>         > tool in ZF, with a simple API, to encrypt/decrypt data
>         following the
>         > best practices of cryptographic engineering in order to
>         build secure
>         > applications.
>         > I would like to improve the Zend\Crypt component of ZF2 with
>         the
>         > following features:
>         >
>         > - add the encrypt/decrypt methods to Zend\Crypt using the
>         simmetric
>         > algorithms of Mcrypt (Blowfish, AES, DES, 3DES, Twofish,
>         etc)
>         > - add the encryptThenAuth, AuthThenEncrypt, encryptAndAuth
>         methods to
>         > Zend\Crypt, to implement a secure encryption +
>         authentication schema
>         > (more info:
>         http://www.cryptopp.com/wiki/Authenticated_Encryption)
>         > - add the bcrypt algorithm to Zend\Crypt using the
>         crypt('$2a$',...)
>         > function of PHP 5.3.0
>         > - improve the randomness of Zend\Crypt\Math::rand
>         >
>         > Moreover, in ZF we have other components that use
>         cryptography: Zend
>         > \Filter\Encrypt and Zend\Filter\Decrypt. I was thinking to
>         do a refactor
>         > of these classes using the Zend\Crypt, what do you think?
>         >
>         > Comments, feedbacks?
>        
>        
>         +1 to all of this. Absolutely. This would allow me to greatly
>         simplify
>         / eliminate a lot of the code in my EdpUser module and also
>         help
>         encourage others to use best practices for password storage.
>        
>         --
>         Evan Coury
>        
>         --
>         List: [hidden email]
>         Info: http://framework.zend.com/archives
>         Unsubscribe: [hidden email]
>        
>        
>        
>

--
Enrico Zimuel
Senior PHP Engineer     | [hidden email]
Zend Framework Team     | http://framework.zend.com
Zend Technologies Ltd.
http://www.zend.com


--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cryptography in ZF

Enrico Zimuel-2
In reply to this post by Artur Bodera
Hi Artur,


>         wrappers) php developers have no clue what's actually
>         happening when they
>         encrypt something
>
>
> Actually that's a very good point.
>
> The bad news is, hiding that behind an API does not provide a better
> security.
> It conceals the problem as opposed to educating about it. Actually,
> API is not meant to educate people at anything - it's supposed to be
> practical,
> concise, efficient etc.

General speaking I agree, but in this context I think it's important to
offer API that can improve, a little bit, the security (especially
because cryptography is a difficult topic). For instance checking the
params with some additional informations, generating good random IV if
not provided, etc.
>

> Bad news is, that we take the responsibility _away_ from developers,
> so
> they had no education and they will not any new, any time soon.
>
Of course, we have to write a good documentation an reference guide on
how to use such API. I think the responsability is always of the
developers. From a framework prospective, we cannot pretend to teach how
to write secure or good software, we should provide best practices
writing with the right components, that means offer the best API for ZF.


--
Enrico Zimuel
Senior PHP Engineer     | [hidden email]
Zend Framework Team     | http://framework.zend.com
Zend Technologies Ltd.
http://www.zend.com


--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cryptography in ZF

intellix
This post has NOT been accepted by the mailing list yet.
Education... if we wanted to spend more time learning things we shouldn't need to know then we would be writing and using our own framework :P
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cryptography in ZF

Wil Moore III
This post has NOT been accepted by the mailing list yet.
-100 :(
--
Wil Moore III

Best Practices for Working with Open-Source Developers
http://www.faqs.org/docs/artu/ch19s02.html

Why is Bottom-posting better than Top-posting:
http://www.caliburn.nl/topposting.html

DO NOT TOP-POST and DO trim your replies:
http://linux.sgms-centre.com/misc/netiquette.php#toppost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cryptography in ZF

Pádraic Brady
In reply to this post by Enrico Zimuel-2
I wouldn't mind seeing the API improved/simplified so I say go ahead
with some outline and see where it leads.

Paddy

On Mon, Jan 9, 2012 at 10:47 AM, Enrico Zimuel <[hidden email]> wrote:

> Hi Artur,
>
>
>>         wrappers) php developers have no clue what's actually
>>         happening when they
>>         encrypt something
>>
>>
>> Actually that's a very good point.
>>
>> The bad news is, hiding that behind an API does not provide a better
>> security.
>> It conceals the problem as opposed to educating about it. Actually,
>> API is not meant to educate people at anything - it's supposed to be
>> practical,
>> concise, efficient etc.
>
> General speaking I agree, but in this context I think it's important to
> offer API that can improve, a little bit, the security (especially
> because cryptography is a difficult topic). For instance checking the
> params with some additional informations, generating good random IV if
> not provided, etc.
>>
>
>> Bad news is, that we take the responsibility _away_ from developers,
>> so
>> they had no education and they will not any new, any time soon.
>>
> Of course, we have to write a good documentation an reference guide on
> how to use such API. I think the responsability is always of the
> developers. From a framework prospective, we cannot pretend to teach how
> to write secure or good software, we should provide best practices
> writing with the right components, that means offer the best API for ZF.
>
>
> --
> Enrico Zimuel
> Senior PHP Engineer     | [hidden email]
> Zend Framework Team     | http://framework.zend.com
> Zend Technologies Ltd.
> http://www.zend.com
>
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>



--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cryptography in ZF

Pádraic Brady
Well, it's either that or you're imagining things ;) Hehe.

Paddy

On Tue, Jan 24, 2012 at 9:38 PM, Artur Bodera <[hidden email]> wrote:

> Paddy!!
> You're back!!! :-)
>
>
> --
>       __
>      /.)\   +48 695 600 936
>      \(./   [hidden email]
>
>
> On Tue, Jan 24, 2012 at 8:55 PM, Pádraic Brady <[hidden email]>
> wrote:
>>
>> I wouldn't mind seeing the API improved/simplified so I say go ahead
>> with some outline and see where it leads.
>>
>> Paddy
>>
>> On Mon, Jan 9, 2012 at 10:47 AM, Enrico Zimuel <[hidden email]> wrote:
>> > Hi Artur,
>> >
>> >
>> >>         wrappers) php developers have no clue what's actually
>> >>         happening when they
>> >>         encrypt something
>> >>
>> >>
>> >> Actually that's a very good point.
>> >>
>> >> The bad news is, hiding that behind an API does not provide a better
>> >> security.
>> >> It conceals the problem as opposed to educating about it. Actually,
>> >> API is not meant to educate people at anything - it's supposed to be
>> >> practical,
>> >> concise, efficient etc.
>> >
>> > General speaking I agree, but in this context I think it's important to
>> > offer API that can improve, a little bit, the security (especially
>> > because cryptography is a difficult topic). For instance checking the
>> > params with some additional informations, generating good random IV if
>> > not provided, etc.
>> >>
>> >
>> >> Bad news is, that we take the responsibility _away_ from developers,
>> >> so
>> >> they had no education and they will not any new, any time soon.
>> >>
>> > Of course, we have to write a good documentation an reference guide on
>> > how to use such API. I think the responsability is always of the
>> > developers. From a framework prospective, we cannot pretend to teach how
>> > to write secure or good software, we should provide best practices
>> > writing with the right components, that means offer the best API for ZF.
>> >
>> >
>> > --
>> > Enrico Zimuel
>> > Senior PHP Engineer     | [hidden email]
>> > Zend Framework Team     | http://framework.zend.com
>> > Zend Technologies Ltd.
>> > http://www.zend.com
>> >
>> >
>> > --
>> > List: [hidden email]
>> > Info: http://framework.zend.com/archives
>> > Unsubscribe: [hidden email]
>> >
>> >
>>
>>
>>
>> --
>> Pádraic Brady
>>
>> http://blog.astrumfutura.com
>> http://www.survivethedeepend.com
>> Zend Framework Community Review Team
>
>



--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Loading...