Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] need to set up fax-mail system



Hi all, posting from a new email address.

I want to implement a system that sends faxes by email, whilst keeping
the fax contents secure from prying eyes and maintaining some degree of
certainty that the claimed sender is the actual sender.

Ultimately I just want to see all fax machines go away. 

I think almost everyone knows how this can be done without writing any 
new software, just re-purposing tools we already have. 

I'd like to know if anyone sees problems with this basic idea, as in
sane or not sane?   EG - As generally described, does this solution
make sense, assuming one has enough money to make and support the 
number of servers needed for the user population? 

Simple idea is this: 

"faxmail" user's register with a service to get PKI-GPG style keys.

The service generates keys, and has a DNS-like pub-key lookup.

when sending, the keys are used to encrypt msg content securely, 
secure data is emailed to recipient just like regular email,
recipient uses their priv-key and sender's pub-key to decrypt
the "fax". 

So Data is sent securely, couldn't be read by nodes it passes thru.
Receiver knows it was sent by the claimed sender by use of the
sender's pub-key to decode after they have used their priv-key
to do the initial decode. 

"A" is the sender, "B" is the recipient, & is crypt-decrypt

A > content & A-priv-key & B-pub-key &  |SMTP| \

& B-priv-key & A-pub-key & content > B 

Email envelope is just like today, with content being only
MIME-packaged secured data. So yes, the sender and recipient
can be seen in the envelope. Content is secure, but traffic
intelligence is still capturable.

The key service would be implemented just like the DNS system
with Time-to-live properties etc.. and would all be done in 
DNSSEC, signed style. Also- Servers would have ability to
"push" a key revocation out via email to most recent addresses 
that looked up the key.

Users get issued at least 3 pairs of keys when they sign up

Pair 1 is used for faxmail crypto. 

Pair 2 is used only when the user thinks pair 1 has been compromised
(eg - Pair 1 priv-key has been stolen, leaked or otherwise exposed)
Pair-2 is used to secure and verify a "get new keys" transaction
with the key service.

Pair 3 - is used by the service when it wants to revoke existing
key pairs in the field. Yes- that is messy, but its necessary.

Notable:  the concept of "fax received" part of fax protocol 
totally goes away. SMTP err codes will have to suffice.

====================================================================

The remainder is just another description of the idea, in case 
it didn't make sense above.

If you want "faxmail" you'll sign up with the service,
which will generate a set of 3 pairs of asymmetric PKI style
keys for you. 

Users will install some software on local system that will manage and use 
the private side of each key pair by copying the priv-keys
to a USB drive or SD card, (or phone) and retrieving the priv-key
when needed to encrypt fax content.

That software will use the priv-key to encrypt fax-message 
into "enc-data1", and then, DNS style, will lookup 
the public-key of the person you want to fax it to, and further encrypt
the enc-data1 with that key into enc-data2. 

Finally enc-data2 is emailed to the recipient, who, having installed the 
same software, uses their priv-key to decode enc-data2 back into enc-data1,
looks up the public-key of the sender and decodes enc-data1 back into
the original message, which could be graphical, like a tiff file, or 
plain text, or a meta-document containing both an image of the document
and the digital source text of the document, for indexing.


=======================================================================

Anyone see Problems? 
Scaling is known issue but I want to hear it anyway.



=======================================================================

Assumptions: 

I assume that more people have email today that have fax machines and so
would probably rather get a fax by email than by fax.

Also I assume PDF's suck and/or are an ongoing security hazard and/or
a continuing headache to wrangle and/or don't give people sufficient access
to their text content so they can't be searched or indexed.

also assume that the software to hold key and crypt/decrypt will run on
Linux, *NIX, Darwin, BSD's Windows, IOS, Android, Wince. [ or can be 
made to run there]

more assumptions? what did I miss?

=======================================================================
Social Side effects - large scale, decentralized, verifyable-Identity
service will enable what other capabilities? 

=======================================================================


Jeff.

-- 
This email partially created with "Dragon Naturally Speaking" speech
recognition system, aka "NS" or "NatSpeak". 
Note: the email may have incorrectly transcribed content.

Jeff Kinz, Emergent Design. 
"Carpe Piscis." -> "Seize the Fish" -> "Fish the Seize"

-- 
This email partially created with "Dragon Naturally Speaking" speech
recognition system, aka "NS" or "NatSpeak". A tool I'm glad to have
been part of. Note: the email may have incorrectly transcribed content.

Jeff Kinz, Emergent Design.
"Carpe Piscis." -> "Seize the Fish" -> "Fish the Seize"


-- 
This email partially created with "Dragon Naturally Speaking" speech
recognition system, aka "NS" or "NatSpeak". A tool I'm glad to have
been part of. Note: the email may have incorrectly transcribed content.

Jeff Kinz, Emergent Design.
"Carpe Piscis." -> "Seize the Fish" -> "Fish the Seize"




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org