Cryptography-Digest Digest #972, Volume #12 Sat, 21 Oct 00 19:13:01 EDT
Contents:
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (pgp651)
Re: Dense feedback polynomials for LFSR (Joaquim Southby)
Re: My comments on AES ([EMAIL PROTECTED])
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (pgp651)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (pgp651)
Re: Dense feedback polynomials for LFSR (Joaquim Southby)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (pgp651)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (Guy Macon)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (pgp651)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (Guy Macon)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (Guy Macon)
Re: Hash programs (Cornelius Sybrandy)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (pgp651)
Re: Help identifiing password encryption scheme? ("Ethics")
----------------------------------------------------------------------------
Date: 21 Oct 2000 22:03:16 -0000
From: pgp651 <Use-Author-Address-Header@[127.1]>
Subject: Re: BIOS password, will it protect PC with PGPDisk against tampering ?
=====BEGIN PGP SIGNED MESSAGE=====
It's would make sense to implement this in hardware instead.
Is this hardware or software implementation ?
On Fri, 20 Oct 2000, jungle <[EMAIL PROTECTED]> wrote:
>how this trick works ?
>by intercepting calls to bios from o/s ?
>
>Jonathan wrote:
>>
>> How about strong encrypt the whole system drive with something like safeboot
>> www.controlbreak.nl or safeguard http://www.utimaco.com . With these
>> utilities you can't get acces to the drive period. (even if you try ntfsdos
>> or bios tricks.)
~~~
This PGP signature only certifies the sender and date of the message.
It implies no approval from the administrators of nym.alias.net.
Date: Sat Oct 21 22:03:14 2000 GMT
From: [EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: 2.6.2
iQEVAwUBOfISpE5NDhYLYPHNAQG6bgf9EyIu9ShMN3VqudDSE/RZo+pXjl9wMnHg
/hwpJKKmrRCAciO+TDeEGQy9bZBNssMCGRRzA716W3kS3buKgoXvI73oJMsajarK
+rxfGE7YHVJmADw8aSQTgZCfz7nav9GQqPaeIL/MHXvhEcwVuNKGbJyDYRFvnlkT
/37nVSDq60+WSnJKfVqp2WHJ7653UYgLxH26xY/Y/I8c0J0N+xYNq2jPT+Sk4eHu
SCC1vNJ67v97EFVW0u2+YBZnV/PnbtLZU/mx2BcT4yd7lThOSfsS1FVQa8TiXyWy
nqk9fitZazR/s4o5Im5nPQFn44MT/zAw68nMvh1WPV1x7QDeGDlwHg==
=BbpF
=====END PGP SIGNATURE=====
------------------------------
From: Joaquim Southby <[EMAIL PROTECTED]>
Subject: Re: Dense feedback polynomials for LFSR
Date: 21 Oct 2000 22:01:16 GMT
In article <[EMAIL PROTECTED]> Tim Tyler, [EMAIL PROTECTED] writes:
>Joaquim Southby <[EMAIL PROTECTED]> wrote:
>: In article <[EMAIL PROTECTED]> Tim Tyler, [EMAIL PROTECTED] writes:
>
>:>The original idea makes no sense, but execution time does not appear to be
>:>a problem with it.
>
>: Simply because you fail to grasp an idea or possible applications for it
>: doesn't mean it makes no sense.
>
>True, but not pertinent here.
>
Pertinence is in the mind of those who can imagine.
>
>: I didn't come up with this idea; it was passed on to me from a friend who
>: uses me as a sounding board from time to time. She pointed out that
>: sub-maximal LFSR's have most of the same behaviour as maximal LFSR's. If
>: a maximal length LFSR has a tap sequence of n, A, B, C, then an LFSR with
>: the tap sequence n, n-A, n-B, n-C will also be maximal length. Guess
>: what -- it works for sub-maximal LFSR's, too. The state spaces of two
>: sub-maximal LFSR's constructed in that way and using the same init vector
>: are the same size. [...]
>
>Which might be interesting - if you had provided a method of identifying
>which LFSRs had a large period that does not involve stepping through the
>states one at a time, and noticing when they repeat.
>
>[FWIW, I know such methods exist - but do not know of any useful ones.]
>
>Since this appears to be the best approach you've mentioned, the results
>will not have a guaranteed minimum period greater than what you can step
>through. Consequently, they are only known to offer protection against
>attackers with resources less than or equal to your own.
>
Hmm. I guess I'm making some progress here. In previous posts, you held
that there was no such thing as a guaranteed minimum period.
>Perhaps you would buy such a device. To me it appears to have nothing but
>disadvantages compared to a maximal period LFSR.
>
Sorry to waste your time. Perhaps someday someone will produce something
that fits in better with your approach to protection schemes.
>: One group of behaviours that is dissimilar between the two is how
>: "random" the output stream looks. The output over a period of a
>: maximal-length LFSR will *always* have the same characteristics: a) # of
>: 1's minus # of 0's = 1; [...]
>
># of 1s minus # of 0s = n where n = register width?
>
>From Golomb's "Shift Register Sequences": "In any maximum-length shift
register sequence, there are 2^(n-1) ones and 2^(n-1) -1 zeros." 2^(n-1)
- [2^(n-1)-1] = 1, not n. That book is a fairly basic requirement for
anyone who deals with LFSR's on a more than casual basis.
>: b) the number of runs is strictly quantifiable -- 1/2 of all runs have
>: length 1, 1/4 have length 2, etc.; c) perform a circular shift of some
>: number less than the period on the output string and then XOR the
>: result with the original string -- the result of the XOR will exhibit
>: the same characteristics described in a) and b).
>
>: Conversely, the output over a period of a submaximal-length LFSR is not
>: constrained to these characteristics. (The autocorrelation exhibited in
>: part c is still very strong, though.) In that regard, this output looks
>: more like a random stream of bits because it will statistically vary from
>: the idealized output described above. [...]
>
>No! If anything it looks less like a random stream - since it has a
>shorter period.
>
Take any random stream of 1's and 0's. Are you guaranteed that (# of
1's) - (# of 0's) = 1 in that stream? No. Take the output of a period
of a maximal-length LFSR. Are you guaranteed that
(# of 1's) - (# of 0's) =1 in that stream. Yes. Take the output of a
period of a sub-maximal LFSR. Are you guaranteed that (# of 1's) - (# of
0's) = 1 in that stream? No. No (random) = No (sub-maximal); No
(random) /= Yes (maximal). This logic applies to the other two
randomness postulates.
>: (Before anyone jumps in with the old "what is random" thread, I did not
>: say that the output is random -- I said it looks more like a random
>: stream than that of the maximal-length LFSR.) Can you see any possible
>: uses for a sub-maximal LFSR now?
>
>The idea that its output is less likely to exhibit statistical anomolies
>than a conventional LFSR appears to be false.
>
>Yes, the output over a period is no longer balanced (give or take n 0s)
>- but try writing a statistical test to detect that. The same goes for
>the runs.
>
The tests that would identify the stream as the output of a
maximal-length LFSR have already been written. They are the three
randomness postulates I gave in my previous post. A random stream would
come close to meeting those postulates as would the output of a
sub-maximal LFSR; the max-LFSR stream meets them exactly. If you have a
stream that meets all three postulates exactly, would you conclude that
you'd stumbled onto a perfectly balanced random stream or would you
suspect an LFSR?
>You might as well iterate until you've found the period - a
>test which the non-maximal LFSR will fail first.
>
Sure. I can see this. Let's find the period of the sub-maximal LFSR.
Now let's find the period of the maximal LFSR. OK, that settles it --
the sub-maximal LFSR fails this test. What are you talking about?
>Both algorithms fall equally to Berlekamp-Massey, of course.
>
Why "of course"? Have you tried the algorithm against a sub-maximal
LFSR? Have you ever even tried it against any type of LFSR?
>: These puppies are a lot more interesting than their maximal-length
>: brethren simply because of the wider range of behaviour that, AFAIK,
>: hasn't been explored yet.
>
>Nobody's interested in them - but with good reason. Generally the whole
>point of using an linear counter is to cheaply get some guaranteed long
>cycles. Miss out this property, and what remains is of low utility.
>
Everything but your last statement has been disproved already. Many
people (including some organizations with initials for names) are
interested in these devices. They can produce guaranteed long cycles.
They can be found as the byproduct of testing for maximal-length LFSR's.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: My comments on AES
Date: Sat, 21 Oct 2000 22:00:56 GMT
In article <[EMAIL PROTECTED]>,
Bruce Schneier <[EMAIL PROTECTED]> wrote:
> Recently there was a thread where people discussed my scant comments
> on AES. Those who expected them to appear in Crypto-Gram were
> correct:
>
> http://www.counterpane.com/crypto-gram-0010.html#8
I think that Rijndael won because of "the rules of the game". In
academic cryptanalysis a cipher is considered broken if an academic
attack is discovered (even if it has no practical value whatsoever).
The reasoning is that even an academic attack demonstrates a flaw in
the design of the cipher. Now, all 5 finalists have proven to be
flawless in this sense, i.e. secure according to the accepted wisdom of
academic cryptanalysis. So NIST chose Rijndael because it appeared to
be the most efficient (in speed and resources required in most
platforms) than the other four. It seems to me that Rijndael won fair
and square.
If, as you expect, an academic attack is found against Rijndael in the
next five years, then I believe that it should not be considered secure
and should not be used - and probably will not. Maybe, in retrospect,
NIST should have chosen a back-up AES algorithm after all.
Elsewhere I have suggested a more quantitative methodology for
measuring the strength of ciphers: analyze them at fewer rounds where
attacks are known and compare how fast their resistance to these
attacks grows if more rounds are added. This methodology would have
allowed NIST to compute a ranking of security for the finalists, even
if all are as yet resistant to attacks on their full version.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: 21 Oct 2000 22:16:27 -0000
From: pgp651 <Use-Author-Supplied-Address-Header@[127.1]>
Subject: Re: BIOS password, will it protect PC with PGPDisk against tampering ?
=====BEGIN PGP SIGNED MESSAGE=====
Isn't the time for good key logger ?
To log all activities and store in encrypted form for possible investigation ?
Any suggestions for free key logger that will run in undetected mode and save
all keys in encrypted file on user H/D ?
On Thu, 19 Oct 2000, "bubba" <[EMAIL PROTECTED]> wrote:
>Backdoor BIOS passwords for many computers can be found on the
>net. In addition, I doubt many BIOS password schemes involve
>modern encryption algorithms. But your worry seems legitimate. I
>could build a PGP replacement executable that operated normally
What will happen when intruder will use they copy of PGP, which is not stealth
tampered ?
>and correctly, except that it maintained a stealth list of all passwords
>entered.
>
>
>"pgp651" <Use-Author-Address-Header@[127.1]> wrote in message
>news:[EMAIL PROTECTED]...
>> -----BEGIN PGP SIGNED MESSAGE-----
>>
>> When you need to protect PC [ win95/98 is running on it ] against physical
>> tampering [ to sneak into PC some backdoor software, software key loggers,
>> replacements of encryption binaries ... ] on PC that has wide & open
>> physical access to it, what would be the most cost effective solution ?
>>
>> The people in question are using & are customized with encryption for
>> e-mail, PGP and with hard disk encryption, PGPdisk.
>>
>> They have good protection in case of virus infection, the online active
>> VShield is intercepting all disk activities.
~~~
This PGP signature only certifies the sender and date of the message.
It implies no approval from the administrators of nym.alias.net.
Date: Sat Oct 21 22:16:25 2000 GMT
From: [EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: 2.6.2
iQEVAwUBOfIVu05NDhYLYPHNAQG++Qf+MMn5fkLUVRb592PRfxb4GzmmnfSvvdXg
1vnciQZKpuhHJN5IFKpav6C4whquOnZIu/hKkKAwUY0JRgANO+F9TDPJ2rFSl/HD
VPkeZadOLM9rlbeBXaz8n6rRKtzOoVsuu7YVPyKKtDSeuT+CHhoWMBVsVyRDeNfb
XDe7IPHn8PG6kx+MBdFI+LC9XIhytCYeFSbJWfTPkwT1yVpEqCuQsvWBAsRJVpqe
r9CjJLkyhpZBN5aP2lCfVsGr8YatRyj07rLIFEVGuMTjBzDeucLHE2OsYvvCjwXv
AsNWhs6a7YnPo8broczGaCroHI1v2N3tP7cmfunMo1PrQUTznq4dVg==
=WHAt
=====END PGP SIGNATURE=====
------------------------------
Date: 21 Oct 2000 22:20:27 -0000
From: pgp651 <Use-Author-Supplied-Address-Header@[127.1]>
Subject: Re: BIOS password, will it protect PC with PGPDisk against tampering ?
=====BEGIN PGP SIGNED MESSAGE=====
It does make sense to remove floppy disk drive + use the ANTI Tampering Seal
Tape at the box.
On Fri, 20 Oct 2000, jungle <[EMAIL PROTECTED]> wrote:
>Seeker wrote:
>>
>> > Many modern motherboards use flash, and the battery trick doesn't work.
>>
>> In that case a BIOS decryptor with a boot disk could work.
>
>could work ?
>when the is no floppy drive ?
>
>> Either way, I
>> think the point is that relying on a BIOS password is far from the most
>> secure solution.
>
>why ?
~~~
This PGP signature only certifies the sender and date of the message.
It implies no approval from the administrators of nym.alias.net.
Date: Sat Oct 21 22:20:24 2000 GMT
From: [EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: 2.6.2
iQEVAwUBOfIWq05NDhYLYPHNAQHZ8Af9HqNJAarLNta8FyHMvox815EXQOfbl6UQ
xoU0eSLyVElIxXiboAdm7RtMyEqvJV8ewqHDEJCULiZ1o4JOhr74Xqb7ILr4BPRI
AifmOQchl/4fXJ5qvPcA54W7W+8lIPXH+UlVlrgFm/s6gd3rBFgRk3mTfSt4564s
zBUw9js+xmCNENcUx8M5SrUOuaN7EPWBkqEz5zhKOqjZQRNlYoZYqf43aCtIRQC3
JvvfU7N+YjPVOCdN0DqH9qzazsxwlzKt3mvDHseiVYuQR+l4TwYYTy6+MGRCOiER
FemGJC/mVVC+oKHlS0fG6prvD1xp5N39Yl75l4weBelCoSl7fOVhKA==
=/yP8
=====END PGP SIGNATURE=====
------------------------------
From: Joaquim Southby <[EMAIL PROTECTED]>
Subject: Re: Dense feedback polynomials for LFSR
Date: 21 Oct 2000 22:17:37 GMT
In article <[EMAIL PROTECTED]> Tim Tyler, [EMAIL PROTECTED] writes:
>: I'm curious about your definition of "exhaustive search". [...]
>
>I'm not sure I can be pinned down there.
>
>However, I know that stepping an LFSR repeatedly until it returns to its
>starting state is pretty "exhaustive" method of determining its period -
>in the sense that if you tried it, you would probably soon be exhausted ;-)
>
OK, I see what you're saying. The "search" part threw me since I was
considering this to be a test, not a search.
>:>You're never going to get vary large guaranteed minimum period,
>:
>: As I've said before, some of the state spaces of non-maximal LFSR's can
>: contain almost all the possible state space of the given register --
>: sometimes up to 99% of it. [...]
>
>I don't dispute this - the problem is finding which LFSRs fit into this
>category. If your approach involves iterating through their state spaces
>(as it currently seems to) "you're never going to get vary large
>guaranteed minimum period" - because you'll die before you can verify that
>a large period exists.
>
This depends on what you call a large period. If your idea of building a
fort would be to cast the entire structure out of one piece of material,
I agree with your argument. However, I lean more toward the concept of
using smaller pieces and locking them together to provide protection.
>The idea in cryptography is to defend against opponents who have more
>computational resources than either communications partner.
>
>Defending against attackers who have less comutational resources than
>you do would not be a very compelling result.
>
This is where we differ. I don't look upon this as a game. My guiding
design principles: 1) Provide a defense that is commensurate with the
cost of losses should the defense be penetrated, e.g., don't buy a $1,000
safe to store a dollar bill; and 2) Make the attacker expend resources
that are greater than the sum of the resources I spent on defense plus
what the secrets are worth.
>:>: Advantage: very easy to choose a suitable key. With a sub-maximal LFSR,
>:>: the known init vector is seeded to the LFSR, then the LFSR is clocked a
>:>: number of times equal to the key value before using the stream output.
>:>: Advantage: key can be larger than 2^n since the clock count will
>:>: effectively be the key moduloed by the size of the state space.
>:>
>:>You call discarding much of the information in your key an "advantage"?
>:
>: I misspoke on this; I was thinking of something else similar in nature.
>: The salient point that you missed here is that (key modulo state space)
>: reduces the actual key space to the size of the state space.
>
>To avoid your neglecting the point I raised, what I had a problem with was
>calling this an "advantage" of using non-maximal period LFSRs.
>
You must be awfully eager to reply. I didn't neglect your point; I
agreed with it. Not only that, I improved your argument by pointing out
to you what you had missed -- that they key space of the sub-maximal LFSR
is actually smaller than that of the maximal LFSR.
------------------------------
Date: 21 Oct 2000 22:23:24 -0000
From: pgp651 <Use-Author-Supplied-Address-Header@[127.1]>
Subject: Re: BIOS password, will it protect PC with PGPDisk against tampering ?
=====BEGIN PGP SIGNED MESSAGE=====
On 21 Oct 2000, [EMAIL PROTECTED] (Guy Macon) wrote:
>Seeker wrote:
>>
>>> Many modern motherboards use flash, and the battery trick doesn't work.
>>
>>In that case a BIOS decryptor with a boot disk could work.
>
>..except that you need to enter the BIOS password before you
>can boot...
How BIOS decryptor will work when access to BIOS is blocked ?
>>Either way, I think the point is that relying on a BIOS password
>>is far from the most secure solution.
>
>Agreed. The other point is that it's not as trivial to defeat on
>some modern motherboards than it was in the Good Old Days.
>
>I defeat BIOS passwords by programming a BasicX Stamp (www.basicx.com)
>to emulate a keyboard, and let it run a brute force search in the
>corner for a cople of days (or weeks - some BIOSes make each trial
>take a long time).
For very simple reason this option will not work here, the couple of days option
is just unfeasible.
~~~
This PGP signature only certifies the sender and date of the message.
It implies no approval from the administrators of nym.alias.net.
Date: Sat Oct 21 22:23:23 2000 GMT
From: [EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: 2.6.2
iQEUAwUBOfIXXE5NDhYLYPHNAQErKQf4jbMUb+C3QPE60joOfPvU6AMWfjlIWILT
a52ydoWc6hQyNTGzRP6mJ4TJPEb9xVDI6d1WRSGU/DPOJd+z9UjUVVRuKNXd6Twf
s2sjx9JIsLFgVc1u+Z0+RA6ahZUpKceAmtBhVB3WzNRWXkQth9NnvjxNnQFtfoNu
ugz1gLcr6q9NpY6qob7T9cUYDI8SPg4xRV8WGFSMB3/UOMzdtKKSN5BewK4dL0V+
PXFyAWj9UR3YdjpKpHeKOl5LyazWjUxUlb8fQiRMa7QJJPXp3uEfX6QHJmc4S0P3
3jONK/6t2ssw9gbfvowG+z/3tJAfeh+/6OO6pcTtt7Ni2pAq7tfO
=r7LU
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: BIOS password, will it protect PC with PGPDisk against tampering ?
Date: 21 Oct 2000 22:24:40 GMT
Bottom line:
BIOS passwords alone are an awful solution (a lot less awful if
you pick the right motherboard, totally bogus if you pick the
wrong motherboard), but disabling boot from floppy, setting a
BIOS password for booting, using an OS with logon security
(Linux, Win NT, Win 2000 are Good, Apple OS, Win 95, Win 98,
Win ME are Bad), then using PGPDisk is about as good as it
gets (Not very good) without physical security.
My suggestion (Removable Hard Disk that you take with you
combined with encryption) is a far superior solution.
------------------------------
Date: 21 Oct 2000 22:25:22 -0000
From: pgp651 <Use-Author-Address-Header@[127.1]>
Subject: Re: BIOS password, will it protect PC with PGPDisk against tampering ?
=====BEGIN PGP SIGNED MESSAGE=====
Will these drives run the installed Win95 on them ?
Because all will be encrypted, how this will compare in speed with Win95 on not
encrypted drive ?
Should user expect serious degradation in speed ?
Has this solution admin super key ?
Is the software source code available or is this hardware solution ?
On Fri, 20 Oct 2000, "Jonathan" <[EMAIL PROTECTED]> wrote:
>How about strong encrypt the whole system drive with something like safeboot
>www.controlbreak.nl or safeguard http://www.utimaco.com . With these
>utilities you can't get acces to the drive period. (even if you try ntfsdos
>or bios tricks.)
>
~~~
This PGP signature only certifies the sender and date of the message.
It implies no approval from the administrators of nym.alias.net.
Date: Sat Oct 21 22:25:20 2000 GMT
From: [EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: 2.6.2
iQEVAwUBOfIX0U5NDhYLYPHNAQH4ngf/VJDq4T3/gIPCvzCJSfFaTjatv2B3dH0d
QTYyCkK44r4QzAjLHAyiiZDUGBxocAAV4QlOBZbMNU2nwtyropqmfMaRA1RmXJkH
FS4B3QpRQn6mr8NGlH8AMCmV+9hBYt7TRq4VZDKs/KNC1TvXcqD4n20nts1XQJ+P
JxMR2/ptvD45wX2uL8nA5xVTdPiqybBc7nAUDMTU/thfkz9rjXzKomj1QmaLd4ch
gYnMo+8Yj0lSoIE5R1ZWk7g931ZlyqmjDeGzi5KHkPRU6Kjvs84xNE6mBPGqDRYd
FK15MFC10+89+fHUk14mH2uy7j9zOwq0ELnYIOvMXvNPi9O9hAOrdw==
=erxm
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: BIOS password, will it protect PC with PGPDisk against tampering ?
Date: 21 Oct 2000 22:25:40 GMT
pgp651 wrote:
>
>To prevent this to happen, the ANTI Tampering Seal Tape [ to indicate and not to
>protect ] would be appropriate to visibly indicate to the user that tampering
>occurred.
>
>Will such tape invalidate the BIOS drainage option ?
There is no BIOS drainage option on many modern motherboards.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: BIOS password, will it protect PC with PGPDisk against tampering ?
Date: 21 Oct 2000 22:43:13 GMT
pgp651 wrote:
>
>Guy Macon wrote:
>
>>>Either way, I think the point is that relying on a BIOS password
>>>is far from the most secure solution.
>>
>>Agreed. The other point is that it's not as trivial to defeat on
>>some modern motherboards than it was in the Good Old Days.
>>
>>I defeat BIOS passwords by programming a BasicX Stamp (www.basicx.com)
>>to emulate a keyboard, and let it run a brute force search in the
>>corner for a cople of days (or weeks - some BIOSes make each trial
>>take a long time).
>
>For very simple reason this option will not work here, the couple of days option
>is just unfeasible.
>
Depends. It's good for forgotten passwords. If you have physical
access to the PC, limited time, and are faced with a BIOS password
that lacks the battery.jumper/backdoor password/etc solution, just
pull the hard drive and put it in another computer.
------------------------------
From: Cornelius Sybrandy <[EMAIL PROTECTED]>
Subject: Re: Hash programs
Date: Sat, 21 Oct 2000 18:52:46 -0400
There are already programs that are very similar if not exactly like what you
are looking for. There is AIDE, a freeware tool (No windows version from what I
can see) and Tripwire, a commercial tool. From what it sounds like, there are
more tools than just those. If you look up Tripwire intrusion detection, you
should find what you are looking for.
csybrandy
Archer wrote:
> Hello all. I have an idea for a program and want to know if something like
> it already exists. If so, where can I find it.
>
> Ok, here it goes. Be able to select a file or folder and generate a hash for
> it using a variety of hash algorithms. Then have this hash saved to a file
> that is encrypted. Then, you could come back later and select the same
> folder/file, and see if it has been altered. I know this is the basis of an
> integrity checker program (or intrusion detection). However, what I am
> seeking is something that is much easier to use and have the ability to
> select one single file or an entire partition.
>
> Does this make sense?
>
> I am running Win2k. I know Win2k will audit specific files/folders, this
> would just be another layer of defense.
>
> If something like this does not already exist, would anyone here be
> interested in programming for hire to do it?
>
> Archer
------------------------------
Date: 21 Oct 2000 22:50:15 -0000
From: pgp651 <Use-Author-Address-Header@[127.1]>
Subject: Re: BIOS password, will it protect PC with PGPDisk against tampering ?
=====BEGIN PGP SIGNED MESSAGE=====
Physical security is the most important one. It is the very good solution but
will you ask your user to remove H/D from PC and WHAT ?
- - ask them to take home ?
- - move to central storage place ?
- - another place ?
How this solution could help in the normal time, after boot - up stage has been
completed ?
Would you ask user to take H/D when leaving temporarily her desk ?
- From what I know, they have 2 x H/D in each PC, it could be not very convenient.
On 19 Oct 2000, [EMAIL PROTECTED] (Guy Macon) wrote:
>
>Easy. Go to [ http://www.dirtcheapdrives.com/ ], click on "Dataport"
>[ http://www.dirtcheapdrives.com/welcome_pages/dataport_w/index.html ]
>and take your drive with you when you leave. You can even get a clean
>drive to leave in there for the attacker tp waste time on.
~~~
This PGP signature only certifies the sender and date of the message.
It implies no approval from the administrators of nym.alias.net.
Date: Sat Oct 21 22:50:13 2000 GMT
From: [EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: 2.6.2
iQEVAwUBOfIdpk5NDhYLYPHNAQE9LAf+JHfzZ24fYP89fm7UEAK6xi76u3YphVBH
Ug89iAPotswwzr5AyJTcJ9Y/oGuOKp7PNMEChfOjC0yJttU1kc0f7qY57j4gNW03
ICF8Ti1BYWSnPGE2+p6fYkw9KwLPGZi8BkgiF1cxZDZEFPgEsLDaWdJqaWKlQOCT
1nqmjllhlODONaYTFk0azaf52rSPbQVsgXHRl+ZZdmLGXJESaNBrTv/OMXQUJ/Vo
vu2yW8ohDsxEJW/nn46mnfhBuAZ+bP7b3bcm0a9vFd4c6BGiA8nl6emFk4eB9MkB
RDoMcvc9qDQllY4xyAPi8pym+w9AM/8cfesZnvRVN3GpUbd695SxKg==
=LFHm
=====END PGP SIGNATURE=====
------------------------------
From: "Ethics" <[EMAIL PROTECTED]>
Subject: Re: Help identifiing password encryption scheme?
Date: Sat, 21 Oct 2000 16:09:31 -0700
No kidding... but he left very unsatisfied with his employers, because they
found him drastically breaking their computer policies... so it's not like
he is going to tell us his password.
"jungle" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Ethics wrote:
> ===
> > would be greatly appreciated, as the old BBS sysop up and left,
>
> your best bet would be to find him ...
>
>
>
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
