Hello!
I find this to be a good aproach but i'd like to make some suggestions. I
think the system is different weather you want to authenticate 1 or more
users, and if you want them to have different passwords. I would do the
following:
Point 1: Use a symmetric cypher (xor :-) ) to encrypt data. It's a good idea
to use block chaining here to make it more secure. I'll explain myself:
imagine you have 3 blocks of plaintext: a b c and f(x) is the symmetric
cipher; A B C is the result encrypted text. IV (initialization vector) which
length is the same as the block. This value is updated every iteration of
the algorithm as shown below but it must be reset to a know value ititialy
(for instance IV(0) = vector of 0). Asumme that fe is the encription
function and fd the decription function (note that in symmetric cipher you
need a = fd ( fe (a) ) that doesn't necessarily mean that fd = fe; if you
use XOR then they are equal though :-) ). Then:
To encrypt:
Iteration 1:
A = fe (XOR (a, IV(0));
IV(1) = A
Iteration 2:
B = fe (XOR (b, IV(1));
IV(2) = B
Iteration 3:
C = fe (XOR (c, IV(2));
IV(3) = C
To decrypt:
Iteration 1:
a = XOR (fd (A), IV(0))
IV(1) = A
Iteration 2:
b = XOR (fd (B), IV(1))
IV(2) = B
Iteration 3:
c = XOR (fd (C), IV(2))
IV(3) = C
That's called chaining block cipher. You'll say: why is it used? This way is
like the key changed every block, so you can't just try to brute force
attack in the middel of the message to find a HTML tag for instance; you can
only brute attack on the first block (well, sort of) :-)
Point 2: I'd prompt from a password, then hash it to obtain the key to
decrypt. But what to do if i want usernames and passwords? Go to point 3 :-)
Point 3: I'd compute some data in a way that i could do the following. Ask
for a username and password, i'd hash the username, the password and a value
computed in a way that hashing everything led to the same decryption
password used in Point 1. This values could be simply included as
usernames/values pairs in the same pages or in an attached javascript (just
to make everything run faster).
Point 4: I'd use 1 to decrypt javasacript routines as you said, could be
ok... I wouldn't check for correctness of the password, only try to decrypt
with the key i obtain. If you check against anything it's very easy to break
this step.
Regards,
Josep
P.S.:
By the way, let me explain these emails things :-)
Signature: A hash of the message is computed and the it's encrypted with the
PRIVATE key of the sender.
Verification: The same hash is computed, then the signature is decrypted
with the PUBLIC key of the sender and hashes are compared.
Encryption: A random symmetric key is generated, then the message is
encrypted and then the key is encrypted using the PUBLIC key of the
receiver.
Decryption: The symmetric key is decrypted with the PRIVATE key of the
receiver and then the message is decrypted.
Asymmetric encryption & decryption is not used for large amounts of data
because it's very slow.
You can also Sign&Encrypt (which is a combination). You can encrypt for more
than 1 user: you encrypt with a symmetric key and then strore a encryption
of this symmetric keys for each of the receivers public keys, and a lot of
things!
hehe... that's all folks. See you
----- Original Message -----
From: "Byrne, Gerald (euler:eti)" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, November 30, 2001 10:50 AM
Subject: RE: Re[2]: [Dynapi-Help] theoretical javascript question
I think this could work:
- All javascript would be held in an encrypted strings. This encryption
will have taken place on the server.
- The password would evaluate to the Private Key.
- If the correct password is entered, the javascript is decrypted and
exectuated using eval().
- If the incorrect password is entered, then the javascript cannot be
decrypted and the user has no access to the system.
> -----Original Message-----
> From: Darío Vasconcelos [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, November 29, 2001 10:58 PM
> To: Dynapi-Help
> Subject: Re[2]: [Dynapi-Help] theoretical javascript question
>
> Josh,
>
> I absolutely agree with you. But there's one case where you would want
> to encrypt the e-mail with your private key: whenever you want to
> "sign" your message, that is, when you want the receiver to
> acknowledge that you're the one that sent the e-mail, since nobody
> else in the world has your private key but you.
>
> Actually, I've heard that a double-encryption scheme can be used in
> this cases: I can encrypt my text with my private key and then encrypt
> it again using your public key. That way, the only one that could read
> the message would be you and the only one that could have composed it
> would be me (you would decrypt the text first with your private key
> and then with my public key).
> But this last paragraph wasn't interesting to the discussion. Please
> ignore it :-)
>
> BTW, I visited the URL that James Sloey posted and I must say that it
> is very impressive. I guess the secret is that the scheme is
> simmetrical, as opposed to RSA, and the password is never included in
> the message. But i still can't imagine how to adapt this to
> authorization/authentication.
>
> Regards,
>
> Dario
>
> JC> I don't mean to be harsh, but did you read the link that you gave
> JC> (http://www.orst.edu/dept/honors/makmur/ ) or were you just feeling
> lucky
> JC> with google? I don't profess to be a RSA encryption expert by any
> means,
> JC> but it's quite clear that you encrypt using a known public key, and
> decrypt
> JC> using the cipher's private key. This is one of the fundamentals of
> JC> key-based encryption/decryption. Please keep reading if this isn't
> quite
> JC> clear.
> JC> Here's a encryption/decryption scenario of users sending emails, as I
> JC> understand it:
> JC> 1) You send an encrypted email to me by using my public key. You also
> JC> include your public key for me to encrypt the message when I reply
> back to
> JC> you.
> JC> 2) I receive the message. Noone along the way is able to decipher the
> JC> message unless they have my private key. When I want to view the
> message, I
> JC> use my private key to decrypt it.
> JC> 3) When I reply back to you, my mail program encrypts the message
> using your
> JC> public key provided on your original message.
> JC> 4) You receive the email message. Noone along the way is able to
> decipher
> JC> the message unless they have your private key. When you want to view
> my
> JC> reply, you use your private key to decrypt it.
> JC> 5) and on and on.
>
> JC> Now this is the idea as I understand it. If I'm way off base, someone
> please
> JC> set me straight ;)
> JC> To relate this idea to using javascript for encryption/decryption,
> let's
> JC> take a look at a scenario of client-side password validation as Jonah
> had
> JC> originally specified. Let's make the example simple and say we have a
> JC> variable defined in javascript (var passwd = "fdjX3!bc@") that
> represents an
> JC> encrypted password. The user will be presented a form in which to
> enter a
> JC> password. The javascript password variable will then be decrypted and
> JC> compared to the password the user entered. In order for this
> decryption to
> JC> occur, the javascript will need the private key that they password was
> JC> originally generated with. Hence, the client will need access to the
> JC> private key, which indeed makes the key a PRIVATE KEY THAT IS PUBLIC.
> JC> Obviously, this is not good. Like I mentioned, there may be
> workarounds for
> JC> this. But to have a pure client-side validation technique I think
> would be
> JC> difficult to do. By all means, I hope this is wrong, because it would
> be
> JC> very cool to see encryption/decryption done "securely" with
> javascript.
>
> JC> --JC
>
> JC> ----- Original Message -----
> JC> From: "Doug Melvin" <[EMAIL PROTECTED]>
> JC> To: "Josh Chu" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
> JC> "Dynapi-Help" <[EMAIL PROTECTED]>
> JC> Sent: Thursday, November 29, 2001 4:02 PM
> JC> Subject: Re: [Dynapi-Help] theoretical javascript question
>
>
> >> uh, private key? the private key is PRIVATE..
> >> you use the public key to decrypt.
> >>
> >> Simply put, aside from SSH and SSL, I don't believe you will find a
> better
> >> solution.
> >> Sorry.
> >> That is just _my_ opinion tho.
> >> :-)
> >> ----- Original Message -----
> >> From: "Josh Chu" <[EMAIL PROTECTED]>
> >> To: "Doug Melvin" <[EMAIL PROTECTED]>;
> >> <[EMAIL PROTECTED]>; "Dynapi-Help"
> >> <[EMAIL PROTECTED]>
> >> Sent: Thursday, November 29, 2001 4:58 PM
> >> Subject: Re: [Dynapi-Help] theoretical javascript question
> >>
> >>
> >> > Again the problem , especially with using key-based encryption
> JC> algorithms
> >> > like RSA, is that you have to have the public and private keys in
> order
> JC> to
> >> > perform the encryption/decryption. Encryption isn't the problem,
> since
> >> you
> >> > can encrypt the password or field just using the public keys. The
> JC> problem
> >> > lies when you need to decrypt the cipher, which requires using a
> private
> >> > key, which is really hard to make private if you have a .js file out
> on
> >> the
> >> > web that contains this key. To make this more clear, if you have a
> >> > javascript program that is running on a users browser, then to
> decrypt a
> >> > cipher, that program will have to read the private key from somewhere
> on
> >> the
> >> > web. Hence, anyone who can run this javascript can also do view the
> >> > private key necessary to decrypt the cipher. Obviously this is not
> very
> >> > secure. I guess one workaround for this would be to store the private
> JC> key
> >> on
> >> > the client (via a cookie -- document.cookie manipulation) and always
> >> decrypt
> >> > using the private key stored on the client. I've never attempted
> this
> >> > however, so if you can get a prototype working, that would be very
> >> > interesting.
> >> > --JC
> >> >
> >> >
> >> > ----- Original Message -----
> >> > From: "Doug Melvin" <[EMAIL PROTECTED]>
> >> > To: <[EMAIL PROTECTED]>; "Dynapi-Help"
> >> > <[EMAIL PROTECTED]>
> >> > Sent: Thursday, November 29, 2001 3:07 PM
> >> > Subject: Re: [Dynapi-Help] theoretical javascript question
> >> >
> >> >
> >> > > two words:
> >> > > RSA encription.
> >> > > http://www.orst.edu/dept/honors/makmur/
> >> > >
> >> > > ----- Original Message -----
> >> > > From: "Jonah" <[EMAIL PROTECTED]>
> >> > > To: "Dynapi-Help" <[EMAIL PROTECTED]>
> >> > > Sent: Thursday, November 29, 2001 2:31 PM
> >> > > Subject: [Dynapi-Help] theoretical javascript question
> >> > >
> >> > >
> >> > > > Would it be possible, in theory, to securely validate a password
> >> client
> >> > > > side?
> >> > > >
> >> > > > Obviously, simple string matching would not work because the
> client
> >> > could
> >> > > > view the source to find the correct password.
> >> > > >
> >> > > > But I have this vague notion (my upper level math skills are very
> >> > rusty):
> >> > > >
> >> > > > Parsing the password up into characters perhaps, converting the
> JC> chars
> >> > > > to numbers, and then passing the numbers into the variables of a
> set
> >> > > > of non-linear equations that must be solved simulataneously (in
> >> > > javascript,
> >> > > > a set of functions that must return true simultaneously). I have
> no
> >> > idea
> >> > > > how you could generate the necessary difficult-to-solve set of
> >> equations
> >> > > > given a particular password, but am curious to know if such an
> >> approach
> >> > > > is viable even in theory. Anyone have any ideas?
> >> > > >
> >> > > > Thanks,
> >> > > > Jonah
> >> > > >
> >> > > >
> >> > > > _______________________________________________
> >> > > > Dynapi-Help mailing list
> >> > > > [EMAIL PROTECTED]
> >> > > > https://lists.sourceforge.net/lists/listinfo/dynapi-help
> >> > >
> >> > >
> >> > > _______________________________________________
> >> > > Dynapi-Help mailing list
> >> > > [EMAIL PROTECTED]
> >> > > https://lists.sourceforge.net/lists/listinfo/dynapi-help
> >> > >
> >>
> >>
>
> JC> _______________________________________________
> JC> Dynapi-Help mailing list
> JC> [EMAIL PROTECTED]
> JC> https://lists.sourceforge.net/lists/listinfo/dynapi-help
>
>
>
> --
> Best regards,
> Darío mailto:[EMAIL PROTECTED]
>
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> _______________________________________________
> Dynapi-Help mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dynapi-help
_______________________________________________
Dynapi-Help mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dynapi-help
_______________________________________________
Dynapi-Help mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dynapi-help
