ARM Club 3/TheARMClub_PDCD3.iso/hensa/security/a241_1/AC/!Signature/!Help

Text File | 1993-02-04 | 24KB | 552 lines

Open reply on NetMail, dated Sat,16 Jan 1993.18:13:58, sent
From:    Dirk-Willem van Gulik
To:      All
Subject: Re: Signature 1.04


                 Help file for Signature.

                 This is a TEST version.

                      version 1.04

              © 1993 Dirk-Willem van Gulik

              - supports interactive help -

   For conditions of use, see the end of this file.

This program allows you to 'sign' and 'seal' text files with your
personal signature. This seal/signature is attached to the text.
Any changes made to the text will render this  signature invalid.

A public key list allows you to check signatures from other
people. If you drag a signed message into this programme it will
check the signature against the known public keys of the sender.
This implies that the message must have a certain header (as
WimpLink 0.96 supplies) which includes the sender.

You will have to create a personal signature first with the
programme 'maker' which accompanies this application. This
programme will make both a secret and a public key. You can then
distribute the public key freely. A 'public' file, which you can
distrubute as a message is create in the same (root) directory as
!Signature.

As the secret password is stored on disc there is an option in
the program to scramble it with a secret password. You should do
this as soon as possible. Just run !Signature immediately.  The
programme will agressively ask for such a password, in fact it
will refuse to do anything, until you have entered one. After
this 'first-time-bad-behaviour' it should get into better moods,
and bit will bhaves decently (I hope) on your sucsessive runs.

This password is normally a sentence of about 15 words long.
Special 'token' words will code the signature. The first time
you run the programme '!Signature' after having used Maker, you
will be prompted to enter a password. In the 'Change/Enter
password' window you will find a 'token-word-list'. Only words
from this list scramble your signature. Normally you would build
a sentence around about 10 words chosen from this list. As an
example you could make passwords like these:

 - He himself is a good rabbit.
 - London is no longer a good living place to look after.
 - Drink Driving is a stupid thing to do.

As you will see only half of these words actually count, i.e.
code your signature. You can see how many 'valid' words you
entered by pressing on 'COUNT'. At least one word should be taken
from the token list in order to make a password a valid password.
If not, the programme will refuse to accept the password. After
you have pressed the 'Change' button your signature will be coded
and stored on disc. From then on you will be prompted to enter a
password each time you run  !Signature. This password is checked
against the known public keys. After that it will be used
together with the information on disk to sign any messages you
drag into the programme.

Be sure you remember your password as there is no way of
recovering it, the 'private file', the password and at least one
public key are needed to sign a message. If any of these gets
missing there is no way of recovering it. You need both public
keys to check the signature of someone else.

After you have ran 'Maker', to create your signature, and
!Signature, to enter your personal password, and you have
distributed the 'public' key-file to your friends, you are ready
to go....

The RSA Public key crypto system...

In 1978 Rivest, Shamir and Adleman published a scientific paper
which, in one brilliant stroke, made all problems with secret
keys, reliable messengers and authorized channels history. They
devized an asymetric coding scheme utilizing a set of three keys.
One of these keys is a secret master key, the two other keys are
known as the public keys. The scheme is called asymtric because
coding and decoding is ruled by different keys. Depending on the
way you use them you can either 'code' messages with the public
key which can only be decoded by the secret key or you can
de-code messages with the public key which can only be coded by
the secret key. This last option is used in this Signature
application.

Because you 'cannot' reconstruct the secret key out of the public
key this system does not rely on complicated exchanges of secret
keys and passwords. This makes it possible for someone to
distribute his public keys. The 'cannot' verb should not be taken
too seriously, it is possible to do this reconstruction at the
expense of an immense amounth of computer power. The amounth of
power required relies on the lenght of the key. Signature can
cope with long keys, up to 300 decimal digits. The last 'hack'
reported on the RSA scheme was done by Manasse and Lemstra in
1990. Using massive parallel computer power they managed to break
one individual signature of lenght 107. In the appendix you can
find a short explanation of the RSA system, the way it works and
how it can be broken.

Brute force code breaking however is not a serious risk. Using
something commenly known as 'human-engineering' one could fool
people far more easier and cheaper. The famous example is of
someone calling up and saying 'hello, this is your friendly bank
manager speaking, we are having problems with our computer, and
something is happening to your bank account. What is your
Personal Identity Code ?' Using a 100 digits or more will
certainly ensure that the 'technical side' of signing messages is
dealt with and that the 'weakest' link must be found on the
organizational/human half of the story.

The signing procedure

