/****************************************************************************
* *
* File Stream I/O Functions *
* Copyright Peter Gutmann 1993-2007 *
* *
****************************************************************************/
#if defined( __UNIX__ ) && defined( __linux__ )
/* In order for the fileReadonly() check to work we need to be able to
check errno, however for this to work the headers that specify that
threading is being used must be the first headers included
(specifically, the include order has to be pthread.h, unistd.h,
everything else) or errno.h, which is pulled in by stdlib.h, gets
set up as an extern int rather than a function */
#include "crypt.h"
#endif /* Older Linux broken include-file dependencies */
#include <stdarg.h>
#if defined( INC_ALL )
#include "stream_int.h"
#include "file.h"
#else
#include "io/stream_int.h"
#include "io/file.h"
#endif /* Compiler-specific includes */
/* In order to get enhanced control over things like file security and
buffering we can't use stdio but have to rely on using OS-level file
routines, which is essential for working with things like ACL's for
sensitive files and forcing disk writes for files we want to erase.
Without the forced disk write the data in the cache doesn't get flushed
before the file delete request arrives, after which it's discarded rather
than being written, so the file never gets overwritten. In addition some
embedded environments don't support stdio so we have to supply our own
alternatives.
When implementing the following for new systems there are certain things
that you need to ensure to guarantee error-free operation:
- File permissions should be set as indicated by the file open flags.
- File sharing controls (shared vs. exclusive access locks) should be
implemented.
- If the file is locked for exclusive access, the open call should either
block until the lock is released (they're never held for more than a
fraction of a second) or return CRYPT_ERROR_TIMEOUT depending on how
the OS handles locks.
When erasing data, we may run into problems on embedded systems using
solid-state storage that implements wear-levelling by using a log-
structured filesystem (LFS) type arrangement. These work by never
writing a sector twice but always appending newly-written data at the
next free location until the volume is full, at which point a garbage
collector runs to reclaim. A main goal of LFS's is speed (data is
written in large sequential writes rather than lots of small random
writes) and error-recovery by taking advantage of the characteristics
of the log structure, however a side-effect of the write mechanism is
that it makes wear-levelling management quite simple. However, the use
of a LFS also makes it impossible to reliably overwrite data, since
new writes never touch the existing data. There's no easy way to cope
with this since we have no way of telling what the underlying media is
doing with our data. A mediating factor though is that embedded systems
are usually sealed, single-use systems where the chances of a second user
accessing the data is low. The only possible threat then is post system-
retirement recovery of the data, presumably if it contains valuable data
it'll be disposed of appropriately */
/* Symbolic defines for stdio-style file access modes */
#if defined( DDNAME_IO )
#pragma convlit( suspend )
#define MODE_READ "rb,byteseek"
#define MODE_WRITE "wb,byteseek,recfm=*"
#define MODE_READWRITE "rb+,byteseek,recfm=*"
#pragma convlit( resume )
#else
#if defined( EBCDIC_CHARS )
#pragma convlit( suspend )
#define MODE_READ "rb"
#define MODE_WRITE "wb"
#define MODE_READWRITE "rb+"
#pragma convlit( resume )
#else
#define MODE_READ "rb"
#define MODE_WRITE "wb"
#define MODE_READWRITE "rb+"
#endif /* EBCDIC_CHARS */
#endif /* Standard vs. DDNAME I/O */
/****************************************************************************
* *
* Utility Functions *
* *
****************************************************************************/
/* Append a filename to a path and add the suffix */
CHECK_RETVAL STDC_NONNULL_ARG( ( 1, 3, 4 ) ) \
static int appendFilename( OUT_BUFFER( pathMaxLen, *pathLen ) char *path,
IN_LENGTH_SHORT const int pathMaxLen,
OUT_LENGTH_SHORT_Z int *pathLen,
IN_BUFFER( fileNameLen ) const char *fileName,
IN_LENGTH_SHORT const int fileNameLen,
IN_ENUM( BUILDPATH_OPTION ) \
const BUILDPATH_OPTION_TYPE option )
{
const int partialPathLen = strlen( path );
assert( isWritePtr( path, pathMaxLen ) );
assert( isWritePtr( pathLen, sizeof( int ) ) );
assert( isReadPtr( fileName, fileNameLen ) );
REQUIRES( pathMaxLen > 8 && pathMaxLen < MAX_INTLENGTH_SHORT );
REQUIRES( fileNameLen > 0 && fileNameLen < MAX_INTLENGTH_SHORT );
REQUIRES( option > BUILDPATH_NONE && option < BUILDPATH_LAST );
/* Clear return value */
*pathLen = 0;
#ifdef EBCDIC_CHARS
#pragma convlit( suspend )
#endif /* EBCDIC_CHARS */
/* If we're using a fixed filename it's quite simple, just append it
and we're done */
if( option == BUILDPATH_RNDSEEDFILE )
{
if( partialPathLen + 12 > pathMaxLen )
return( CRYPT_ERROR_OVERFLOW );
memcpy( path + partialPathLen, "randseed.dat", 12 );
*pathLen = partialPathLen + 12;
return( CRYPT_OK );
}
/* User-defined filenames are a bit more complex because we have to
safely append a variable-length quantity to the path */
if( partialPathLen + fileNameLen + 4 > pathMaxLen )
return( CRYPT_ERROR_OVERFLOW );
memcpy( path + partialPathLen, fileName, fileNameLen );
memcpy( path + partialPathLen + fileNameLen, ".p15", 4 );
*pathLen = partialPathLen + fileNameLen + 4;
#ifdef EBCDIC_CHARS
#pragma convlit( resume )
#endif /* EBCDIC_CHARS */
return( CRYPT_OK );
}
/****************************************************************************
* *
* AMX File Stream Functions *
* *
****************************************************************************/
#if defined( __AMX__ )
/* Open/close a file stream */
CHECK_RETVAL STDC_NONNULL_ARG( ( 1, 2 ) ) \
int sFileOpen( INOUT STREAM *stream, IN_STRING const char *fileName,
IN_FLAGS( FILE ) const int mode )
{
static const int modes[] = {
FJ_O_RDONLY, FJ_O_RDONLY,
FJ_O_WRONLY | FJ_O_CREAT | FJ_O_NOSHAREANY,
FJ_O_RDWR | FJ_O_NOSHAREWR
};
assert( isWritePtr( stream, sizeof( STREAM ) ) );
assert( fileName != NULL );
REQUIRES( mode != 0 );
/* Initialise the stream structure */
memset( stream, 0, sizeof( STREAM ) );
stream->type = STREAM_TYPE_FILE;
if( ( mode & FILE_FLAG_RW_MASK ) == FILE_FLAG_READ )
stream->flags = STREAM_FLAG_READONLY;
openMode = modes[ mode & FILE_FLAG_RW_MASK ];
/* If we're trying to write to the file, check whether we've got
permission to do so */
if( ( mode & FILE_FLAG_WRITE ) && fileReadonly( fileName ) )
return( CRYPT_ERROR_PERMISSION );
/* Try and open the file */
stream->fd = fjopen( fileName, openMode, ( openMode & FJ_O_CREAT ) ? \
FJ_S_IREAD | FJ_S_IWRITE : 0 );
if( stream->fd < 0 )
{
const int errNo = fjfserrno();
return( ( errNo == FJ_EACCES || errNo == FJ_ESHARE ) ? \
CRYPT_ERROR_PERMISSION : \
( errNo == FJ_ENOENT ) ? \
CRYPT_ERROR_NOTFOUND : CRYPT_ERROR_OPEN );
}
return( CRYPT_OK );
}
RETVAL STDC_NONNULL_ARG( ( 1 ) ) \
int sFileClose( INOUT STREAM *stream )
{
assert( isWritePtr( stream, sizeof( STREAM ) ) );
REQUIRES( stream->type == STREAM_TYPE_FILE );
/* Close the file and clear
没有合适的资源?快使用搜索试试~ 我知道了~
CryptLib3.32加密算法库
共784个文件
c:308个
h:103个
p7s:101个
需积分: 30 45 下载量 65 浏览量
2009-02-08
21:58:00
上传
评论 2
收藏 4.04MB ZIP 举报
温馨提示
Cryptlib实现了各种公开密钥算法、对称加密算法、数字签名算法、信息摘要算法以及其相关的其它算法等等。它采用C++语言编写而成,因为是面向对象语言,所以对于初学者来说更容易理清其结构。该库没有提供应用程序,只是作为库函数提供应用。因为基于C++面向对象的思想,其算法的剥离相对于openssl来说可能更加容易。对于不需要涉及SSL协议的技术人员来说,使用该库函数应用是一个不错的选择。
资源推荐
资源详情
资源评论
收起资源包目录
CryptLib3.32加密算法库 (784个子文件)
pubkey1.asc 2KB
pubkey2.asc 2KB
pubkey3.asc 2KB
certchn1.asc 1KB
cert1.asc 792B
sshkey2.asc 662B
sshkey1.asc 356B
d-win32.asm 56KB
bn-win32.asm 47KB
bn-win32n.asm 45KB
aes_x86_v2.asm 35KB
rm-win32.asm 30KB
s1-win32.asm 28KB
aes_amd64.asm 27KB
gvmat32.asm 27KB
gvmat32y.asm 26KB
c-win32.asm 16KB
inffas32y.asm 16KB
aes_x86_v1.asm 16KB
gvmat64y.asm 15KB
b-win32.asm 14KB
m5-win32.asm 11KB
inffasx64y.asm 10KB
r5-win32.asm 9KB
r4-win32.asm 5KB
cryptlib.asn 31KB
cryptlib.bas 79KB
file.c 179KB
attr_acl.c 150KB
python.c 150KB
ms_capi.c 131KB
cryptapi.c 128KB
envelope.c 127KB
java_jni.c 124KB
ext_def.c 112KB
fortezza.c 108KB
certs.c 94KB
tcp.c 88KB
msg_acl.c 83KB
comp_set.c 80KB
comp_get.c 80KB
pkcs11_rw.c 78KB
write.c 77KB
win32.c 76KB
ssh.c 74KB
unix.c 73KB
devices.c 73KB
dumpasn1.c 72KB
ssh1.c 70KB
sendmsg.c 67KB
keyfile.c 67KB
pkcs11_pkc.c 65KB
deflate.c 65KB
odbc.c 65KB
ssl.c 65KB
ext_rd.c 64KB
dn.c 62KB
cmp_rd.c 62KB
cmp.c 61KB
ssh2_msg.c 60KB
os_spec.c 60KB
utils.c 59KB
pkcs11.c 57KB
env_attr.c 57KB
s_cmp.c 57KB
asn1_rd.c 56KB
cryptcrt.c 55KB
chain.c 55KB
pgp_denv.c 54KB
ssh2_cli.c 53KB
key_rd.c 53KB
pkcs11_init.c 53KB
highlvl.c 53KB
http_parse.c 52KB
ssl.c 51KB
cms_env.c 51KB
ldap.c 51KB
random.c 51KB
loadkey.c 51KB
decode.c 50KB
inflate.c 50KB
stream.c 48KB
chk_cert.c 48KB
testlib.c 48KB
res_denv.c 47KB
read.c 47KB
imp_exp.c 46KB
cms_denv.c 46KB
user.c 45KB
ssl_rw.c 44KB
cryptkey.c 44KB
mech_pkwrap.c 43KB
trees.c 43KB
timing.c 43KB
sreqresp.c 42KB
ssh2_svr.c 41KB
ssh2_cry.c 41KB
certimp.c 41KB
certrev.c 40KB
cmp_wr.c 40KB
共 784 条
- 1
- 2
- 3
- 4
- 5
- 6
- 8
资源评论
martica
- 粉丝: 0
- 资源: 1
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功