I'm no expert, but isn't a hash supposed to be irreversible? But, like I
said, I''m not busy encrypting things to reverse them, just to check data.
So MD5(source+key) should do it. If the key would always we the same, than I
wouldn't even need to add a key, since MD5 is irreversible (right?). Anyway,
my problem is solved. Offcourse you can argue more about encryption if you
like....

Maarten


On 19/05/06, Charles Yeomans <[EMAIL PROTECTED]> wrote:


On May 19, 2006, at 2:31 PM, Mark Nutter wrote:

>
>
> --- Charles Yeomans <[EMAIL PROTECTED]> wrote:
>
>>
>> On May 19, 2006, at 1:08 PM, Phil M wrote:
>>
>>> Since you don't need a decrypt, you can use a simple hash
>> method.
>>>
>>> Easiest would be an MD5 since it is built into REALbasic, and
>> it
>>> would work something like this:
>>>
>>>     hash = Md5(secret_phrase + user_password + user_id)
>>>
>>> adding the user_id in there means that even if two users have
>>> exactly the same password, they would not have the same
>> password hash.
>>
>> Using MD5 like this to make a stream cipher does require a bit
>> more
>> care.  If you encrypt two strings with the same key, then an
>> attacker
>> can XOR the encrypted strings and get the XOR of the two
>> unencrypted
>> strings.  With a bit of text guessing, it may then be possible
>> to
>> recover the original text.
>
> He's not making a stream cipher, though.  Just the one-way hash.
>
> You've got me thinking, though. What about something like
>
> Dim result, chars() As String
> Dim i, c As Integer
> Dim m As new MD5Digest
> m.Process secretPhrase
> chars = Split(plainText, "")
> c = UBound(chars)
> for i = c DownTo 0
>   result = result + chr(Bitwise.BitXor(chars(c - i),
> asc(m.Value.Mid(i mod 16))))
>   m.Process result
> next
>
> I know enough about cryptography to know that sometimes making
> your cipher more complicated only makes it easier to break.  I
> would think that processing the characters incrementally, and
> re-calculating the MD5 digest at each step, ought to at least
> avoid the Xor problem.

It won't.

>
> How about it cryptographers?  Is this reasonably secure, or just
> an exercise in security by obscurity?

The solution is not hard.  Each time you generate a stream for
encryption, it needs to be different.  This is true for any stream
cipher.  What you do is change the key each time, usually by adding
some random data.  Then you need to some way to remember the data...


Charles Yeomans
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Reply via email to