Re: encrypting files
From: Michael Amling (nospam_at_nospam.com)
Date: 05/14/04
- Next message: Michael Amling: "Re: enigma machine and related questions"
- Previous message: Tom St Denis: "Re: Protection from Tempest attacks"
- In reply to: Bob Jenkins: "encrypting files"
- Next in thread: Ernst Lippe: "Re: encrypting files"
- Reply: Ernst Lippe: "Re: encrypting files"
- Reply: Bob Jenkins: "Re: encrypting files"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 14 May 2004 13:37:29 GMT
Bob Jenkins wrote:
> I'm doing some serious wheel-reinvention, writing a command-line
> utility to encrypt files. So far, though, it's been educational.
>
> * Block ciphers are better than stream ciphers because they thwart
> attackers who know the plaintext from changing the encrypted file
> meaningfully.
As noted elsewhere, you need to use a MAC or digital signature to
detect changes, regardless of mode. Or use an authenticating mode (such
as OCB if you can get a license).
>
> * There should be a different salt for each encryption so that the
> same text will encrypt to different things every encryption.
> Particularly an issue for multiple revisions of the same file.
>
> * To reduce the burden on the user, the salt should be internally
> generated and stored with the encrypted file. This means the utility
> has to distinguish between encrypting and decrypting. (I'm currently
> favoring the date down to the current second plus the input file name
> as the salt. Is there any point in keeping the salt secret?)
Why not just pick the salt at random?
>
> * Encrypted and decrypted files will be different sizes because the
> salt has to be prepended to the encrypted file. Since the filesize
> can't be preserved anyhow, compressing before encryption and/or ASCII
> encoding after encryption look attractive.
>
> * The password shouldn't appear on the screen. In C there's a library
> routine, passwd = getpass("password:"), for that.
>
> * In C, stdin and stdout are character streams, which behave poorly in
> the presence of binary data. Either I don't use pipes (I only
> read/write files), or the encrypted data has to be ASCII encoded.
stdin and stdout work just fine for binary data. Try
gzip <myfavoritefile >mfvrtfl
for a demonstration of binary data on stdout,
gunzip <mfvrtfl >myfavoritefile
for a demonstration of binary data on stdin, and
gzip <myfavoritefile | gunzip >alsofavorite
for a demonstration of binary data through a pipe.
--Mike Amling
- Next message: Michael Amling: "Re: enigma machine and related questions"
- Previous message: Tom St Denis: "Re: Protection from Tempest attacks"
- In reply to: Bob Jenkins: "encrypting files"
- Next in thread: Ernst Lippe: "Re: encrypting files"
- Reply: Ernst Lippe: "Re: encrypting files"
- Reply: Bob Jenkins: "Re: encrypting files"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