This procedure consists of three steps; Checksum creation, Coding
and adding the signature to the message. The first step creates a
unique number which is dependent on every single character in the
message. Changing a single character will affect the checksum in
a very unpredictable way. In this 'unpredictable' is the
key-word. Up till version 1.04 use a technique  classified as
polinomal creation. Later version have a few more tricks up their
sleeve. The reason for this is that the checksum is of cource
shorter than the text. So there must be quite a number of
different messages all with the same checksum. This means that in
theory you could change a message and still have the same
checksum. This would not be detected by the system. However the
lenght of this checksum is equal to the length of the key.
Because of the fairly 'inpredictable' way in which this checksum
changes it is very hard to generate a message which is both
meaningfull AND which has a  specific checksum. Currently a
length of 39 decimal digits is considered to be safe....
!Signature uses a checksum which has the same length as the
secret key, in the order of 100 digits.

This checksum is then coded using your very personal and secret
key. The  resultant chypher code is translated into reable ascii.
This ascii string is added to the message.

The receiver removes this string. Next it again calculates the
checksum. Then it 'decodes' the signature using the known public
keys of the sender. This should result in the vaule of the
original checksum. This must match with the newly calculated
checksum. If they do you can savely assume that the message is
NOT altered and that the signature has been created by somone,
the sender, who knew the secret key. As you will notice only
'public' information is used and created in this process. The
checksum which is calculated is of cource public, because the
receiver may read the message. The information extracted from the
signature is again a checksum, which contains information about
the message to which you already have acces to.

Well that is the technical side.... now for the weak spots:

..... the secret key and all the values of the variables used whilst
      creating it must be kept secret.
..... the checksum must be long enough and must be so unpredictable
      that it is impossible to create a message given a certain checksum
..... the communication channel of the public key and messages must
      be safe. If not an attacker could intercept the public key and
      all messages send to you, send you his own public key, and resign
      all subsequent messages from then on.
..... during the coding oparation your system should be 'closed'
..... there is no way of checking whether a message arrives, so removal
      and repeated sending is possible. You can prevent this by numbering
      and dating the messages if this is important.


Usage......

How to use this pogramme...........

Outgoing mail:

 Simply write your messages as usual, using any editor, typically
 !Edit. After you have written them, drop them on the icon-bar-
 icon of !Signature to have them signed. After a few seconds and
 some hourglass fiddling a normal 'save-as' window will appear.

 Now you can drag the -signed- message to its destination, a filer,
 mail programme or editor. Of course you can always type out a full
 pathname and press the return key or 'OK' button.

Incoming mail:

 Incoming mail should have a header. A typical header, like the one
 WimpLink (0.96) supplies looks like

   Private message on NetMail, dated Fri,04 Dec 1992.15:10:01
   From:    Dirk-Willem van Gulik
   To:      Pieter Griessen
   Subject: Birthday party of Adriaan.

 The exact format of the header recognized can be changed in the
 'preferences window'.

 If you drag a window with an appropriate header onto the icon-bar-
 icon of signature, an analyze window will pop up. This will inform
 you about the sender of the message. Whether her/his public key is
 known, whether the message is signed and if this signature matches
 the known public keys.

To allow a greater degree of control you can open a more elaborate
window. Just press SELECT on the iconbar icon. This will open a large
window in the middle of your screen. You can use the interactive help
to find your way around. Typically you can drag a message into the
in-tray, right-hand-top-corner. Next you can have it signed, even if
it is already signed, remove the last signature or check the signature.

If there is no known sender to check the signature against, you can
enforce one temporarily by choosing one from the list. You can gain
access to a menu with a list of all known public-signatures owners
by pressing select on the '⇨' button, to the right of the from field.

You will see that the first entry in this public list has an arrow
pointing to a leaf item. This window contains a whole host of information
about your public key, the age of your password (keep it fresh!) and
public list. Most notably there is also a report on the signature
attachted by the list-distributor of the public list.

Preferences:

 For the more expert user there is also a preference section. It can
 be reached by choosing the option 'Prefs...' in the menu. This will
 open a window with various options. Changing these will normally affect
 the format of your outgoing mail. This can cause serious trouble,
 because your Mailer, your Host and the people you send your mail to
 expect you to use a certain format. So do not change these setting,
 unless you are VERY sure about what you are doing. If a change is needed,
 for example because a new version of WL appears, you will be briefed by
 private netmail.

