Re: string literals passwords in run only applications
Re: string literals passwords in run only applications
- Subject: Re: string literals passwords in run only applications
- From: email@hidden
- Date: Wed, 27 Feb 2002 00:18:19 -0500
On Feb 26, 2002 at 12:05 AM,
Jon Pugh <email@hidden> suggested,
At 10:20 PM -0500 2/25/02, email@hidden wrote:
>
set l to {}
>
repeat with N from 1 to 100
>
encrypt the text "ABC" with password N
>
set end of l to result
>
end repeat
>
l
>
Small passwords and text runs are hard to encrypt. Try this:
>
>
set l to {}
>
repeat with N from 1 to 32565 by 256 * 32 -- too lazy to compute it
>
encrypt the text "now is the time for all good weasels to come to >
the
>
aid of marketing" with password N
>
set end of l to result
>
end repeat
>
l
>
>
It produces:
>
>
{
>
>
"~q&e%qkf2f}ya$w~t&m`i%dl}v4caebtju,xj%`lw4`k$eyc&mea%le2ufoaexha",
>
"vir#av3`{w gis$~iw#ii4t}ow6ssekcip(q|4p}mv6py$ln`#ilw4|t >
~wv}alokd",
>
>
"gb3|3fhp2azy`$nka2mq~6rlza4kawwh~u=wy&`}h}<`y\"ykc0bzb%}r8cuuimwx~r",
>
"|cr#|s3for2a|gp%jsq2aa~5p|zb*c`uop~s->
wz'p}kr4`{.ake8b{c=}s7guteqw{vb"
>
}
>
>
Much more robust, and it's still using lame passwords. Longer passwords >
help.
I three bad things about Akua Sweet's 'encrypt' command. The first isn't to bad
from a security point of view, but it does reduce flexibility: the encryption is
a stream cipher, since changing a single character of the plain text only
changes a single character of the cyphertext. That is, even with a very strong
password (created by combining a Perl script, an APL program, and a nap on the
keyboard ;-) ) you get the following mapping of plaintext to cyphertext:
ABCDEF --> PGR[Y
BBCDEF --> SGR[Y
CBCDEF --> RGR[Y
Also (and this is bad), it seems to remap characters only within a block. Hex
characters 0x20 to 0x3F (space, numbers, and shifted numbers) map only amongst
themselves, 0x40 to 0x5F (@, uppercase letters, and [\]^_) map only amongst
themselves, and so on. This is similar to how the Japanese "Purple" cipher
worked, scrambling consonants with one table and vowels with another. Here, its
a real weakness, since if you see "Q" you know the text has an uppercase letter
(or one of [\]^_).
But worst of all, for my suggestion that we could use 'encrypt' to create a hash
function, 'encrypt' doesn't make use of all characters of the password.
Passwords "12345", "12346", and "12347" all encrypt "ABCDEF" to "PBVWPJ". To
get all the characters of the password to play, you need a much longer
plaintext. (It seems like three times the length of the password is needed.)
It seems like the algorithm shuffles the characters of the password in different
orders and then uses each password character to control the substitution of one
plaintext character. That is, the password "ABCDEF" is converted to the stream
below and matched with each character of plaintext
ABCDEF becomes (with spacing for clarity only),
ABCDEF ABCDEF ABCDEF ABCDEF ABCDEF which is shuffled to
ABCDEC CEFDAC FFBBBC EAEDEB FFADDA which then combines with the
plaintext
ABCDEC CEFADC FFBBBC EAEDEB FFADDA
PLAINT EXTPLA INTEXT PLAINT ...
| |
V V
Q Q
(pointing out that each time "A" in the password stream matches "P" in the
plaintext, you get "Q").
I think in my copious free time, I'll write an osax that provides encryption
using the system's services. I should be able to knock that off sometime before
OS 11 is released.
--
Scott Norton Phone: +1-703-299-1656
DTI Associates, Inc. Fax: +1-703-706-0476
2920 South Glebe Road Internet: email@hidden
Arlington, VA 22206-2768 or email@hidden
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.