Re: Hashing methods for giant keys

From: AE (hidden@nospam.com)
Date: 03/28/03 

From: AE <hidden@nospam.com>
Date: Fri, 28 Mar 2003 20:04:16 +0100

lurker wrote:
> On Tue, 25 Mar 2003 20:09:10 +0100, AE <hidden@nospam.com> wrote:
>
>
>
>>Nevertheless you are considering to XOR the key either with the
>>passphrase or with an unsalted hash - why not use one of the usual
>>key-wrap algorithms? There are several around - from the key-wrap for
>>rc2 and 3des to the AES key-wrap and with proper password-handliung each
>>of them gives an attacker a much harder time than what you are planning.
>>
>
> I am currently developing this algorithm for an automated email
> client. Since there is a different session key for every message I
> have implemented a couple extra fields to help with key maintenance.
>
> Rather than use an existing key-wrap routine to validate the key I am
> simply encrypting the email user ID from the mime header along with a
> time/date field. This allows grooming the key file by user id and
> date and also keeps the session keys recieved from one user seperate
> from keys received by another user.
>
> I am storing the actual key in another field of the same record. The
> key search itself is very fast since it typically rejects a session
> key within the first several characters of the UserId validation.
>
> I am concerned about hashing speed since most of the processing time
> in the session key search will be spent unlocking each of the 80
> character keys so that the key composite can be used to decrypt the
> verifying fields.
>
> Simply XORing each character of the password with a different
> character of the key and repeating where necessary should be adequate
> since there would be no collisions for the length of the password. I
> think Microsoft uses this method.

I fear I don't get it - not at all: The session-key of an email only
encrypts the textbody, not the mailheaders or it would be impossible to
deliver the mail.

In case your program encrypts the mail headers you could/should use a -
possibly encrypted - table with the fields you want to browse (usually
name, data&time, subject, priority and flags for "new" and "unread") and
with pointers to the individual mails and maybe with the various keys.

The table contains important information and deserves to be encrypted
with AES.

To speed up the system you could/should invest some time in fast
algorithms to search within the tables, but not in faster and at the
same time less secure algorithms.

>>>This is a pretty simple cipher. The cipher text is twice the length
>>>of the plain text so it is easy to refresh the session keys between
>>>messages.
>>>...
>>
>>Twice the length of plaintext doesn't sound that good to me - why should
>>I want to do this? And what does it have to do with "refresh the session
>>key" (whatever this means)?
>>
>
> This is a composite key cipher capable of encrypting any data up to
> 256 bit characters.
>
> For simplicity the cipher encrypts one byte at a time. The ciphertext
> has to use two bytes of ciphertext to encrypt one byte of data. The
> second byte holds a composite key that is loaded into a simple array.
>
> One random element is added to the composite key as another random
> element is removed (the first and the last) so only the net change of
> the cipher text character can be determined.
>
> The array rolls along till the end of the message and the last
> composite key protecting the last character of the message signature
> is stored as a new session key for the current user.
>
> The system is a lot faster than pgp and reduces battery consumption on
> my Windows CE device by a factor of 10. Although the system has other
> advantages the savings in power consumption was the primary motivation
> for writing the algorithm.

That's not a good comparison between your obviously symmetric algorithm
and a public-key cryptosystem. Is your system as well that much
faster/less power-consuming than pure AES?

AE

Relevant Pages

  • Re: Hashing methods for giant keys
    ... Since there is a different session key for every message I ... Simply XORing each character of the password with a different ... The cipher text is twice the length ... second byte holds a composite key that is loaded into a simple array. ...
    (sci.crypt)
  • Re: Hashing methods for giant keys
    ... Since there is a different session key for every message I ... >character keys so that the key composite can be used to decrypt the ... >For simplicity the cipher encrypts one byte at a time. ... >second byte holds a composite key that is loaded into a simple array. ...
    (sci.crypt)
  • Re: Hashing methods for giant keys
    ... Since there is a different session key for every message I ... >encrypts the textbody, not the mailheaders or it would be impossible to ... Good automated email encryption systems require that each different ... >> for writing the algorithm. ...
    (sci.crypt)
  • Re: Password Strength II
    ... encrypted in two separate 7 character groupings. ... > Where did you get that NT4 only encrypts the first eight characters? ...
    (Security-Basics)
  • RE: One Character at a time not fast enough
    ... "thejamie" wrote: ... of many) and it decrypts (and encrypts) characters one at a time. ... I'm using DES encrypted files whose content is the information ... encrypted/decrypted one character at a time. ...
    (microsoft.public.vsnet.general)
Quantcast