Most recent edit on 2008-08-02 18:37:55 by KogAdmin
Deletions:
~- Screen shots
Edited on 2006-08-17 20:34:44 by KogAdmin
Additions:
NEEDS RECOVERY
Edited on 2006-04-02 06:03:38 by KogAdmin [notes update]
Additions:
~- GUI in MS VC# 2003 format, src + binary (see notes)∞ RC1
Regarding the GUI: it's my first winforms app, so I'm teaching myself best practices. I've wired some hotkeys the way MSDN tells me to, so hopefully that's all ok. There's a long laundry list for the GUI to take care of - the first probably being auto-resize on window resize. Now that the project has gone RC1 I'll probably get back to it after the rest of the projects go RC, I'm working as time permits. The GUI is somewhat ugly, but if I fix some portions it'll be relatively simple and nice to use.
Edited on 2006-04-02 00:01:59 by KogAdmin [scr+binary]
Additions:
~- CLI in MS VC# 2003 format, src + binary (see notes)∞ RC1
Deletions:
~- CLI in MS VC# 2003 format (see notes)∞ RC1
Edited on 2006-04-02 00:01:29 by KogAdmin [list formatting]
Additions:
~- CLI in MS VC# 2003 format (see notes)∞ RC1
Deletions:
CLI in MS VC# 2003 format (see notes)∞ RC1
Edited on 2006-04-02 00:01:16 by KogAdmin [closing parens are good]
Additions:
My releases are written using SharpDevelop (original)∞ against .NET1. There's no significant improvement such that I'm planning on swapping out to 2, although I could easily cross-compile with SD (since unlike MSVS it's not bound to a specific framework). I've made an effort to spit out an MSVS-friendly build file using SD's export MSVS 2003 function. I tested it on a friends' copy, and it seemed to work. Worst case scenario I could always build a NAnt build file or something.
Deletions:
My releases are written using SharpDevelop (original∞ against .NET1. There's no significant improvement such that I'm planning on swapping out to 2, although I could easily cross-compile with SD (since unlike MSVS it's not bound to a specific framework). I've made an effort to spit out an MSVS-friendly build file using SD's export MSVS 2003 function. I tested it on a friends' copy, and it seemed to work. Worst case scenario I could always build a NAnt build file or something.
Edited on 2006-04-02 00:01:03 by KogAdmin [notes]
Additions:
Notes
My releases are written using SharpDevelop (original∞ against .NET1. There's no significant improvement such that I'm planning on swapping out to 2, although I could easily cross-compile with SD (since unlike MSVS it's not bound to a specific framework). I've made an effort to spit out an MSVS-friendly build file using SD's export MSVS 2003 function. I tested it on a friends' copy, and it seemed to work. Worst case scenario I could always build a NAnt build file or something.
Edited on 2006-04-01 23:48:34 by KogAdmin [link fix on dl]
Additions:
CLI in MS VC# 2003 format (see notes)∞ RC1
Deletions:
CLI in MS VC# 2003 format (see notes)∞ RC1
Edited on 2006-04-01 23:48:01 by KogAdmin [cleanup, organization, creation of sub-pages]
Additions:
History
I love crypto as a hobby. As such, someone once asked me to write them a simple way of encrypting things to store on her Livejournal (don't ask...). I originally wrote the app as a GUI, but I rewrote the app while cleaning up/writing an interface for the project and figured a CLI app would be better to start with. Most of the code can be re-used anyway.
ECrypter is a tool that allows you to encrypt text in a paste-friendly way, decrypting it later.
Project Status
CLI in MS VC# 2003 format (see notes)∞ RC1
Links
Deletions:
AESC is in the process of being re-written with a pluggable encryption API (see below). I'll be releasing both a CLI and a GUI version (SWF, not GTK# at the moment) sometime soon, especially since the US export laws on strong crypto no longer apply. For now, feel free to view my interface for ICrypter:
using System;
namespace Org.Epiphanic.ECrypter
{
/// <summary>
/// Interface for a pluggable Ecrypter drop-in
/// </summary>
public interface ICrypter
{
string Encrypt(string plaintext);
string Decrypt(string ciphertext);
void Save(string file);
void Load(string file);
void Configure(params object[] p);
}
}
Configure accepts an arbitrary bunch of objects (sorry... box your primitives) as parameters. Unfortunately params is {1,n}, so if you have no params, you should wrap it with a no-param method (like I do with the AES crypter). Yay for language constructs. If you do need the params (ECC quadratics, key strength etc), just remember to send it 1 or more objects, and you can either pass it an explicit array or just a bunch of params (IE: Configure(a,b,c,d) or Configure(new object[] {a,b,c}).
Eventually there will be a DLL to compile against, and you can throw your own DLLs in to use as encryption methods.
There's also a ByteConversion class that comes bundled, allowing for canonicalization of byte[] (that is, long strings of padded integer representations of bytes). There are a myriad of interesting qualities derived from this, which I hope to explain later. For now, suffice-it-to-say that integers are very hardy, they obfuscate and are extremely mutable. I also suggest using ByteConversion with encrypt/decrypt - the first crypto module will spew out encrypted canonicalizations as the ciphertext, and translate them back into plaintext
ByteConversion:
using System;
namespace Org.
Epiphanic.
ECrypter
{
public class ByteConversion
{
public string FromBytes
(byte[] bytes
)
{
string finalMessage =
"";
string c =
"";
//convert to a string
foreach (byte b
in bytes
)
{
if (b <=
9)
c =
"00"+b;
if (b <
100 && b >=
10)
c =
"0"+b;
if (b >=
100)
c =
""+b;
finalMessage += c;
}
return finalMessage;
}
public byte[] FromString
(string input
)
{
int i =
0,j =
0;
string temp =
"";
byte[] crypted =
new byte[input.
Length/
3];
//convert to a byte[]
while (j < crypted.
Length)
{
temp = input.
Substring(i,
3);
crypted
[j
] = Convert.
ToByte(Convert.
ToInt32(temp
));
i +=
3;
j++;
}
return crypted;
}
}
}
Kinda hackish for now, but it works. I'll clean it up to use string formatters and more C#-tastic stuff when I'm done building the rest of the app.
Right now it won't support asymmetric encryption so well, but as I open up configure it should support more operations. You could also extend the interface to provide things such as sign and verify - the interface is just to provide a simple, usable/readable way to deal with crypto.
More will be added later
Edited on 2006-04-01 17:13:03 by KogAdmin [syntax edit]
Additions:
Configure accepts an arbitrary bunch of objects (sorry... box your primitives) as parameters. Unfortunately params is {1,n}, so if you have no params, you should wrap it with a no-param method (like I do with the AES crypter). Yay for language constructs. If you do need the params (ECC quadratics, key strength etc), just remember to send it 1 or more objects, and you can either pass it an explicit array or just a bunch of params (IE: Configure(a,b,c,d) or Configure(new object[] {a,b,c}).
Deletions:
Configure accepts an arbitrary bunch of objects (sorry... box your primitives) as parameters. Unfortunately params is {1,n}, so if you have no params, you should wrap it with a no-param method (like I do with the AES crypter). Yay for language constructs. If you do need the params (ECC quadratics, key strength etc), just remember to send it 1 or more objects, and you can either pass it an explicit array or just a bunch of params (IE: Configure(a,b,c,d) or Configure(array_of_a_b_c_d)).
Edited on 2006-04-01 16:09:00 by KogAdmin [configure params, byteconversion class]
Additions:
void Configure(params object[] p);
Configure accepts an arbitrary bunch of objects (sorry... box your primitives) as parameters. Unfortunately params is {1,n}, so if you have no params, you should wrap it with a no-param method (like I do with the AES crypter). Yay for language constructs. If you do need the params (ECC quadratics, key strength etc), just remember to send it 1 or more objects, and you can either pass it an explicit array or just a bunch of params (IE: Configure(a,b,c,d) or Configure(array_of_a_b_c_d)).
Eventually there will be a DLL to compile against, and you can throw your own DLLs in to use as encryption methods.
There's also a ByteConversion class that comes bundled, allowing for canonicalization of byte[] (that is, long strings of padded integer representations of bytes). There are a myriad of interesting qualities derived from this, which I hope to explain later. For now, suffice-it-to-say that integers are very hardy, they obfuscate and are extremely mutable. I also suggest using ByteConversion with encrypt/decrypt - the first crypto module will spew out encrypted canonicalizations as the ciphertext, and translate them back into plaintext
ByteConversion:
public class
ByteConversion
{
public string
FromBytes(byte[] bytes)
{
string finalMessage = ;
string c = ;
foreach (byte b in bytes)
{
if (b <= 9)
c = "00"+b;
if (b < 100 && b >= 10)
c = "0"+b;
if (b >= 100)
c = +b;
finalMessage += c;
}
return finalMessage;
}
public byte[] FromString(string input)
{
int i = 0,j = 0;
string temp = ;
byte[] crypted = new byte[input.Length/3];
convert to a byte[]
while (j < crypted.Length)
{
temp = input.Substring(i,3);
crypted[j] = Convert.
ToByte(Convert.
ToInt32(temp));
i += 3;
j
;
}
return crypted;
}
Configure will be swapped out to allow arbitrary arguments sometime soon. For now all it does (since all I have is a Rijndael module) is generate an IV and a key, meant to be saved bundled as a "session." Some algorithms will require key strength, curves (ECC) or other seemingly arbitrary information.
Eventually there will be a DLL to compile against, and you can throw your own DLLs in to use as encryption methods. I'll be building a ByteConversion class that will convert from byte[] to string in the form of numerical representation of bytes. There a myriad of interesting qualities derived from this, which will be explained later, but for now just suffice-it-to-say that integers are hardy as an intermediate form and rather mutable. The ByteConversion class is the reason why Encrypt and Decrypt both work on/return strings, because everything will be either plain text, or the canonical representation of the integers of the bytes of the ciphertext.
Edited on 2006-04-01 05:40:13 by KogAdmin [interface, rewrite]
Additions:
AESC Project Page
AESC is now ECrypter, until I can come up with a real name
AESC is in the process of being re-written with a pluggable encryption API (see below). I'll be releasing both a CLI and a GUI version (SWF, not GTK# at the moment) sometime soon, especially since the US export laws on strong crypto no longer apply. For now, feel free to view my interface for ICrypter:
using System;
namespace Org.Epiphanic.ECrypter
{
/// <summary>
/// Interface for a pluggable Ecrypter drop-in
/// </summary>
public interface ICrypter
{
string Encrypt(string plaintext);
string Decrypt(string ciphertext);
void Save(string file);
void Load(string file);
void Configure();
}
}
Configure will be swapped out to allow arbitrary arguments sometime soon. For now all it does (since all I have is a Rijndael module) is generate an IV and a key, meant to be saved bundled as a "session." Some algorithms will require key strength, curves (ECC) or other seemingly arbitrary information.
Eventually there will be a DLL to compile against, and you can throw your own DLLs in to use as encryption methods. I'll be building a ByteConversion class that will convert from byte[] to string in the form of numerical representation of bytes. There a myriad of interesting qualities derived from this, which will be explained later, but for now just suffice-it-to-say that integers are hardy as an intermediate form and rather mutable. The ByteConversion class is the reason why Encrypt and Decrypt both work on/return strings, because everything will be either plain text, or the canonical representation of the integers of the bytes of the ciphertext.
Right now it won't support asymmetric encryption so well, but as I open up configure it should support more operations. You could also extend the interface to provide things such as sign and verify - the interface is just to provide a simple, usable/readable way to deal with crypto.
More will be added later
Deletions:
AES Crypter is an effort to provide rather simple and somewhat secure text encryption. The source is on my mythical soon-to-be-recovered harddisk and I still need to figure out a way to distribute it that doesn't violate US encryption export laws.
Oldest known version of this page was edited on 2005-06-09 02:22:46 by KogAdmin [import of mediawiki content]
Page view:
AES Crypter is an effort to provide rather simple and somewhat secure text encryption. The source is on my mythical soon-to-be-recovered harddisk and I still need to figure out a way to distribute it that doesn't violate US encryption export laws.
This page is
CategoryAESC