________________________________
From: Paul Gilmartin <paulgboul...@aim.com>
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, 2 September 2013, 22:09
Subject: Re: RACF Database protection
>>The password phrase hash can be split into blocks of 8 bytes, and each of
>>them "cracked" independently, also in parallel.
>>
>Sounds like a half-hearted implementation -- what would have been the
>additional cost of using larger blocks?
Not possible directly with DES, but there are many other alternatives which
would be quite secure at no additional cost. I have no idea why the password
phrase is encrypted in this way, considering the available modern technology
already employed by RACF.
>>Another flaw, concerning the hash storage, allows for collisions in the last
>>block,
>>if the phrase length is not exactly multiple of 8.
>>
>The obvious question, then, is would the method be improved simply by padding
>that last block (with blanks, e.g.; or better characters invalid in the
>passphrase)
>to a multiple of 8. Does the passphrase syntax permit trailing blanks so that
>passphrases differing only in the number of trailing blanks are considered
>different?
The phrase clear text is already padded with spaces to a multiple of 8, but,
after encryption, the resulting hash is truncated to the length of the original
clear text, minus the padding. This leaves us with an incomplete DES cipher
text block at the end, if the last clear-text block was padded. This means
that, if for example the last block had one character (say 1=F1) padded to a
length of 8 with spaces (F14040.....), only the first byte of the resulting DES
cipher text will be stored. There are many clear-texts what will generate the
same byte on the first position when encrypted with DES. Example: create user
COSTIN with phrase Abcd1234Abcd1234a, then try to logon with phrase
Abcd1234Abcd1234X
>Does the method still operate by storing the user ID encrypted by the (chunks
>of)
>the passphrase? Is any weakness introduced by the 7-character (practical)
>limitation of user IDs?
Pretty much the same, with some obfuscation.
Costin
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
