Database Info

photo resizing with pocket PC

I'm using an Orbit2(Touch Cruise), but my question relates to any pocketPC powered device.
Does anyone know of some pocketPC software that allows precise control over photo resizing ? Preferably free (failing that nag-ware). Ideally it would also allowing cropping, control over compression settings, contrast, and USM (but I know that I'm dreaming on this last point!)
I've been searching for several days, but most of the links relate to desktop software which resize down to PDA dimensions. This is not what I want - I already have plenty of software for PC's which does this.
What I want to be able to do is take a photo on the phone (3.2 MP), and then resize by an arbitrary factor
I realise that the built in picture editor allows "resizing" down to 640 by 480, but this is too small, and only applies when you're emailing and does not affect the original. It also over compresses.
The reason for my question is that the orbit 2 camera is pretty noisy, but when scaled down to about 50% using Gimp or Photoshop on the PC actually gives quite a nice image suitable for beaming / emailing.
Thanks,
Roy.

Here are the ones I tried and rejected today:
photoresize (free)
---------------
failed - converted 21 imgaes out of 31 then fell over with a memory error.
for those it did convert, all of the portrait ones were squished (lost the aspect ratio) irrespective of whether "keep aspect ratio" was checked or not.
promising (good selection of sizes, and selectable compression), but poor implementation
but could use in a pinch by creating a directory with just one or two images, and forcing their rotation to be "correct" prior to conversion
PocketPicture (free)
-------------------
seems to be a ms-paint clone.
fell over when I tried to open a large (3.1mp) image
SpbImageer ($15)
----------------
I didn't like the install process -
it wanted to act as an activesync filter, so abandoned install.

Try XnView Pocket. Unlike the name would let you believe, it is more than a viewer; it edits and resizes pictures and is free. http://www.xnviewpocket.org/

Here are the ones I tried and rejected today:
photoresize (free)
---------------
failed - converted 21 imgaes out of 31 then fell over with a memory error.
for those it did convert, all of the portrait ones were squished (lost the aspect ratio) irrespective of whether "keep aspect ratio" was checked or not.
promising (good selection of sizes, and selectable compression), but poor implementation
but could use in a pinch by creating a directory with just one or two images, and forcing their rotation to be "correct" prior to conversion
PocketPicture (free)
-------------------
seems to be a ms-paint clone.
fell over when I tried to open a large (3.1mp) image
SpbImageer ($15)
----------------
I didn't like the install process -
it wanted to act as an activesync filter, so abandoned install.

Read my pic viewer / editor bible

wovens said:
Try XnView Pocket. Unlike the name would let you believe, it is more than a viewer; it edits and resizes pictures and is free. http://www.xnviewpocket.org/
Click to expand...
Click to collapse
Thanks, tried this and it does most of what I want, and the interface was good too.

Menneisyys said:
Read my pic viewer / editor bible
Click to expand...
Click to collapse
Thanks, took me a while to find it, but your review at
http://www.winmobiletech.com/PICVIEWERS/
was exactly the sort of thing I was looking for.
I note you rate xnview highly (version 1.3 in 2005)
it's now at version 1.4, and doesn't seem to have the 8MP image size restriction any more - not that I've tested that.

r_southampton said:
Thanks, took me a while to find it, but your review at
http://www.winmobiletech.com/PICVIEWERS/
was exactly the sort of thing I was looking for.
Click to expand...
Click to collapse
Great you've found it - sorry for my not posting the URL last time, I've sposted my message from my BlackBerry; then, it's very hard to post URL's.

A run through of the panel code and mddi interface

Hey guys,
Over the last few days, I've been reading through the code and just trying to understand how it all works.
I think I've got some pretty good guesses on how the panel interacts with the video hardware now, so I thought I'd share. Some of you probably already know this stuff, so if I'm getting anything wrong, please tell me. Note this whole post is pretty much 100% guesses, so take it all with salt.
The phone uses a "Mobile Station Modem" (msm) chipset which is this specialized chipset made for hand held devices that provides a grab bag of features.
This chipset seems to be what drives access to the various features of the phone (video, cameras, gps, etc). The chipset can be used in a variety of phones and things, so it provides some features that aren't relevant or wired up to the evo 4g.
Inside msm_fb.h there's a list of the output interfaces:
enum {
MSM_MDDI_PMDH_INTERFACE = 0,
MSM_MDDI_EMDH_INTERFACE,
MSM_EBI2_INTERFACE,
MSM_LCDC_INTERFACE,
MSM_TV_INTERFACE,
MSM_MDP_NUM_INTERFACES = MSM_TV_INTERFACE + 1
};
In reverse order, I'm guessing this translates to, "old school tv out", "typical digital video output (for LCDs and other digital outputs)", "memory i/o (unrelated to video? or maybe for driving 'dumb framebuffers'?)", "External mobile display via mddi", "primary mobile display via mddi".
mddi is apparently "Mobile Display Digital Interface" which is some new way to connect lcd panels to the video hardware using less wires than more typical digital video outputs. I guess a usecase for mddi would be a flip phone, where the big screen would take the primary interface, and the little viewfinder screen you use when the phone is closed would be driven via the external interface.
Apparently, the HDMI port on the EVO is hooked up to the LCDC interface (where on other android phones, the LCDC interface is used for the screen). So that leaves the two mddi interfaces left. Which one of the mddi interfaces does driver use for the main display? Unsurprisingly, it seems to use the "primary interface" aka mddi0
Note this code in board-supersonic-panel.c:
if (panel_type == 0) {
mddi_pdata.power_client = mddi_epson_power;
} else {
mddi_pdata.power_client = mddi_novatec_power;
}
msm_device_mddi0.dev.platform_data = &mddi_pdata;
and this code in devices.c:
static struct resource resources_mddi0[] = {
...
.start = MSM_PMDH_PHYS;
...
}
struct platform_device msm_device_mddi0 = {
...
.resource = resources_mddi0
...
}
Okay, so now we know the panel talks to the graphics hardware via mddi. But, how is the image data transferred? Apparently, there are two possible DMA channels. The "primary" dma channel and the "secondary" dma channel. I think these channels are closely tied with the interface the panel is hooked up to. i.e. the panel uses the primary interface, so it would use the primary dma channel. I'm not 100% sure though. It might be that either channel is okay. I suspect the former is true, though, because at some point the epson panels weren't working when they were trying to use the secondary dma channel and Joe Hansche made them work by forcing them to use the primary channel (among other changes).
There is a little mystery here, though. mdp_probe has this:
if (pdata == NULL || pdata->dma_channel == MDP_DMA_P) {
ret = mdp_out_if_register(&mdp->mdp_dev,
MSM_MDDI_PMDH_INTERFACE, mdp, MDP_DMA_P_DONE,
mdp_dma_to_mddi);
} else if (pdata->dma_channel == MDP_DMA_S) {
ret = mdp_out_if_register(&mdp->mdp_dev,
MSM_MDDI_PMDH_INTERFACE, mdp, MDP_DMA_S_DONE,
mdp_dmas_to_mddi);
}
The else half of that code says something like:
if we've found a panel in our devices database that is configured to use the secondary dma channel, then link the primary interface up to the secondary dma channel code.
As the code stands now, there is no panel in the devices database configured for the secondary dma channel, so that else clause will never run, afaict. Anyway the driver is at least structured to allow the primary interface to use the secondary dma channel. It just might not work in practice.
The driver looks incomplete for handling the external interfaces. It hardcodes using the primary interface. That's okay though, since the evo4g apparently doesn't use that interface (since it's not a clamshell phone with a viewfinder display i guess).

the logic seems pretty sound and makes sense. appreciate the detailed write up with the sections of code!
for arguments sake, assume you're 100% correct in everything you stated, im not clear on the immediate next step or options of steps which can be taken from here?

i think this wouldve done more good to be posted in the thread thats topic is about the source u are commenting on. :/

Thanks, extremely helpful even if they are only guesses!

toastcfh said:
i think this wouldve done more good to be posted in the thread thats topic is about the source u are commenting on. :/
Click to expand...
Click to collapse
I thought about it, but I thought it might be a little too much of a deep dive and didn't want to hijack that thread.
We can move the discussion there if you want.

joeykrim said:
the logic seems pretty sound and makes sense. appreciate the detailed write up with the sections of code!
for arguments sake, assume you're 100% correct in everything you stated, im not clear on the immediate next step or options of steps which can be taken from here?
Click to expand...
Click to collapse
well the point of this is code spelunking is just educational, not necessarily with a specific end goal in mind. Since this is the developer forum, it's probably useful in general to have stuff like this written out so that when people (with specific end goals in mind) don't know where to start they can do a read through and figure out the best place to dive in.

[Q] Send picture from PC to WP7

The data can be sent as a simple byte stream.
I want to capture a PC screen and send it to WP7, I must convert it in server side and reconvert it in client side (I don't know how do that).
The code that I developed to capture the PC screen give me a bmp image extension, and the WP7 can't read that file.
How do I serialize media objects (pictures) for socket transfer??
I want to be able to send pictures files from Pc to WP7 via WiFi using socket.
How can I convert the picture file to what the file extension stream and send it?
I am confused how to do that

juste_3al_faza said:
The data can be sent as a simple byte stream.
I want to capture a PC screen and send it to WP7, I must convert it in server side and reconvert it in client side (I don't know how do that).
The code that I developed to capture the PC screen give me a bmp image extension, and the WP7 can't read that file.
How do I serialize media objects (pictures) for socket transfer??
I want to be able to send pictures files from Pc to WP7 via WiFi using socket.
How can I convert the picture file to what the file extension stream and send it?
I am confused how to do that
Click to expand...
Click to collapse
I think I need to know a little more about what you are trying to do.
I am assuming a program is running on the PC. You want to capture an image of the program. Then send it to the phone through WiFi.
For it to be readable on the phone, bmp will not work. Convert it to jpg. Plenty of free algorithms and libraries can be can be found to do this.
To transfer it to the phone, I would suggest using a webserver or hosting one on the same machine. Possibly Apache, since it is free, but i am more familier with IIS.
Have your app on the pc do a post to page on localhost. Have it pass something on the querystring to identify the phone it is for. This page will store the image in a location on your computer that the webserver has access to.
Now your phone will need an app that will also hit that same ip address, not local host. You will need to know the ip address of the machine. Have it hit a different page and pass that phone identifier. The page will do a redirect to the jpg file. As you recieve the output, write it to to a file on the phone. Using Redirect should automatically send the name and mimetype with the response.
There are other more complicated ways to stream an image, but this is the simplest.
You could always have the webserver be on a different machine entirely, which would make it more generic. Yiou could even have it be hosted so it is accessible from the internet, not just the intranet.

Usign a webserver seems vastly over-complicated to me, but OK. Maybe I'm just more comfortable writing netwrok code than most people...
Take your screenshot (I assume you already managed this). Put it in a format the phone likes (JPEG is good; there might even be BMP-to-JPEG conversion code in the .NET library). Connect the phone and the PC.
This is where the network code comes in. I would personally do this by starting a TCP server socket on the PC on some arbitrary high port, more than 1024 and less than 65000. Have it "Listen()" for a request from the phone. Write a phone app that opens a TCP connection to the PC on that port. Once the phone connects, set it waiting to Receive() data. On the PC side, since some signal that you're going to transfer a file (a realllllly simple protocol would be to just send the file size, as an int, first). There are a few ways to send data on a TCP socket; you can use the Send() function which takes an array (type byte[], which could be populated by using another array and then converting), or a NetworkStream, which is just like any other member of System.IO.Stream (I'm assuming you're writing both ends in .NET, although really simple netcode is actually easier in C). To transfer the file itself, just open it and read it however you like, and send the byte array over the socket. On the phone end, create a new IsolatedStorage file, and write the data coming over the socket into it. Just read in a loop until you've read up to the size that the server told you was coming, or until you hit the end of the stream / the connection closes (which indicates a bug or a problem on the other end).
That's a dead-simple and not very robust network protocol, but it does have the advantage of being trivial to code up...
Or, if that all sounds too confusing, you can try using HTTP. I actually find that to be *more* painful, but YMMV; I cut my first netcode in C and to me HTTP feels needlessly complex by comparison (because it's meant to do so many more things than just transfer a simple byte stream like a file). If you want to look at the source code of an app that uses HTTP to send and receive files, including both the phone app and the PC server app, take a look at WP7 Advanced Explorer (it's on Codeplex). Ignore the parts about filesystem and registry for now, and just look at the network part.

To me the web server approach may seem to be the easiest solution because I have been doing dot net web programming since before dot net 1.1 came out (beta 1.0). Before that I was doing other web development using classic asp, xml, xsl, and javascript. So, I have been working with IIS for well over a decade.
Quite recently, I just worked on dot net code to stream documents and video that is not directly accessible through any virtual directory, without doing a redirect for the purpose of enforcing additional security.
Different types of programmers find different things easier. I have done little to no direct sockets programming since college, so that to me would be more difficult, even if it is actually easier.
It didn't even occur to me to try listening on a port.
Also, now that you mention it, there are ways built into dot net to convert image types. I actually use them in some of the programs I've written for Windows Mobile, such as the FB pic to Outlook Pic application. I might be converting the other way in that app though.

I don't think I do that with web service
I prefer to use the Socket.
My apps let me just view the PC screen

juste_3al_faza said:
The data can be sent as a simple byte stream.
I want to capture a PC screen and send it to WP7, I must convert it in server side and reconvert it in client side (I don't know how do that).
The code that I developed to capture the PC screen give me a bmp image extension, and the WP7 can't read that file.
How do I serialize media objects (pictures) for socket transfer??
I want to be able to send pictures files from Pc to WP7 via WiFi using socket.
How can I convert the picture file to what the file extension stream and send it?
I am confused how to do that
Click to expand...
Click to collapse
With the zune.

Link contact adress to Nokia Drive

I use my7rom on my Omnia 7.
Is there anyway to link a contacts adress to Nokia Drive instead of Maps (stock wp7 app). It would be much more practical if Nokia Drive opened a navigation session instead.
Anyone up for the challenge? A reg-tweak perhaps?
// Manneman
Skickat från Windows Phone 7.8

There's two parts here. The first is identifying the correct "filetype" or URI scheme that is used for navigation. That shouldn't be too hard; a little digging in HKCU should reveal it. We already know about ones like callto: and http: and I'm actually (slowly) working on an app to allow people to easily change them. The second part is finding the correct command to load that address or route in the Nokia Maps app. If the app supports pinning routes or destinations to Start, this is probably possible. If not, it may not be possible in the app. Most apps aren't designed to accept command-line parameters, so even if you make them the default handler for a given filetype or URI scheme, they ignore the value you send them and just start as though launched from Start.

GoodDayToDie said:
If the app supports pinning routes or destinations to Start, this is probably possible.
Click to expand...
Click to collapse
Nokia Drive supports pinning to start so it should be possible. Unfortunately I can't tell you exact command line parameters 'cause my Lumia 900 still "in jail"

Let me see if I have a copy of the Nokia Drive XAP handy. I'll need to decompile it to figure out the correct parameters for launching it with the intent of navigating to a specific location. Note also that this might not be possible directly - for example, the app might store a list of locations internally, and the tiles only provide an index into that list rather than providing the location directly - but that just requires another layer of indirection.
In that case, you create an app that gets registered as the navigation handler, and in response to a navigation request, it writes the requested location into the Nokia Drive app and then chain-launches Nokia Drive with the index of the newly written location. That's just an example of one way that this might go wrong, but overall, the odds are actually pretty good. Obviously, all of this will require, at a minimum, write access to the HKCR hive in the registry.

Ah, guys! You are so kind helping me out. I´m really certain alot of members in the WP7 section would love for this to work!
// Manneman

GoodDayToDie said:
I'll need to decompile it to figure out the correct parameters for launching it with the intent of navigating to a specific location
Click to expand...
Click to collapse
GoodDayToDie, you may try much simpler solution. Just create assembly (dll) to show startup parameters in message box, and replace main Nokia Drive dll (but pin some location first).

That's actually harder than it sounds; even if the app is sideloaded (which would mean I already have the DLL) my fake would have to mimic the internal structure of the real app to a degree (namespaces, class names, default actions, etc.). That's not hard, but decompiling .NET is pretty trivial too.

AFAIR, Nokia Drive is obfuscated (but I'm not 100% sure). Also, you don't need to duplicate all names and structures; just a stuff mentioned in WMAppManifest (I hope so). BTW, I forgot: I still have unlocked handset; if I'll found time, will try today later.
Update: tried but without of luck What I did:
- installed Nokia Drive first;
- downloaded map and pinned current location;
- created fake app with same app guid and namespace name ("Drive"), and performed app update (that operation completely override whole solution but NokiaDrive tile still pinned to the start screen);
- tried a few different page names (_default.xaml, QuickStartPage.xaml, DestinationPickerPage.xaml, FavoritesPage.xaml) with code
Code:
protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
{
MessageBox.Show("Hello from fake dll");
if (e.NavigationMode == System.Windows.Navigation.NavigationMode.New)
{
string[] keys = NavigationContext.QueryString.Keys.ToArray();
string[] values = NavigationContext.QueryString.Values.ToArray();
string param = "";
for (int i = 0; i < keys.Length; i++)
{
param += keys[i] + " -> " + values[i] + "\n";
}
MessageBox.Show("parameters: " + param);
}
}
But result always the same: app doesn't start from the pinned tile

Update 2: Finally, I did it
The trick is:
- do the same as I've described above (you should have pinned tile from ND);
- add following code to the start page:
Code:
public MainPage()
{
InitializeComponent();
var appTile = ShellTile.ActiveTiles.Last();
if (appTile != null)
{
//MessageBox.Show(appTile.NavigationUri.OriginalString);
EmailComposeTask emailTask = new EmailComposeTask();
emailTask.Subject = "NokiaDrive pinned parameters";
emailTask.Body = appTile.NavigationUri.OriginalString;
try
{
emailTask.Show();
}
catch (Exception ex)
{
MessageBox.Show(ex.Message, "Error", MessageBoxButton.OK);
}
}
}
- run app as usual (not from tile);
We allset - all params are sent to our email (I'm too lazy to manually copy all stuff )
Here we are (start parameters; bold values are changed for privacy reason ):
/_default?destination.name=200 SomeName Street&destination.latitude=49.5255378801376&destination.longitude=-72.4296837244183&destination.address.street=SomeName Street&destination.address.houseno=200&destination.address.district=&destination.address.county=&destination.address.city=SomeCity&destination.address.state=&destination.address.country=USA&destination.address.postcode=05720&destination.hashCode=371767793destination.address.statecode=MA&pinnedFrom=Favorites
P.S. Just found: Navigon also has ability to pin address to the start tile So, if you find the way to modify map protocol (or how it calls), it will be a really nice hack! BTW, could you remind me: do we have ability to launch assembly by GUID (on the full-/policy-unlocked phones)? If "yes", it's possible to write a real nice "proxy" app to handle map requests

I don't know about launching assemblies directly, but it's certainly possible to launch apps by GUID. It doesn't even require anything more than dev-unlock in fact (although of course you can only launch apps that you could launch anyhow). So yes, a proxy app is totally possible. That's actually what I'm working on (started as a project to make a Kindle ebook file loader, that would pur .mobi/.prc file in the Kindle app's folder and then launch the app).

GoodDayToDie, could you please, take a look to the registry, for default map protocol handler and figure out how to change that stuff? I'm pretty busy these days (and probably will be extremely busy couple of next months) but we can cooperate and create this app...

I'll investigate, but you're not the only one busy. If you've noticed a lack of software from me recently, it's due to the nex job I got some months back; I love it, but it leaves me with a lot less time for phone hacking if I want to still have a life outside of that.
With that said, this actually ties into the work I'm already doing with things like filetype handling and default browser switching. I can send you my HKCRlib, at a minimum; it's a library that simplifies interacting with HKCR, including creating backups of important values when they change, and reverting the backups.

GoodDayToDie, truly, I'm not much interested (personally) in that hack 'cause I can't use it for my Lumia 900. So it's only for the community needs but because of lack of time, I believe, we may put it on hold.

Trident Encoder : Encryption for Windows RT

I implemented a browser based encryption solution which runs on Windows RT (and many other Windows computers). All I wrote was the HTML page, I am leveraging Crypto.JS javascript library for encryption algorithm. I am using the HTML 5 File API implementation which Microsoft provides for reading and writing files.
I make no claim on this but seems to work good for me. Feel free to feedback if you have any suggestions. The crypto.js library supports many different algorithms and configuration so feel free to modify it to your own purposes.
You can download the zip file to your surface, extract it and load the TridentEncode.htm file into Internet Explorer.
If you want to save to custom directory you probably need to load it from the Desktop IE instead of metro IE (to get the file save dialog). I usually drag and drop the file onto desktop IE and from there I can make favorite. This should work in all IE 11 and probably IE 10 browsers... if you use other browsers you may need to copy paste into the fields since the File API implementation seems rather browser specific. Running the html page from the local filesystem means that there is no man-in-the-middle which helps eliminate some of the vulnerabilities of using a javascript crypto implementation. You could also copy the attached zip file to your skydrive to decrypt your files from other computers.
Skydrive files in theory are secure (unless they are shared to public) so this might be useful for adding another layer of protection to certain info.
Again, use at your own risk, but feel free to play around and test it, and offer any suggestions or critiques of its soundness, or just use it as a template for your own apps.

Ok... this is really cool! Nice idea, and a good first implementation.
With that said, I have a few comments (from a security perspective). As an aside, minimized JS is the devil and should be annihilated with extreme prejudice (where not actually being used in a bandwidth-sensitive context). Reviewing this thing took way too long...
1) Your random number generation is extremely weak. Math.random() in JS (or any other language I'm aware of, for that matter) is not suitable for use in cryptographic operations. I recommend reading http://stackoverflow.com/questions/4083204/secure-random-numbers-in-javascript for suggestions. The answer by user ZeroG (bottom one, with three votes, as of this writing) gets my recommendation. Unfortunately, the only really good options require IE11 (or a recent, non-IE browser) so RT8.0 users are SOL.
NOTE: For the particular case in question here (where the only place I can see that random numbers are needed is the salt for the key derivation), a weak PRNG is not a critical failing so long as the attacker does not know, before the attack, what time the function is called at. If they do know, they can pre-compute the likely keys and possibly succeed in a dictionary attack faster than if they were able to generate every key only after accessing the encrypted file.
2) Similarly, I really recommend not using a third-party crypto lib, if possible; window.crypto (or window.msCrypto, for IE11) will provide operations that are both faster and *much* better reviewed. In theory, using a JS library means anybody who wants to can review the code; in practice, the vast majority of people are unqualified to either write or review crypto implementations, and it's very easy for weaknesses to creep in through subtle errors.
3) The default key derivation function (as used for CryptoJS.AES.encrypt({string}, {string})) is a single iteration of MD5 with a 64-bit salt. This is very fast, but that is actually a downside here; an attacker can extremely quickly derive different keys to attempt a dictionary attack (a type of brute-force attack where commonly used passwords are attempted; in practice, people choose fairly predictable passwords so such attacks often succeed quickly). Dictionary attacks can be made vastly more difficult if the key derivation process is made more computationally expensive. While this may not matter so much for large files (where the time to perform the decryption will dominate the total time required for the attack), it could matter very much for small ones. The typical approach here is to use a function such as PBKDF2 (Password-Based Key Derivation Function) with a large number of iterations (in native code, values of 20000-50000 are not uncommon; tune this value to avoid an undesirably long delay) although other "slow" KDFs exist.
4) There's no mechanism in place to determine whether or not the file was tampered with. It is often possible to modify encrypted data, without knowing the exact contents, in such a way that the data decrypts "successfully" but to the wrong output. In some cases, an attacker can even control enough of the output to achieve some goal, such as compromising a program that parses the file. While the use of PKCS7 padding usually makes naïve tampering detectable (because the padding bytes will be incorrect), it is not a safe guarantee. For example, a message of 7 bytes (or 15 or 23 or 31 or any other multiple of 8 + 7) will have only 1 byte of padding; thus there is about a 0.4% (1 / 256) chance that even a random change to the ciphertext will produce a valid padding. To combat this, use an HMAC (Hash-based Message Authentication Code) and verify it before attempting decryption. Without knowing the key, the attacker will be unable to correct the HMAC after modifying the ciphertext. See http://en.wikipedia.org/wiki/HMAC
5) The same problem as 4, but from a different angle: there's no way to be sure that the correct key was entered. In the case of an incorrect key, the plaintext will almost certainly be wrong... but it is possible that the padding byte(s) will be correct anyhow. With a binary file, it may not be possible to distinguish a correct decryption from an incorrect one. The solution (an HMAC) is the same, as the odds of an HMAC collision (especially if a good hash function is used) are infinitesimal.
6) Passwords are relatively weak and often easily guessed. Keyfiles (binary keys generated from cryptographically strong random number generators and stored in a file - possibly on a flashdrive - rather than in your head) are more secure, assuming you can generate them. It is even possible to encrypt the keyfile itself with a password, which is a form of two-factor authentication: to decrypt the data that an attacker wants to get at, they need the keyfile (a thing you have) and its password (a thing you know). Adding support for loading and using keyfiles, and possibly generating them too, would be a good feature.
The solutions to 3-5 will break backward compatibility, and will also break compatibility with the default parameters for openssl's "enc" operation. This is not a bad thing; backward compatibility can be maintained by either keeping the old version around or adding a decrypt-version selector, and openssl's defaults for many things are bad (it is possible, and wise, to override the defaults with more secure options). For forward compatibility, some version metadata could be prepended to the ciphertext (or appended to the file name, perhaps as an additional extension) to allow you to make changes in the future, and allow the encryption software to select the correct algorithms and parameters for a given file automatically.

Wow thanks GDTD that's great feedback
Not sure about his minified sources, the unminified aes.js in components is smaller than the minified version (which I am using) in rollups. I'll have to look into what his process for 'rollup' is to see if I can derive a functional set of non-minified script includes. If I can do that it would be easier to replace (what I would guess is) his reliance on Math.random.
His source here mirrors the unminified files in components folder : https://code.google.com/p/crypto-js/source/browse/tags/3.1.2/src
msCrypto that would be great, I had no idea that was in there. I found a few (Microsoft) samples so I will have to test them out and see if I can completely substitute that for crypto.js. Would be more keeping in line with the name I came up with.
Currently this version only works for text files, I am using the FileAPI method reader.readAsText(). I have been trying to devise a solution for binary files utilizing reader.readAsArrayBuffer but as yet I haven't been able to convert or pass this to crypto.js. I will need to experiment more with base64 or other interim buffer formats (which Crypto.js or msCrypto can work with) until I can get a better understanding of it.
Metadata is a great idea, maybe i can accommodate that with a hex encoded interim format.
You seem extremely knowledgeable in the area of encryption, hopefully i can refine the approach to address some of the issues you raised by setting up proper key, salt, and IV configuration... I'm sure I will understand more of your post as i progress (and after reading it about 20 times more as a reference).
Too bad we don't a web server for RT, that would at least open up localStorage for json serialization (mostly for other apps I had in mind). I guess they might not allow that in app store though. Could probably run one of a developers license though (renewed every 1-2 months)?

nazoraios said:
Too bad we don't a web server for RT, that would at least open up localStorage for json serialization (mostly for other apps I had in mind). I guess they might not allow that in app store though. Could probably run one of a developers license though (renewed every 1-2 months)?
Click to expand...
Click to collapse
I cant comment too much on the encryption, GoodDayToDie has covered anything I could contribute and more. But there is a functioning web server on RT. Apache 2.0 was ported: http://forum.xda-developers.com/showthread.php?t=2408106 I dont know if everything is working on it, I dont own an RT device and last time I tried I couldnt get apache to run on 64 bit windows 8 anyway (needed it at uni, spent hours going through troubleshooting guides and it never worked on my laptop, gave up and ran it under linux in virtualbox where it took 2 minutes to have functioning the way I needed it to).

Curious about the performance. Speaking of encryption, 7-Zip has it built-in, and from the discuss in StackExchange, it seems pretty good.

One of the neat things about this thing (local web app? Pseudo-HTA (HTml Application)? Not sure if there's a proper name for such things) is that it runs just fine even on non-jailbroken devices. That's a significant advantage, at least for now.
Running a web server should be easy enough. I wrote one for WP8 (which has a subset of the allowed APIs for WinRT) and while the app *I* use it in won't be allowed in the store, other developers have taken the HTTP server component (I open-sourced it) and packaged it in other apps which have been allowed just fine. With that said, there are of course already file crypto utilities in the store anyhow... but they're "Modern" apps so you might want to develop such a server anyhow so you can use it from a desktop web browser instead.
Web cryptography (window.crypto / window.msCrypto) is brand new; it's not even close to standardization yet. I'm actually kind of shocked MS implemented it already, even if they put it in a different name. It's pretty great, though; for a long time, things like secure random numbers have required plugins (Flash/Java/Silverlight/whatever). Still, bear in mind that (as it's still far from standardized), the API might change over time.

Yep, I think of them as Trident apps since trident is what Microsoft calls their IE rendering engine, but I guess they are sort of offline web apps (which come from null domain). Being from null domain you are not allowed to use localstorage which is domain specific. You also are not allowed to make ajax requests. You just have file api and json object serialization to make do with I/O.
Another app I am working on is a kind of Fiddler app similar to http://jsfiddle.net/ where you can sandbox some simple script programs.
Kind of turning an RT device into a modern/retro version of a commodore 64 or other on-device development environments. Instead of basic interpreter you've got your html markup and script.
I have an attached demo version which makes available jquery, jquery-ui, alertify javascript libraries in a sandbox environment that you can save as .prg files.
I put a few sample programs in the samples subfolder. Some of the animation samples (like solar system) set up timers which may persist even after cleared so you might need to reload the page to clear those.
It takes a while to extract (lots of little files for all the libraries) but once it extracts you can run the html page and I included a sample program 'Demo Fiddle.prg' you can load and run to get an idea.
I added syntax highlighting editors (EditArea) which seems to work ok and let's you zoom each editor full screen.
The idea would be to take the best third party javascript libraries and make them available and even make shortcuts or minimal API for making it easier to use them. Common global variable, global helper methods, ide manipulation. I'd like to include jqplot for charting graphs, maybe for mathematical programs and provide api for user to do their own I/O within the environment.
These are just rough initial demos, and obviously open source so if anyone wants to take the ideas and run with them i'd be interested in seeing what others do. Otherwise I will slowly evolve the demos and release when there are significant changes.