Re: [Phpgroupware-developers] Re: [ phpgroupware-Bugs-445721 ] email password not saved.

[Tony (Angles) Puglisi]

Miles,
There have been no "changes" to _existing_ crypto, we have a seperate,
developmental set of en/de crypt functions that do not effect existing apps, 
these
functions are committed as such EXACTLTY for the purpose of PUBLIC review.

In fact, these functions do NOTHING different yet, except correctly "mirror 
image"
the preparation of the thing to be encrypted.

Crypto and Security needs the eyes of everyone to be effective. This should be 
an
ongoing effort with EVERYONE's input. Again, I commit on a seperate track for
public review and comment and involvement.

Also, there has been NO change to any session items. Could you please point out
where that/these changes have occured?


Miles Lott (address@hidden) wrote*:
>
>Please do not commit any more changes to the crypto or
>sessions classes.  Submit patches to one of the project
>admins.  Jengo most certainly needs to be involved in this.
>
>Del wrote:
>>
>> Tony (Angles) Puglisi wrote:
>> >
>> > Del,
>> > Again, hack at it and sent me the file(s) (as attachments to an email). My
brain is
>> > too simple for these modern things, but I do know that I can commit a file 
>> > :)
>>
>> OK, will do.  Not tonight, I've been driving for 10+ hours and my brain is 
>> fried.
>>
>> One question before I start:  Do I have permission to change the underlying
encryption
>> type for mcrypt 2.4 from 3DES (triple DES) to Rijndael?
>>
>> This will break pre-stored encrypted passwords, but provide an order of 
>> magnitude
>> performance and security benefit.  My understanding is that pre-stored 
>> encrypted
>> passwords are broken at the moment anyway.
>>
>> Any objections from the other developers?
>>
>> (trust me, I'm a cryptogeek:  DES should have gone into the dustbin of 
>> history
>> ages ago, and 3DES with it).
>>
>> > ahh.. as far as email goes, we only need to do crypto on a string, and a 
>> > short
>> > string at that, the pasword. Therefor to program for encrypting objects is 
>> > over
>> > kill for us but, hey, while we are at it why not do that...
>>
>> I agree, it's an easy operation to do it so we should do it.  It's no major
>> discomfort.  Note that you should always treat a string as an object anyway
>> (and therefore serialize it before encrypting) because of limitations in the
>> mcrypt functions.
>>
>> > As for database "de-fanging" (eliminitating database unfriendly chars and 
>> > char
>> > sequences), I believe this should be handled at the SO level, as an 
>> > example,
the
>> > preferences class that handles the storage and retrieval of email prefs 
>> > from
the
>> > preferences table, has code in there to handle adding slashes, and
serialization.
>> > (I don't know how other apps handle their prefs)
>>
>> OK, BUT:
>>
>> -  The mcrypt functions will ONLY handle an object / string that has ALREADY 
>> been
>>    de-fanged.  It will ALWAYS return a string (in fact a binhex'ed string) 
>> that
>>    has been de-fanged, or in any case does not need de-fanging.
>>
>> -  Since crypto will always return a de-fanged string when mcrypt is 
>> enabled, why
>>    not have it also always return a de-fanged string when mcrypt is disabled?
>>
>> I agree that the encrypt & de-fang operations are logically orthogonal, 
>> however
in
>> this case there is some benefit to having them combined due to the reliance 
>> of
one
>> upon the other.
>>
>> --
>> Del
>>
>> _______________________________________________
>> Phpgroupware-developers mailing list
>> address@hidden
>> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>
>--
>
>Miles Lott - http://milosch.net
>phpGroupWare - http://www.phpgroupware.org
>
>_______________________________________________
>Phpgroupware-developers mailing list
>address@hidden
>
--
that's "angle" as in geometry