..>> To protect the inexpert user a nasty protection scheme has been
..>> employed. This 'prefs' option will not be visible, unless you open
..>> the menu whilst pressing 'shift'. This will ensure that ony people
..>> who have read this help-text will be able to access it. I am sorry
..>> if you find this tooooo paternalistic.

 The main reason for providing this option is to ensure that during the
 initial testing period certain characterstics can be changed. Future
 versions of this programme will most like have a more 'hidden' way
 of setting up things.

 Export line separators.

  The ascii end op line codes. Currently only lf and cr are supported.
  Most mailers accept both.

 Signature specification

  Specify the signature prefix. Currently set at '*Signature ['. Also
  whether to compress the signature-sequence. (saves about 62%)

 Header specification

  Specification of the header of incoming mail. Currently set to the
  values which match WimpLink version 0.96.

 After you have entered any values you can do three things:

 Press the CANCEL button; this removes all your changes and ignores them.

 Press the STORE button; this will (after confirmation) save the newly
 entered values to disc and use them on this and subsequent runs.

 Press the Oké button. This will use the newly entered values on the
 current run, but will NOT save them.

Entering/Changing your password:

 As said you will have to enter your password. You can also change the
 password. There is a 'Password...' option in the menu.

 The password window consist of 4 parts. Use the interactive help to
 find your way around it quickly.

 Entry area:

  This is the white top rectangle. Here you type out your password. You
  can use the cursor-keys to find your way around. The editor however is
  not very advanced and certainly not up to the normal risc-os-standards.
  As soon as you have typed part of a word you will find that the token
  list scrolls to the nearest entry in the token list. You can click
  SELECT on the 'insert' button, or press tab to automagicaly insert a
  word from the token list. The more words from this list appear in the
  password-sentence, the better the coding of your secret signature will
  be. About 20% is really the minimum.

 Comment area:

  This is the small (yellowish) rectangle just below the entry area. It
  tells you about the things you are currently supposed to do...

 Count/Info area:

  Bottom lefthanded square. You can find some counts on the number of words
  and the number of token words in your password sentence. The more the
  better. Also the 'covering' percentage is displayed, ie what part of
  your signature is coded by the password sentence.

 TokenList:

  The bottom middle square. This is a list of thousand words. Each word has
  a number. Every word in your password sentence which can be found in the
  token list combines to on mega-long-number. This number codes your
  secret signature code.

 Count button:

  Press this button to update the count area.

 Cancel button:

  Cancel and close the password entry/change window. If you are entering a
  password for the first time in a run-session this will be aborted too.
  This means that the programme will refuse to sign messages.

 Oké/Change button:

  Oké-state: When you press this button the password sentence entered is
  translated into a long number. This number is combined with a number
  from the file 'private'. Together these will make your secret signature.
  Then this signature is checked against the known public keys. If they
  match, the password is accepted. This means that the programme checks the
  password without actually knowing the password! So you better not forget
  it because there is no-one who can get it back.

Public List.

 Inside the !Signature application is a text file called 'List'. This file
 contains all the public keys known to the programme. As soon as you have
 ran 'maker' you will find your name added to that list along with the
 public keys. From time to time you will have to update this file. This
 will normaly require replaceing it by a new 'List' file. Use Shift-Double
 click on the application icon in the filer dir to open de directory
 inside !Signature. Rename the old 'List' into something like 'backup' and
 copy the new list into the directory.

 This is, by the way, the only flaw in this otherwise secure system of
 signing and sealing messages. It is absolutely required that you have an
 authorized, ie unalted and correct list of public keys. From version 1.04
 onwards the list is checked for a public, hard-coded, distribution key.

 A future version of this programme, for serious use, will address this
 subject even further. Problems like this can, by matter of principle,
 not be solved by computer and mathematical tricks, and the solution is
 one of organizing  and protocol agreements between people rather
 that computing.

 In order to make sure that your public keys, which are added to the list,
 are secure the following protocol is to be adhered to:

 - You should send the list distributor the file 'public' made by Maker.

 - The list distributor will return this message with his sign attached.

 - You check this signature using your secure list. You also check
   your keys which are quoted in the message against the ones stored
   in your private file.

 - Only and Only if they match, and if the signature of the message if
   oke, you send a confirmation to the list distributor, signed with
   your now fixed signature.

 - Your public keys will be added to the list and a new list will be
   send to all users. This list is of course signed. On receival of this
   list you will check it against the public keys of the OLD list. Only
   if everything is correct you are to replace the old list.

 The main safety measurement is keeping your system clean. First make sure
 you have a 'safe' version of the software. For the extrem schito-people,
 you can order one from the address below. Next you have to keep this
 version clean. This means 'locking' of the disc/directory, if possible,
 as on a floppy disc, using the 'hardware' write-protection thingy on the
 disc. Every time you get a new distribution list, check wether the sender
 and his or her signature is correct. If in doubt, get a few copies of the
 list, from several (BBS) sources, and check wether they have EXACTLY the
 same signature. Ctrl-Reset your machine before updating the list; do not
 use your harddisc, just a 'bare', 'clean' machine  quite sufficient!

Well that is all there is to it.

Happy signing.
....................... W A R N I N G S ...............................

WARNING for usersers of WimpLink 0.96 (and other versions perhaps)

