Is this being produced by RadicalSoft(dead), DS(evil empire), or just MV? But it's a pretty good program.

Evil empire :)

Now why are we referring to it as an evil empire?

I don't know, and it certainly isn't. I was just going along with the comment.

I think it's because DS bring out all the quality cool stuff (with limited amounts of source), and so people liken it to the Dark Side (as opposed to Detached Solutions) M$.

Oooooohhhhh.... but I like MS (hahahaha)

DS-Dark Side, haha, I get it! lol

ok, a comparison to M$ isn't even fair. DS's non-buggy (mostly) software is free, not WAY overpriced.

As to the source, I'd like to see it released; but they created it so it's their choice.

Does anybody have a description of the cipher used in this program?

There are three different ones. Blowfish, GOST, and RC6. If you search on Google you can find the papers for all three.

waiiit did you not include the source code, or am i just not seeing that as well?

If he included the source code, it would make it slightly easier to crack. Therefore the program would be useless.

that's not the way that encryption works, but anyway.

saying that is like saying that twofish encryption is useless in the linux kernel because you can go download the source for the patch at kernel.org
/pub/linux/kernel/v2.4/people/hvr

The source code shouldn't affect the strength of the files encrypted though, only the possibility of someone in a debugger snooping during encryption. I will be releasing the source code once there is no possibility of further development.

word, i'd like to see it (regardless of the fact i haven't touched any z80 code in 4 years ..)

Are z80 apps in assembly, or are they in C like the 68k apps?

ASM

If this is written in assembly, it *is* the sourcecode; you just have to convert the hex values to human-readable opcodes with a lookup table.

no ..
it's machine code, and you'd be converting it from machine code backwards to assembly code, which would result in assembly code that has no human readable labels and such..

HOLY DUDE! Your userID is 38! (Of course, NickD's is three)

But back to topic... when one would encrypt a file, would the file size normally be larger or smaller? If smaller, you could use it as a type of compression.

Neither, it's exactly the same. There is the possibility of gaining up to 7 bytes, because I have to pad the file to make it have a length that's a multiple of 8.

You do realize that you just contradicted yourself, right? :-p

He said "normally." If you study the encryption algorithm, the number of bytes input is equal to the output bytes. However, in the implementation it is necessary to have a complete input. If the algorithm works on 8 byte blocks, then I have to pad the data to be a multiple of 8 bytes.

my friend claims to have found a flaw in the password part of this program. He says when the enter password screens appears when you start up you can hold the delete button and then remove a battery thus reseting the ram and the password along with the options you set for the program allowing access to the calc. post if you can shed any light on the situation

Well, Michael's been around for a very long time. I've been around for awhile, but not nearly as long as him. Also, I bet the program goes through a file byte by byte (or bit by bit) and encrypts each byte (or bit), so the file size wouldn't change.

That said, I've never owned a TI-83+, I have not tried this program, and nobody but Michael has seen the source.