Re: XOR javascript implementation
Dr Moria
"mistral" <poly...@softhome.net> wrote in message
news:1158101174.6...@e3g2000cwe.googlegroups.com...
> Does someone know good XOR javascript implementation, which provides
> back a readable string without any special chars, that often result in
> unusable and simpy undecodable strings. I want use XOR to encrypt
> javascripts in html page, and decrypt function need decrypt script to
> make it executed in browser.
>
> regards.
>
xor is a binary function, you would have to have special cases to handle the
special characters.
What you going to xor it with in the first place, and where are the byte
boundries?
mistral
Dr Moria писал(а):
> "mistral" <poly...@softhome.net> wrote in message
> news:1158101174.6...@e3g2000cwe.googlegroups.com...
Does someone know good XOR javascript implementation, which provides
back a readable string without any special chars, that often result in
unusable and simpy undecodable strings. I want use XOR to encrypt
javascripts in html page, and decrypt function need decrypt script to
make it executed in browser.
regards.
-------------------------------
> xor is a binary function, you would have to have special cases to handle the
> special characters.
> What you going to xor it with in the first place, and where are the byte
> boundries?
-----------------
the application is obfuscate javascript in html page. Separate XOR
encoder will encode javascript, then i'll copy encoded script in html
page, the page need have javascript decoder function inside head
tags(prefixed ), which will decode script to make it recognizable by
browser, browser will execute script. The issue is that XOR could
produce characters not recognised by the web page encoding (e.g.
control characters in the 0x80 to 0x9F range). So i need encoder that
will take into account this issue and produce only characters which is
recognisable by the web page encoding.
regards
rossum
wrote:
>Does someone know good XOR javascript implementation, which provides
>back a readable string without any special chars, that often result in
>unusable and simpy undecodable strings. I want use XOR to encrypt
>javascripts in html page, and decrypt function need decrypt script to
>make it executed in browser.
>
>regards.
One alternative is simply to accept that special characters will
appear in your cyphertext and transmit the cyphertext in Base-64, hex
or whatever. This will increase the size of your cyphertext and
require conversion back to bytes before decrypting.
Apart from that, there is a way to produce a cyphertext string without
special characters, though I would not normally use XOR if that is a
design goal. Using XOR means you will have to pick a number of
characters that is an exact power of two: 64, 128 or 256 characters,
so every possible bit pattern has a representation in the character
set. For a number of characters that is not an exact power of two it
is easier to use modular addition to encode and subtraction to decode.
Google "Vigenere" for more details.
This sort of thing is easy enough to write for yourself:
1 Decide on the alphabet of characters you want and assign each
character a code number in the range 0...n-1. Special characters are
not included in the alphabet.
2 Set up a PRNG to generate a series of numbers in the range 0...n-1
from a given key.
3 To encrypt generate a PR number for each plaintext character and add
it to the code number of the character modulo n.
4 To decrypt generate the same PR number for each cyphertext character
and subtract it from the code number of the cyphertext character
modulo n.
An example of the add/subtract version.
Alphabet a = 0, ... z = 25.
To encypher:
Plaintext: helloworld
Plaintext numbers: 7 4 11 11 14 22 14 17 11 3
PRNG numbers: 16 6 18 3 1 9 9 13 5 14
Add mod 26: 23 10 3 14 15 5 23 4 16 17
Cyphertext: xkdopfxeqr
The cyphertext can only contain characters from the chosen alphabet
since every number from 0 to n-1 is represented in the alphabet and
the result of the modular addition must be in the range 0 to n-1.
To decypher:
Cyphertext: xkdopfxeqr
Cyphertext numbers: 23 10 3 14 15 5 23 4 16 17
PRNG numbers: 16 6 18 3 1 9 9 13 5 14
Subtract mod 26: 7 4 11 11 14 22 14 17 11 3
Plaintext: helloworld
rossum
mistral
rossum писал(а):
> On 12 Sep 2006 15:46:14 -0700, "mistral" <poly...@softhome.net>
> wrote:
Does someone know good XOR javascript implementation, which provides
back a readable string without any special chars, that often result in
unusable and simpy undecodable strings. I want use XOR to encrypt
javascripts in html page, and decrypt function need decrypt script to
make it executed in browser.
regards.
---------------
> rossum
---------------------
well, i am no crypto expert. Yes, probably there is no necessity to
stick to XOR algorithm, it can be any comfortable algorithm which
provides easy encoding of javascript, and provides back a readable
string without any special chars, i.e. without an unusable and simpy
undecodable strings(browser compatible). Encoder need be in sepapate
page. Html page need have a decoding function inside head tags, and
automatically decode strings. I did a google search for such simple
script cryptor ("Vigenere" based), but without sucess..
Mistral
Douglas...@gmail.com
> mistral wrote:
>
> > Does someone know good XOR javascript implementation, which provides
> > back a readable string without any special chars, that often result in
> > unusable and simpy undecodable strings. I want use XOR to encrypt
> > javascripts in html page, and decrypt function need decrypt script to
> > make it executed in browser.
http://guymal.com/mycode/xor_js_encryption/
> And what exactly should this nonsense be good for?
It might not actually be completely pointless to distribute your
webpage in an encrypted form, with a javascript to let the viewer
decrypt them if they know the key.
When you think about it, it saves the hassel of distributing the
webpage in an encrypted form and expecting the end user to have some
magical encryption software to make it view it. The data is packaged up
neatly with the encryption algorithm all in one lump.
ciao,
D.
Jean-Luc Cooke
> It might not actually be completely pointless to distribute your
> webpage in an encrypted form, with a javascript to let the viewer
> decrypt them if they know the key.
Yes, but ... xor isn't good. AES should be used. And you can do it in
JS if you're cleaver. Also, this may only be of limited interest, since
a simple:
document.write( decryptCode() ); woudl reveal the JS source.
JLC
--
linderd
Basically, I agree. I was just saying it wasn't completely pointless...
However, if you're at a loose end, this guy seems to have a bit to say
on the subject:
http://www.fourmilab.ch/javascrypt/
ciao,
D.
Jean-Luc Cooke
> which encryption method provides most compact code? And encryption must
> use only browser supported strings, without special symbols not
> recognizable by web browser.
RC6 is pretty small, but AES would only be slightly larger.
Any algorithm can be used to operate on
Strings in any language that can convert them to bytes. javascript is
just such a language.
JLC
--
Tom St Denis
> I there any sample of RC6 javascript implementation? However, if it
> will be more compact, than base64, otherwise base64 is preferable.
And this children, is why amateurs who can't even handle BASIC
programming tasks shouldn't write security applications.
SHAZAM!
Tom
rossum
wrote:
>which encryption method provides most compact code? And encryption must
>use only browser supported strings, without special symbols not
>recognizable by web browser.
You need to think about you requirements. For the "most compact code"
RC4 is a good candidate - compact and easy to program. However is is
only secure enough to stop Aunt Edna looking at your source code;
against anyone with reasonable knowledge or resources RC4 is not
secure.
Most cyphers will not give you "only browser supported strings,
without special symbols." For that you need some sort of additive
Vigenere cypher as I suggested earlier. Alternatively you need to add
translation into and out of Base-64, yEnc or whatever. A modified
version of yEnc (http://www.yenc.org/) would probably give you less
cyphertext expansion than Base-64. Against that a Javascript Base-64
implementation is probably available off the shelf while I doubt that
yEnc is similarly available being newer.
You have three requirements:
- security
- compact code
- no special characters
You need to think about what order of priority these three have and
the interactions between them.
What level of security do you want? Do you want to stop Aunt Edna
reading your HTML source or do you want to stop Nasty Megacorp Inc
reverse engineering your HTML? NMI will be able to throw a lot more
resources at breaking the cypher than Aunt Edna. If you only want to
stop Aunt Edna then do you need to encrypt at all? Base-64 or yEnc
may stop Aunt Edna just as well as full encryption.
How important is compact code? Good security can be complex so
shorter code is likely to be less secure, as with RC4.
Special characters can be an add-on like yEnc or Base-64 which will
expand both the Javascript code and the cyphertext. If you want no
special characters built into your cypher then you are pretty much
forced to use Vigenere which will reduce your security level.
There is no perfect solution to your problem. You are going to have
to balance your requirements, and only you can do that.
rossum
mistral
rossum писал(а):
--------------
Mostly for encoding of javascript code. Need be only secure enough to
protect from Aunt Edna looking at source code and stop robots that try
research scripts. Nasty Megacorp Inc or reverse engineers is not
important, so no extra security required. And yes, encryption may not
required at all, encoding only. I use Base-64, but want to try other
encoding methods as well, probably simple encryption. I dont know yEnc
javascript implementaion. What is important that encryption provide
compact enough size(page need load fast) and must provide character
strings that fully recognized by browser. Otherwise javascript may not
work correctly.
mistral
rossum
wrote:
>Mostly for encoding of javascript code. Need be only secure enough to
>protect from Aunt Edna looking at source code and stop robots that try
>research scripts. Nasty Megacorp Inc or reverse engineers is not
>important, so no extra security required. And yes, encryption may not
>required at all, encoding only. I use Base-64, but want to try other
>encoding methods as well, probably simple encryption. I dont know yEnc
>javascript implementaion. What is important that encryption provide
>compact enough size(page need load fast) and must provide character
>strings that fully recognized by browser. Otherwise javascript may not
>work correctly.
>
>
>mistral
Sounds like Base-64 would solve your problem. It will be more
difficult to amend yEnc to avoid special characters as you would not
be able to use an off-the-shelf implementation.
rossum
rossum
wrote:
>
>rossum ?????(?):
>-------------
>
>what is correct inplementation of Base64 decoding function in
>javascript?
>
>mistral
Learn to use Google. Base-64 is described in many places on the web,
I got over 100,000 hits on Google. The formal definition is in RFC
3548: http://www.rfc-archive.org/getrfc.php?rfc=3548
rossum
Rob Warnock
+---------------
| >
| >what is correct inplementation of Base64 decoding function in javascript?
|
| I got over 100,000 hits on Google. The formal definition is in RFC
| 3548: http://www.rfc-archive.org/getrfc.php?rfc=3548
Well, if he's going to use some insecure, quick&dirty hack
like that, he might as well use Base-85:
http://www.ietf.org/rfc/rfc1924.txt
http://en.wikipedia.org/wiki/Ascii85
http://www.morello.co.uk/binaryencoding.pdf
http://www.tug.org/tex-archive/tools/atob/btoa.c
since it's almost 7% more efficient in terms of bandwidth
[a 25% expansion versus Base-64's 33% expansion]. That is,
for each 12 bytes of binary input Base-64 outputs 16 bytes of
encoded printable text, while Base-85 outputs only 15 bytes
of encoded printable text.
-Rob
p.s. Several of the above references claim that Adobe invented
Base-85 for use in PDF, but to the best of my knowledge Base-85
was first promulgated by Paul Rutter & Joe Orost in the programs
"btoa.c" and "atob.c", somewhat before PDF appeared. And in fact
the "PostScript Language Reference Manual, 2nd Ed, Ch. 3.13.3"
<http://partners.adobe.com/public/developer/en/ps/psrefman.pdf>
references "btoa/atob":
The ASCII base-85 encoding is similar to one used by the
public domain utilities btoa and atob, which are widely
available on workstations. However, it is not exactly the
same; in particular, it omits the begin-data and end-data
marker lines, and it uses a different convention for marking
end-of-data.
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
rossum
>Well, if he's going to use some insecure, quick&dirty hack
>like that, he might as well use Base-85:
>
> http://www.ietf.org/rfc/rfc1924.txt
> http://en.wikipedia.org/wiki/Ascii85
> http://www.morello.co.uk/binaryencoding.pdf
> http://www.tug.org/tex-archive/tools/atob/btoa.c
>
>since it's almost 7% more efficient in terms of bandwidth
>[a 25% expansion versus Base-64's 33% expansion]. That is,
>for each 12 bytes of binary input Base-64 outputs 16 bytes of
>encoded printable text, while Base-85 outputs only 15 bytes
>of encoded printable text.
>
>
>-Rob
Since he wants the output not to interfere with HTML, Base-85 might
cause problems with characters like '&', '<' or '>' with special
meanings in HTML. A test would show if this was a problem.
rossum
rossum
wrote:
>yes I know, there is a plenty examples on the web, but most of them is
>show implementation for html forms, where a text is pasted/copied,
>whereas I need decoding javascript which just need be executed in
>browser.
As you may have reslised by now, we are not going to write Javascript
for you. If you cannot find what you want on the web then copy an
existing implementation and amend it to suit your purpose. If you
have problems try asking questions in alt.comp.lang.javascript or
comp.lang.javascript. Here on sci.crypt we are not necessarily
javascript experts; the people who know javascript are in the
javascript groups.
rossum
Rob Warnock
+---------------
| rp...@rpw3.org (Rob Warnock) wrote:
| >...he might as well use Base-85: ...
|
| Since he wants the output not to interfere with HTML, Base-85 might
| cause problems with characters like '&', '<' or '>' with special
| meanings in HTML. A test would show if this was a problem.
Aha! Somehow I overlooked that constraint. But not to worry,
no test is needed -- it's a non-problem, really. There are 94
printable ASCII characters. Base-85 needs only 85, so nine
need to be left out of the encoding anyway. Simply choose
'&', '<' and '>' as three of those omitted. Then omit both
single and double quote ('"' and '\''), so you can use Base-85
in quoted HTML/XML attribute values. Backquote ('\\') is another
frequent troublemaker, so omit it too. Since the conventional[1]
"<~" and "~>" won't work as end brackets[2], pick "{~" and "~}"
instead [three more chars], leaving the following 85 characters
available for the encoding [in increasing order of ASCII codepoints]:
!#$%()*+,-./0123456789:;=?@
ABCDEFGHIJKLMNOPQRSTUVWXYZ[]^_`
abcdefghijklmnopqrstuvwxyz|
Based on a quick look at the HTML4 spec, I see no problem with any
of those characters either in document text or in properly-quoted
attribute values.
Hmmm... This has been useful. I may want to start using Base-85
myself instead of Base-64 for some of the "hidden" session state
data in dynamically-generated HTML forms.
-Rob
[1] <http://en.wikipedia.org/wiki/Ascii85> says:
- Conventionally, the encoded data starts with "<~",
but this is not always the case.
- If a group contains only zero bytes, it is encoded as "z"
instead of "!!!!!".
Note that the tilde "~" is also convenient to use for the
compression-of-zeros role mentioned for "z", which is not
available given the above choice of encoding. This does not
introduce any ambiguity with its end-marker function, nor
with the detection and handling of final short groups.
[2] Note: Explicit end brackets are not required in quoted
HTML/XNL attribute values, but it's probably a good idea
to allow for them in the encoding anyway.
Paul Rubin
> need to be left out of the encoding anyway. Simply choose
> '&', '<' and '>' as three of those omitted. Then omit both
You can generally use '>' except inside a tag where the html parser
might think the tag is being closed. If you use < for '<' then the
parser won't think you're in a tag.
TC
mistral wrote:
> Sebastian Gottschalk wrote:
> > And well, this shows why it is completely pointless.
> Have you any constructive, positive ideas?
I do!
As far as your javascript is concerned, the world is divided into two
classes of people:
(1) Those who realize that if your javascript is encrypted, then, the
decryption process must be trivally available to the page itself; and,
(2) Those who do not realize that.
As for the folks in class (2), *any* encryption, no matter how simple,
will serve to hide your code. You might as well just ASCII-armour it
("61"=A, "62"=B and so on). Some of these folks will not even know how
to view your source of your pages, at all.
As for the folks in class (1), *no amount* of encryption will serve to
hide your code. These folks will instantly find your decoder, with
trival simplicity. It is irrelevant what cipher(s) you use. You could
use 50 different block, stream, symmetric & asymmetric ciphers, all
combined in a horrendously complicated way - and this makes *no
difference* to the trvial simplicity of finding & running your
decryptor.
So, 1% of effort will deter 99% of people. But *no amount* of extra
effort will deter the remaining 1%. So there is no point arguing the
fine details of what cipher to use, for this application, IMHO.
HTH,
TC (MVP MSAccess)
http://tc2.atspace.com
linderd
Exactly.
Idly though, what if the javascript application started out by
prompting the user for input, like those stupid websites that ask you
to enter your name, and then print "Hello [Name]" at the top of the
page? (and possibly stored that in a cookie so afterwards you didn't
have to re-enter it for every other page you viewed).
Then you arent distributing the key with the cipher-text.
Obviously not the stated objective, but probably actually possible (as
the stated objective is not).
ciao,
Doug.
Rob Warnock
+---------------
Yes, but... Using "<" for "<" blows up the encoded character
count, and makes Base-85 less advantageous over Base-64. In fact,
if one were to leave all of "&<>" *in* the encoding and then have
to replace them with "&<>", then assuming random binary
input data such a Base-85 encoding would be *worse* than MIME-standard
Base-64.
The encoding I suggested does not require any such escaping,
and thus preserves the ~7% advantage of Base-85 over Base-64.
-Rob
linderd
> rossum писал(а):
>
> > On 22 Sep 2006 07:53:40 -0700, "mistral" <poly...@softhome.net>
> > wrote:
> >
> > >
> > >rossum ?????(?):
>
> > >> On 22 Sep 2006 05:22:14 -0700, "mistral" <poly...@softhome.net>
> > >> wrote:
>
> > >Mostly for encoding of javascript code. Need be only secure enough to
> > >protect from Aunt Edna looking at source code and stop robots that try
> > >research scripts. Nasty Megacorp Inc or reverse engineers is not
> > >important, so no extra security required. And yes, encryption may not
> > >required at all, encoding only. I use Base-64, but want to try other
> > >encoding methods as well, probably simple encryption. I dont know yEnc
> > >javascript implementaion. What is important that encryption provide
> > >compact enough size(page need load fast) and must provide character
> > >strings that fully recognized by browser. Otherwise javascript may not
> > >work correctly.
>
> >mistral
>
> > difficult to amend yEnc to avoid special characters as you would not
> > be able to use an off-the-shelf implementation.
> >
> > rossum
> > >-------------
>
> what is correct inplementation of Base64 decoding function in
> javascript?
>
> mistral
>
> > Learn to use Google. Base-64 is described in many places on the web,
> > I got over 100,000 hits on Google. The formal definition is in RFC
> > 3548: http://www.rfc-archive.org/getrfc.php?rfc=3548
> >
> > rossum
> yes I know, there is a plenty examples on the web, but most of them is
> show implementation for html forms, where a text is pasted/copied,
> whereas I need decoding javascript which just need be executed in
> browser.
>
Do you understand what you are trying to do? Does anyone here
understand what you're trying to do?
Let's go back in time for a moment:
>From google groups:
From: mistral
Date: Wed, Sep 13 2006 6:33 pm
Email: "mistral" <polych...@softhome.net>
Groups: sci.crypt
<<<<< the application is obfuscate javascript in html page. >>>>>>
Emphasis mine.
So to summarize:
You want to have a webpage, with two sets of javascript: one, an
ENCRYPTED javascript, and two a PUBLIC javascript. When the page is
loaded, the browser will run the PUBLIC javascript which will then run
the ENCRYPTED javascript. However, some 15-yr-old-brat from the UK will
only be able to see an ENCRYPTED BLOCK in your webpage source, and not
be able to steal your SECRET javascript.
To conclude: it is not possible.
Javascript is parsed ONCE, when the page is loaded. Either your
javascript exists at that point, or it doesn't. If it does, its public,
can be executed and can be stolen. If it does not, it cannot be seen,
stolen by the browser, and also cannot be executed.
That is why you'll find a lot of examples where the page loads and a
little box of text is transformed into encrypted text and back into
normal text. And none which do what you describe.
That ASIDE (through some arcane means you might be able to actually get
it to work...) if we actually have a Stated Problem, we can begin to
look at it. Let's redefine the problem a bit:
1) You have this recipe for the Worlds Best Apple Pie.
2) You have this friend Mary who wants some pie.
3) You want to somehow give Mary the ability to make pie, but stop her
from taking the recipe and sharing it with all her friends.
At the moment what you plan to do is encrypt the recipe and send it to
Mary. When Mary gets it, she will decrypt it and use it. Unforuntately,
Mary doesnt know anything about encryption, so you send her a book on
it, and the key phrase youve used to encrypt it.
Mary unencrypts the recipe, makes some pie, eats it and shares the
recipe with all her friends just to annoy you for making her life hard
by encrypting it. In fact, she adds some oranges and sells the recipe
as the Worlds Best Apple and Orange Pie.
What you WANT to do, is send Mary an obufuscated recipe, where the
first instruction is to turn off the light. Then she has a series of
instructions to perform, in order. Although she knows what they are,
because the light is off, she has trouble telling exactly what she is
doing... and as a result if she makes any changes to the recipe she'll
end up with a messy kitchen and no pie. She can still make the pie as
much as she likes, and teach the recipy to her friends, but its much
harder for them to meddle with it.
I can't think of any solution to your problem, but maybe some of the
other clever people here have something interesting to say...
ciao,
D.
Paul Rubin
> | You can generally use '>' except inside a tag where the html parser
> | might think the tag is being closed. If you use < for '<' then the
> | parser won't think you're in a tag.
> Yes, but... Using "<" for "<" blows up the encoded character
Yes, just don't use <. Use some other character instead of < and then
you can still use >.
TC
linderd wrote:
> Idly though, what if the javascript application started out by
> prompting the user for input, like those stupid websites that ask you
> to enter your name, and then print "Hello [Name]" at the top of the
> page? (and possibly stored that in a cookie so afterwards you didn't
> have to re-enter it for every other page you viewed).
>
> Then you arent distributing the key with the cipher-text.
>
> Obviously not the stated objective, but probably actually possible (as
> the stated objective is not).
Definitely possible. No doubt about it!
If he can prompt the user for a decryption key, and that key is not
coded-in to the page (or in some other file that is called by the
page), then, the encrypted javascript is perfectly safe from those who
do not have that key.
But:
(1) He would have to get the key to them somehow;
(2) the user would have to enter the key (at least once) - would they
be willing to do that?, and
(3) a user who had the key, could then decrypt the javascript
"manually" (by fnding the decryptor & then running it using the known
key value).
So if his objective is to stop *everyone* from stealing his javascript,
then, there is just no way to do that, afaik.
Cheers,
Jean-Luc Cooke
document.write( unescape( myCode ) );
Where myCode was created offline using the javascript function
"escape()".
But yes, I'm in agreement with everyone else here - making JavaScript
secure is like trying to make water not wet.
JLC
TC <aatcbb...@yahoo.com> wrote:
> linderd wrote:
--
rossum
wrote:
>making JavaScript secure is like trying to make water not wet.
Just what the world needs - dehydrated water. Add water and drink.
rossum