Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Cobol and encryption
- Thread starter TLudwig
- Start date
> Has anybod experience in doing password encryption in standard cobol ...
I did a calculation on a name, date etc. and a series of Y/N values, pushing the alpha characters into num fields by calculation like in a banking account number, where the position in the string influences the calculation, translated that to a non-10 based number (i think it was 24-based, 0..9,A..Q or a bit like that). Transposed the result by a pseudo-random table to a new string, and chopped that into manageable pieces (5/7 chars) This is presented in my license-form, and together with the original name, results in the correct Y/N options set.
A method like this could be used in any language, so why not in cobol. The hard part is to device a calculation that's not to obviously reversible. If I change 1 char in the name or date entered, a lot of digits in the key change, so I concluded it's difficult enough to crack. The market where it's to be used is small and sophisticated enough, not to even try to break this, so ;-)
> The solution must run on NT/WIN2000 and also on the mainfraime.
Just write it in cobol, compatible with ansi 85 or 92 standards, can't miss ;-) If you have used both Windows and unix or MVS compilers, you probably know the quirks that separate the platform dependent compilers, and how to avoid problems, if there are any. Usually the supplier of the compiler can inform about any known differences.
HTH
TonHu
I did a calculation on a name, date etc. and a series of Y/N values, pushing the alpha characters into num fields by calculation like in a banking account number, where the position in the string influences the calculation, translated that to a non-10 based number (i think it was 24-based, 0..9,A..Q or a bit like that). Transposed the result by a pseudo-random table to a new string, and chopped that into manageable pieces (5/7 chars) This is presented in my license-form, and together with the original name, results in the correct Y/N options set.
A method like this could be used in any language, so why not in cobol. The hard part is to device a calculation that's not to obviously reversible. If I change 1 char in the name or date entered, a lot of digits in the key change, so I concluded it's difficult enough to crack. The market where it's to be used is small and sophisticated enough, not to even try to break this, so ;-)
> The solution must run on NT/WIN2000 and also on the mainfraime.
Just write it in cobol, compatible with ansi 85 or 92 standards, can't miss ;-) If you have used both Windows and unix or MVS compilers, you probably know the quirks that separate the platform dependent compilers, and how to avoid problems, if there are any. Usually the supplier of the compiler can inform about any known differences.
HTH
TonHu
This is the way I did it:
The encoded password is saved. Then the password entered by the user is encoded and compared to the saved encoded password. The encoded password can not be decrypted as data is lost during the encoding.
Code:
01 WS-PASSWORD PIC X(08).
01 redefines WS-PASSWORD.
05 WS-PASS-1 PIC 9(08) COMP.
05 WS-PASS-2 PIC 9(08) COMP.
01 OVERLAY-MASK PIC 9(08) COMP Value 31459987.
01 ENCODED-PW PIC X(04).
01 redefines ENCODED-PW.
05 EPW-BIN PIC 9(08) COMP.
. . . . .
ENCODE-PASSWORD.
MULTIPLY WS-PASS-1, WS-PASS-2, OVERLAY-MASK
GIVING EPW-BIN.Webrabbit,
I like that ever so much! It's quick, clever, and easy. The only question I have about it is the size of the EPW-BIN only being 9(8) COMP. Surely if you're multiplying 3 9(8) COMP fields, with a potential for two of them to be very high numbers, then you need to increase the size of EPW-BIN?
Marc
I like that ever so much! It's quick, clever, and easy. The only question I have about it is the size of the EPW-BIN only being 9(8) COMP. Surely if you're multiplying 3 9(8) COMP fields, with a potential for two of them to be very high numbers, then you need to increase the size of EPW-BIN?
Marc
- Status
Similar threads
