[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SecureDrive News 8/24/96
-----BEGIN PGP SIGNED MESSAGE-----
SecureDrive Users:
It's been brought to my attention that users who attempt to compile
SecureDrive 1.4b using Turbo C++ 3.00 are haveing a problem in that
the MD5 routine does not produce a correct result, so that the key
generated from a given passphrase will not be the same as the
pre-compiled version. This is a bug in Turbo C++, not SecureDrive!
However, a bypass for the problem is possible by modifying SD source
as follows
- ------------------------------cut here-----------------------
*** C:\SECDR14B\UNC\MD5.C Sun May 09 19:38:36 1993
- --- MD5.C Wed Aug 14 00:58:46 1996
***************
*** 12,17 ****
- --- 12,20 ----
* of the MD5 routines in RSAREF. Due to this alteration, this
* code is "derived from the RSA Data Security, Inc. MD5 Message-
* Digest Algorithm". (See below.)
+ *
+ * Simplified some expressions to avoid incorrect compiles with
+ * some compilers, e.g. Turbo C 3.0 EWS 8/96
*/
/*
***************
*** 135,145 ****
- --- 138,158 ----
/* transform if necessary */
if (mdi == 0x40) {
+ #if defined (__TURBOC__)
for (i = 0, ii = 0; i < 16; i++, ii += 4)
+ {
+ in[i] = (((UINT4)mdContext->in[ii+3]) << 24);
+ in[i] |= (((UINT4)mdContext->in[ii+2]) << 16);
+ in[i] |= (((UINT4)mdContext->in[ii+1]) << 8);
+ in[i] |= ((UINT4)mdContext->in[ii]);
+ }
+ #else
+ for (i = 0, ii = 0; i < 16; i++, ii += 4)
in[i] = (((UINT4)mdContext->in[ii+3]) << 24) |
(((UINT4)mdContext->in[ii+2]) << 16) |
(((UINT4)mdContext->in[ii+1]) << 8) |
((UINT4)mdContext->in[ii]);
+ #endif
Transform (mdContext->buf, in);
mdi = 0;
}
***************
*** 167,178 ****
padLen = (mdi < 56) ? (56 - mdi) : (120 - mdi);
MD5Update (mdContext, PADDING, padLen);
! /* append length in bits and transform */
for (i = 0, ii = 0; i < 14; i++, ii += 4)
in[i] = (((UINT4)mdContext->in[ii+3]) << 24) |
(((UINT4)mdContext->in[ii+2]) << 16) |
(((UINT4)mdContext->in[ii+1]) << 8) |
((UINT4)mdContext->in[ii]);
Transform (mdContext->buf, in);
/* store buffer in digest */
- --- 180,201 ----
padLen = (mdi < 56) ? (56 - mdi) : (120 - mdi);
MD5Update (mdContext, PADDING, padLen);
! /* append length in bits and transform 1.4c*/
! #if defined (__TURBOC__)
! for (i = 0, ii = 0; i < 14; i++, ii += 4)
! {
! in[i] = (((UINT4)mdContext->in[ii+3]) << 24);
! in[i] |= (((UINT4)mdContext->in[ii+2]) << 16);
! in[i] |= (((UINT4)mdContext->in[ii+1]) << 8);
! in[i] |= ((UINT4)mdContext->in[ii]);
! }
! #else
for (i = 0, ii = 0; i < 14; i++, ii += 4)
in[i] = (((UINT4)mdContext->in[ii+3]) << 24) |
(((UINT4)mdContext->in[ii+2]) << 16) |
(((UINT4)mdContext->in[ii+1]) << 8) |
((UINT4)mdContext->in[ii]);
+ #endif
Transform (mdContext->buf, in);
/* store buffer in digest */
- ------------------------------cut here-----------------------
This code will be inserted into any future version of SecureDrive,
but no new release is planned at this time.
For those users of Win95 and SecureDrive who are concerned about loss
of 32-bit disk access, I've recently learned that use of Secure Device
ftp.demon.co.uk:/pub/ibmpc/secdev/secdev14.arj
instead avoids this requirement. Although the Secure Device virtual
drive is listed as in compatibility mode, the real drives are not so
affected. And since the virtual drive is mapped to a dos file on one
of the real drives, I believe you get 32-bit phyical drive access
there as well, although access is still slowed by CPU time necessary
to encrypt and decrypt.
Edgar W. Swank <[email protected]>
Edgar W. Swank <[email protected]>
Edgar W. Swank <[email protected]>
Home Page: http://members.tripod.com/~EdgarS/index.html
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCUAwUBMh7d4t4nNf3ah8DHAQHNdAP3RKd07B55fkW5CazT8mMaGUoTtjxSvUBv
3ykPvBhHvu7egb4EB1/XcBTM3K/6QeE8Dt10XJVX15Fd9nHY+XI0c0VB8Trlb/NB
0ymq+/SchedtUNmCgDeycbF104bfirpuXKy0OChDfpgMe0d/ifCXny6Co0BqIbRi
fQyKtXzOxQ==
=h1RT
-----END PGP SIGNATURE-----
--
[email protected] (Edgar Swank)
The Land of Garg BBS -- +1 408 378-5108