AES Pad -- No downloads. Local-only. You control it.
by Endlessskyway, May 2014
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Password and password tools
You want at least 128 bits of entropy. Each base64 character has 6 bits of entropy if your random number generator is up to snuff. To help compensate for below-par random number generation, try adding some of your own characters, deleteing some of the generated characters, and hitting the shuffle button a bunch of times. Random.org might also be of some assistance.
Plaintext to be encrypted
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Encrypted text (or hash) result
Encrypted text for decryption:
Decrypted text result:
1) Local only.
This page is a single html5 file that runs fully locally. No accessing the internet.
No cookies. No other "local storage". No spying on you "justified" by some
company's asinine rationalization of their greater good. Only the links on the top
and bottom of the page try to go to the internet, but you can easily strip them out
when you make your own local .html file from this, which you should do.
2) Best way to run it.
Grab the source of this "page", save it into a local .html file, and it should run
just the same. That's actually the preferred way of running this -- to guard
against "meddling" on your page load. In fact, it's even better to run that local
.html file in some alternate browser that's cut off from the internet by whatever
means you like.
you can verify by looking at it in the page source, which I recommend you do.
The CryptoJS v3.1.2 files are pasted in this html page explicitly. Explicit pasting
is done so there is no accessing anything on the internet with the associated risks.
Anyone can verify that the pasted source codes here match the v3.1.2 files from
the proper sources on the internet. I recommend you do that. If they don't match,
don't use this code, because that means either this or the other is corrupted and it
might be this.
5) Format of the encrypted results.
The encrypted results here have the first N characters as hex (containing the salt
and the initialization vector), with the rest as base64. That's less than fully
desirable. Any encrypted stream generally should be indistinguishable from random
noise. The switch from hex to base64 "says something" about what's going on, but
since we're not trying to hide what that something is, it's okay to leave it like
that for now.
6) Size of the encrypted results.
Sending out the encrypted stream in (mostly) base64 means only 6 bits per renderable
character. So, the base64 part of the encrypted message is going to be 6/8ths as
dense as the original plaintext. That is, 8/6ths the size or 33% bigger (plus a
little for padding). The advantage is that the base64-encoded encrypted stream is
cut/pastable, renderable, and handlable as ordinary text. If the data stream didn't
need to be handlable as text, that part of the stream would be the same length as
the plaintext plus what ever small amount of padding proved necessary. Similarly,
the N hex characters at the beginning are only 4 bits each meaning that if they
didn't need to be handlable as text, then that part of the stream would only be N/2