WimpLink substitutes the '{' characters into '{/123}' whilst exporting
messages if the 'Impressionize Brackets' option is on. This is to make
sure that Impression does not get confused by the '{' character, which
normaly defines the start of a lay-out-token. However !Signature
sees this as a change of the contents of the message, effectively '/123}'
is added. So make sure that the impressionize options are OFF, or check
the message (and signature) for '{' tokens if a 'non-match' occurs. A
'match' situation is always save, no matter the '{' characters or
substitutions.

WARNING for users upgrading from Signature 1.03 and below.

There is always a certain trade-off between individual and system
safety. After some discussion it has been deceided to change the
balance a wee bit into the direction of the individual user. This
means that in version 1.04 onwards a different password sentence
coding system has been implemented. Full instructions can be found
in a file update_103. Please study them carefully and follow then
closely.

........................................................................

Boring section:

This programme is (c) december 1992 by Dirk-Willem van Gulik.

     -   C O N D I T I O N S      O F      U S E   -

 Both the user and or the owner of the media this programme is
 stored upon, as well as the user and or the owner of the
 computer system this programme is loaded into agrees to the
 following conditions:

 This programme shall not be changed. All its files as listed below
 shall remain part of the programme unalterd and must be stored
 inside the !Signature application directory.

 This programme is ShareWare. It can be freely copied and used
 by private users for recreational purposes only. Provided that
 all files are kept unchanged and copied along.

 The 'Message' file can be changed and translated for personal
 use. However you should always keep the original and pass it on.

 The 'List' file can be updated. See below.

 Commercial use of this programme is prohibited.

 Commercial Distribution of this programme is prohibited.

 Public Domain Libraries are not allowed to distribute
 this programme.

 Usage and or distribution which bears profit, by means of
 money, goods, services and alike, to the user is prohibited.

 Any of these foregoing conditions can be lifted by a written
 permission from the author. PD Libs can obtain a special full
 version for distribution by writing a letter to the author.

 If you do not want to fulfil the conditions of use named
 above, please wipe all your copies of this programme.


Files,

  Inside the directory !Signature:

    name:         filetype:  short description:

    !boot         Obey
    !Help         Text       This Help text
    !Run          Obey
    !RunImage     Basic      Main kernel of the programme
    !Sprites      Sprite     System sprites.
   *List          Text       Public list of keys. Update it
                             as new lists of public keys
                             become available.
   *Messages      Text       Messages. Currently english. Feel
                             free to make translations or to
                             improve this one. Send the
                             author a copy please!
    Numbers       Module     Relocatable module doing all
                             the heavy number stuff, from
                             the Acorn User, Sep. 92.
    NumModTxT     Text       Explanation number module.
    prefs         Data       preferences
    RSA           Basic      libary for the coding stuff
    Sprites       Sprites    internal sprites
    Templates     Template   window definitions
    WimpLib       Basic      libary for the wimpy stuff
    words         Text       list of token words.

   *private       Data       this file constains a part of your personal
                             password. Do not copy it along!

Only the files marked with a * may be changed. All files should be
copied along in their original versions.

Version History

Versions: 1.00  First release

          1.01  better editor, more help. Wimp$Scrap improved,
                more hourglasses, default msg-name, autoscroll-tokens,
                bug in export to WL fixed

          1.02  center windows, menu-option from, remove signature, center
                after mode change, escape implemented

          1.03  full release version, more helptext, compact bug with ']'
                removed, preference pane bug removed, more messages, adjust
                on desk-icon, improved error trapping. improved 'assume-sender'
                options. pointer-changes (for RO3 only) implemented.

          1.04  new password coding sheme, better tradeoff between mathematical
                security and 'guess-'secure. This means that only 'exact' token
                words code, others are ignored. See user_103 file!
                Solid-sprite-drag, checking of public list for hard coded key,
                loading window, info on public-keys and list
                Some hints of my brother implemented:
                Menu-icon added to the out tray, rather than that obscure d-clic
                to open the xfer/save-as window and menu-pressing on a menu-icon
                will not yield the normal menu but the specific one.



Please note:

               This is a limited test version.

    A future version will utilize longer code sequences.

          For questions contact the author:

             : Dirk-Willem van Gulik
               Lionsight Residence
               Lipperkerkstraat 290
               7533 AK Enschede
               The Netherlands

               Phone [phone]
               Email [e-mail]
                     [e-mail]


           This programme is uses the

          NUMBERS MODULE version 0.08

  also (C) Copyright Nick Craig-Wood 1992

          who remains the owner of the
           numbers module, see the file
         NumModTxt for any contrains and
             limitations imposed.

*Signature [MQ{>}jeLs^m 6&V95( 9Y_b3q4u 9OY_{q 9XL^]