Board index Linux Applications

help: security with encryption?

help: security with encryption?

Post by Robert Hamilto » Sat, 22 Jun 1996 04:00:00



I was experimenting with TEA (Tiny Encryption Algorithm), and wrote
a nice little utility.  But it occurs to me that this kind of thing
is useless unless all the back doors are closed.  Specifically, one
should consider the worst case that "bad guys" can watergate the
computer at some inconvenient time, steal the hard drive, and turn it
over to a kernel expert, who attempts to recover the key.

 So, being a newcommer to Linux, I thought I'd ask the experts:

1) What's the easiest/best way to ensure that no part of the executable
or data gets swapped to the hard-drive?  (Suppose I'm not root.)

2) How can you make sure that disk buffers and keyboard buffers are
wiped clean before the program exits?

3) Is it possible to make completely certain that the physical area
on disk, where the original plain text resides, is wiped completely
clean?

4)How can one prevent evil user from scanning the physical memory
when the utility is resident and running?

5) Are there any other back doors that I've missed?

(There might be obvious answeres to these; but knowing nothing about
the file system, I'd rather not take any chances :)

Thanks in advance,
Robert

 
 
 
Top

help: security with encryption?

Post by Ralf W. Steph » Sun, 23 Jun 1996 04:00:00


Quote:Robert Hamilton writes:
> 5) Are there any other back doors that I've missed?

Yes.  If you close all 4 doors above there is still the possibility
the spooks could have bugged your keyboard or a van with big EM
equipment is standing 100m from your house.

PC's are unsafe.  Don't fool yourself.

But then, to be constructive, what about the idea of bypassing keyboard
input by using some sort of programmable dongle that holds the key,
like putting the card in a bank-o-mat?  This could increase physical
security of PCs.

ralf

 
 
 
Top

help: security with encryption?

Post by Joe Bu » Tue, 25 Jun 1996 04:00:00



>I was experimenting with TEA (Tiny Encryption Algorithm), and wrote
>a nice little utility.  But it occurs to me that this kind of thing
>is useless unless all the back doors are closed...
> So, being a newcommer to Linux, I thought I'd ask the experts:

The issues are similar in all Unix and Unix-like systems.

Quote:>1) What's the easiest/best way to ensure that no part of the executable
>or data gets swapped to the hard-drive?  (Suppose I'm not root.)

Currently there isn't a way.  There's work being done on POSIX 1b
calls that can lock pages in memory; it's necessary to decide policy
for non-root users.

Quote:>2) How can you make sure that disk buffers and keyboard buffers are
>wiped clean before the program exits?

There really isn't a way to do this (for disk buffers, you may be
able to prevent sensitive data from ever hitting the disk though).

Quote:>3) Is it possible to make completely certain that the physical area
>on disk, where the original plain text resides, is wiped completely
>clean?

Depends on how paranoid you are.  It isn't enough just to zero the data,
because if a really determined opponent can get hold of your hard disk,
they can still get data off it even if you've zeroed it (since the
underlying disk hardware is analog not digital).

Quote:>4)How can one prevent evil user from scanning the physical memory
>when the utility is resident and running?

If the evil user is root, no way.

Quote:>5) Are there any other back doors that I've missed?

While the user is typing, EM radiation sent out by the keyboard can
be detected by a nearby bad guy who can decode what is being typed
without any physical connection to your machine at all.  The junkier
the keyboard, the more of this kind of leakage.

Quote:>(There might be obvious answeres to these; but knowing nothing about
>the file system, I'd rather not take any chances :)

Go to sci.crypt where the experts hang out.

--

Work for something because it is good,
not just because it stands a chance to succeed.    -- Vaclav Havel

 
 
 
Top

1. Password encryption in Ultrix enhanced security

Does anybody know how the password is encrypted on an Ultrix system
with enhanced security? I intend to run crack or something similar
on our user database, but I need to modify the program to check the
particular format of the encrypted password found on this system.

Of course, I can use the system call authenticate_user(), but I guess
that this will be pretty slow, because the call reads both the passwd
file, the auth database, and the ttys file, possibly opening and closing
them for each call.

So, it will be much faster, if I could just generate the encrypted
password from the guess. The encrypted password consists of 24
characters, apparently upper and lower case letters, digits, slash,
and period, so I guess that 6 bits are stored in each character, but
for the rest, I am at complete loss. I am not good at decoding MIPS
machine code either, so I can't reverse engineer the stuff from the
object code.

Any help is appreciated. Please reply by email, I'll summarize.

Karsten
--
Karsten Spang                       Snail Mail:  Kampsax Technology

WWW:    http://www.kampsax.dk/~krs               Denmark
Phone: +45 36 39 08 00   Fax: +45 36 77 03 01    DK-2650 Hvidovre

2. LILO with DOS and Coherent

3. US-OFFSITE NETWORK SECURITY AUTHOR/INSTRUCTOR (FIREWALLS ENCRYPTION), LEARNING TREE INTERNATIONAL

4. parrellel port networking w/ win98

5. Is WEP the most secure encryption in wireless network security?

6. SuSE Linux 6.2 - Voodoo Banshee Problem

7. new encryption system promises high security

8. configuration X 600*800

9. Password Security through Encryption

10. US-CA-Palo Alto-Encryption/Network Security SW Eng.

11. security or encryption

12. Security, encryption for the POST method without CA

13. Security, encryption for the POST method


All times are UTC
Board index