Cryptography-Digest Digest #971, Volume #12 Sat, 21 Oct 00 18:13:01 EDT
Contents:
Re: Entropy and RC4 ("Scott Fluhrer")
Re: Storing an Integer on a stream (SCOTT19U.ZIP_GUY)
Re: My comments on AES (SCOTT19U.ZIP_GUY)
Bezozs and bountyquest.com ("Paul Pires")
Visual Basic ("binary digit")
Help identifiing password encryption scheme? ("Ethics")
Quasi philosphical question regarding Index of Coincidence ([EMAIL PROTECTED])
Re: Help identifiing password encryption scheme? (jungle)
another problem question (Ernest Dumenigo)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (Guy Macon)
Re: Dense feedback polynomials for LFSR (Tim Tyler)
Re: Dense feedback polynomials for LFSR (Joaquim Southby)
Re: Storing an Integer on a stream (Tim Tyler)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (pgp651)
Re: Visual Basic (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 ? (pgp651)
Re: My comments on AES (Tim Tyler)
Re: xor algorithm (Tim Tyler)
----------------------------------------------------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Entropy and RC4
Date: Sat, 21 Oct 2000 09:42:46 -0700
George Gordon <[EMAIL PROTECTED]> wrote in message
news:rOHH5.120$[EMAIL PROTECTED]...
> Other people have asked similar questions here, but let me ask a very
> specific one.
>
> Assume that you initialise RC4 using a 128-bit key. Then you output
exactly
> 16 bytes worth of the stream. (I don't care how many loops you do for the
> initialisation)
>
> OK, how could you determine how much of the entropy in the 128-bit key is
> preserved in the 16 byte stream if 1) you assume RC4 specifically? 2)
you
> assume a perfectly uniform distribution?
I don't know about RC4 in particular (and I seriously doubt anyone else does
either), but if you model the process by a uniformly chosen random function
from 128 bits to 128 bits, then it's not difficult.
If you have a full 128 bits of entropy coming in (that is, each bit pattern
has probability 2**-128), then you should have an expected 127.1728
(approximately) bits of entropy coming out.
You can see this by observing that, for a random function from 2**128 ->
2**128, then for small k, then you would expect approximately 2**128/(e *
k!) outputs that have precisely k preimages (where e = 2.718281828...).
This approximation becomes worse as k becomes larger, but 2**128 is
sufficiently large that by the time k becomes large enough to make the
approximation invalid, the number of expected outputs is sufficiently small
not to affect the result materially.
Or, in other words, for each k, there are approximately 2**128/(e * k!) with
probability k2**(-128)
Then, we apply that standard definition for entropy:
E = Sum{ p_i lg( p_i )) }
(where lg is logarithm base 2). Combining equal terms, and summing over k,
we get:
E = Sum( 2**128/(e * k!) * k2**(-128) / lg( k2**(-128) ) )
k
The k=0 term can be ignored, and the rest can be computed to give the above
number.
--
poncho
--
poncho
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.compression
Subject: Re: Storing an Integer on a stream
Date: 21 Oct 2000 17:01:38 GMT
[EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>: Andras Erdei wrote:
>
>:> The method i like most is fibonacci coding:
>:>
>:> - start with the largest fib number smaller than your integer
>:>
>:> - if the current fib number is smaller than your number
>:> substitute it and write down 1
>:> else
>:> write down 0
>:> - take the next fib number
>:>
>:> Example:
>:>
>:> number: 15
>:> fib: 1,1,2,3,5,8,13
>:> encoding: 13+2 -> 0010001
>:>
>:> This way you encoded your (arbitrarily big number) in a way that
>:> there are *no consecutive 1s* in the encoding, and it ends with 1;
>:> so you can append an additional 1 and thus make it a prefix code.
>:>
>:> result: 00100011
>:>
>:> IIRC this encoding is asimptotically optimal.
>
>"Severly sub-optimal" is how I would describe it, especially in the
>context of padding schemes.
>
>Padding with a format that can't use repeated 1s could only ever be
>anywhere near optimal for small values.
>
>Since when larger and larger values are used, methods which can use a
>greater range of symbols will systematically trounce it, it's hard to see
>how it could be described as "asymtotically optimal".
It reminds me of the work I use to do on interial guidance systems
I wrote a lot of algorithms that worked. My cohrots use to find artices
in the "IEEE" or like journals telling how they did some optimal
crap and my workmates would laugh and say gee they almost got it right
to bad that can't see the code your wrote so that maybe they could get
it right. When I won the EDN desing award one time some professor
use to tell my when other later invented subsets of the method I did.
He claims he taught it in his class but I long forgot his name. But in
academia things get inveted over and over again. But when some
one in Acedeamia finally gets the balls to copy it to some insiders
journal they get the credit not the numberous indivduals who used
it before. Sort of like when a "scientist" desicovers a new animal
that people in a region have been using as food for generations. Yet
the scientest get the credit for the "discovery".
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: My comments on AES
Date: 21 Oct 2000 17:17:26 GMT
[EMAIL PROTECTED] (Mok-Kong Shen) wrote in <39F1C560.EBFB6A56@t-
online.de>:
>
>
>Tim Tyler wrote:
>>
>
>>
>> How about the bit where he wrote (from the URL above):
>>
>> ``I believe that within the next five years someone will discover an
>> academic attack against Rijndael.''
>
>However, if an academic attack is only of interest
>academically and not a genuine menace in practice, then
>that would be only a happy and laudable success of some
>intellectual endeavour, nothing more.
>
>M. K. Shen
>
Actaully it is not only of academical interest. It would
place an upper limit on how secure the method was and would
lead many to belive that once one such limit is found others
may make further advacnes bringing the limit down even more.
Have any limit one then could use it as a yard stick to
compare against others. Untill better rules are made.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Bezozs and bountyquest.com
Date: Sat, 21 Oct 2000 10:25:27 -0700
Off Topic so I'll keep it short.
Those interested in Patent reform and killing bad patents
based on prior art should look at this site.
this http://www.bountyquest.com/
Paul
------------------------------
From: "binary digit" <[EMAIL PROTECTED]>
Subject: Visual Basic
Date: Sat, 21 Oct 2000 20:18:48 GMT
Anyone know where I can find some encryption algorithms that have been coded
in Vb and have good documentation on them?
------------------------------
From: "Ethics" <[EMAIL PROTECTED]>
Subject: Help identifiing password encryption scheme?
Date: Sat, 21 Oct 2000 13:26:34 -0700
Sirs,
I am the trying to figure out the encryption scheme that WildCat! 4 BBS
uses to encrypt the password files in it's user databases. I would greatly
appreciate any information on grabbing an encryption scheme form inside a
program, or on how to identify an encryption scheme. The encrypted
passwords are from 12-15 characters in length, include upper and lowercase
characters, and almost every special character on the keyboard. Any help
would be greatly appreciated, as the old BBS sysop up and left, and we have
a database of over 5000 users, which we cannot administer without that
sysop's password.
Thank You,
Nick Jacobsen,
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Quasi philosphical question regarding Index of Coincidence
Date: Sat, 21 Oct 2000 20:23:11 GMT
Or perhaps I should have titled the message "Quasi Philosphical Question
Regarding Captal Letters"
The question is this:
If your faced with a cryptogram which includes both upper and lower case
letters, who would you calc the IC? Would you first convert all the
letters to one case and look only at frequency? Or do you consider "I"
as a seperate symobol from "i"?
I'm curious how much the derived stat is "thrown off" by assuming the
English alphabet has 52 charaters rather than 26?
Any ideas?
--
"Wife who put husband in doghouse, soon find him in cathouse."
-- Wisdom of the Tao
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: jungle <[EMAIL PROTECTED]>
Subject: Re: Help identifiing password encryption scheme?
Date: Sat, 21 Oct 2000 16:42:36 -0400
Ethics wrote:
===
> would be greatly appreciated, as the old BBS sysop up and left,
your best bet would be to find him ...
------------------------------
From: [EMAIL PROTECTED] (Ernest Dumenigo)
Subject: another problem question
Date: 21 Oct 2000 20:51:56 GMT
I have another problem I have been working on, and I think I have part of
it but again I am stuck and not sure if I am on the right track or am
completely lost.
The instructions are: "The following badly garbled cryptogram was
intercepted. Reconstruct the original plaintext message, resolving the
errors and omissions, and indicate the specific key.
HUVSH UDSU- EKHCU IEQWU DK-RU HOXHU UUYMX JIU-U DTQJU TEDUA YNTUS
===== IJEFY DIJKH SJYE= IOQLU RUUNY IIKU= JEQBD IKRHE TYDQJ =SECC Q=TIJ
EYDYW YQJUK DYJJH QYDCD WFHEW HQKIK DTUHJ XAFHE RYIYE DIEVF
QHQMH QUXJ- EEV-F -SYQB THTUH IDMCR UHIYT
What I have done is: 1) statistical analysis which was inconclusive 2) pi
test and this is what I got: o = 2136 r = 1310 p = 2270 which to me
shows a monoalphabetic substitution which a count of the blanks
statistically showed a substitution. 3) I
tried completing the plain-component sequence for standard alphabets and
came up with the key: A equals K
Using this key A=K I have come up with:
Reference your message number three eight seven dated one --- December
stop instructions have been issued to all subordinate commands to
===== ===== ===== ===== ===== ===== ======= provisions of ====== ======
of speical order number six.
Can anyone help or give me advice?
Thanks
--
=====
Ernest
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: BIOS password, will it protect PC with PGPDisk against tampering ?
Date: 21 Oct 2000 20:57:58 GMT
[EMAIL PROTECTED] wrote:
>
>why are we bothering to crack the BIOS password? Just open the case,
>pop the battery, which wipes the CMOS, boot up, set the disks back up
>in BIOS (which these days is automatic), and you are in - I've had to
>do that urmmm quite a few times.
Because there is no battery on many modern motherboards.
Flash memory is now cheaper than battery backed up SRAM.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Dense feedback polynomials for LFSR
Reply-To: [EMAIL PROTECTED]
Date: Sat, 21 Oct 2000 21:06:53 GMT
Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote:
: Joaquim Southby 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. [...]
:> 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; 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. (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.)
: There's a logical gap here. In order to claim something "looks more random"
: one must provide a criteria by which one detects the degree of randomness.
: My criteria leads to the conclusion that fractional LFSR periods are
: far less random looking than their maximal versions because the missing
: bit patterns are glaring artifacts.
A 2^n-1 LFSR has a missing bit pattern as well (in the form of all-zeros).
However you look at it, if the state is large - and most of the space is
covered - such artefacts are unlikely to be "glaring" - in that it would
take forever to positively identify them.
I don't know of statistical tests that usefully distinguish the two sorts
of output, much short of finding the period of the generator.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Joaquim Southby <[EMAIL PROTECTED]>
Subject: Re: Dense feedback polynomials for LFSR
Date: 21 Oct 2000 21:17:58 GMT
In article <[EMAIL PROTECTED]> Trevor L. Jackson,
[EMAIL PROTECTED] writes:
>Perhaps I did miss something. I don't see a need to perform counting during setup of
>a maximal-length or near-maximal-length LFSR. Any but a trivially small (1-2) number
>of keys is a suitable key. So why does the RVW weakness hold for maxlen LFSRs?
>
In the case of sub-maximal length LFSR's, the init vector is no longer
the key. It is part of the description of the device, much like the tap
sequence. What becomes the key is the number of times the register is
clocked before starting to use the output stream.
The RVW weakness holds for the maximal length LFSR's for the reasons you
cited -- it takes quite a bit of time to perform the count. Tim has
suggested advancing the count using other means than clocking the
register; I'm not sure how feasible that would be using a hardware LFSR.
You mentioned in another post in this thread that I had perhaps neglected
the effects of scaling to larger registers when it comes to feasibility.
I'm aware of those effects; they just aren't foremost in my mind because
I usually deal with combinations of LFSR's no larger than 32 bits rather
than single larger LFSR's. Good observation.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Storing an Integer on a stream
Reply-To: [EMAIL PROTECTED]
Date: Sat, 21 Oct 2000 21:26:29 GMT
John Savard <[EMAIL PROTECTED]> wrote:
: <[EMAIL PROTECTED]> wrote, in part:
:>If I'm writing a file, whose format is a 64 bit file length, followed by
:>some amount of data, followed by some [random] padding, which of the
:>following is the best way to store that length value:
:>1) 8 base-256 digits. With this format, we always use 8 bytes.
:>2) Some number of base-255 digits, with leading 0 digits stripped, []
:>3) Some number of base-128 digits, with leading 0 digits stripped, []
: [...] if your encryption method doesn't change the length of the
: file being encrypted, there's a *really simple* way to deal with the
: problem:
: don't encrypt the length at all [...]
I think that case was eliminated on a-priori grounds by:
``If I'm writing a file, whose format is a 64 bit file length, followed by
some amount of data, followed by some [random] padding, which of the
following is the best way to store that length value:''
I'm still amazed at David's solution. He advised me that he'd written
some code relating to this problem - but I had no idea that he'd actually
properly addressed the whole issue, with another of his methods that
adds nothing that's not needed to the resulting file.
AFAICS, about the only thing remaining in this whole field is to add a
probability density function to the location of the the split point:
Since (in the case of adding random padding) the location of the split
point is likely to be not /entirely/ random (because of e.g. bandwidth
issues), it might be desirable to have a representation of the split point
that made more probable values have shorter representations.
...and this is completely fluff! ;-)
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Surf against sewage.
------------------------------
Date: 21 Oct 2000 21:36:19 -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 this be a valid assumption after Floppy Drive has been disabled in BIOS ?
How will this hold when Floppy Drive has been disconnected in the box ?
How will this hold when Floppy Drive has been removed permanently from the box ?
On Thu, 19 Oct 2000, "Seeker" <[EMAIL PROTECTED]> wrote:
>> One of the first option that has been suggested, is BIOS password. It is
>> very short, about 5 characters long, but it could created about 60 minutes
>> buffer.
>
>The window of protection on BIOS passwords is more like 5 minutes.
~~~
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 21:36:17 2000 GMT
From: [EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: 2.6.2
iQEVAwUBOfIMUk5NDhYLYPHNAQHQCQf9Faq4fJ1zmGB8I5MvgqO9li6voMic+qpY
FxwqPb3QRSabV2SukNzfIx1JdIxtz0YZ2VS0oQfU+KbKtoGuOfYHcR4pb7vdXgGv
FZHFMM0+KgAhc6Rx9u8lQ6exmk0looscBZRRK6McPF5eX52EXMSUImVtLWV7gXLf
X0QdndR/Kijv//FfK+oY+HciJjRBJPtg4l+LMwYahZasaS+mFwy6SCq8KYzQHZEl
lubGtJ3gTijA8wV0/W13MsRR7WcF9V49QEZDwNmJnLccDbx15RNBBwu41G8Zynz/
kzY33Z2UTz8HWklX34sFr/xyj62N1K4/kj+Qe/XJ4lFvp4zPZa2uoA==
=R/Tw
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Visual Basic
Date: 21 Oct 2000 21:40:28 GMT
binary digit wrote:
>
>
>Anyone know where I can find some encryption algorithms that have been coded
>in Vb and have good documentation on them?
>
http://ciphersaber.gurus.com/
http://ciphersaber.gurus.com/cryptanalysis.html
http://www.freespeech.org/freethought/CipherSaber.htm
http://www.xs4all.nl/~cg/ciphersaber/
http://www.xs4all.nl/~cg/ciphersaber/comp/qbasic.txt
http://www.xs4all.nl/~cg/ciphersaber/comp/visualbasic.zip
http://www.hyuki.com/cs/
http://www.xs4all.nl/~cg/ciphersaber/nat/se.html
http://www.lodz.pdi.net/~eristic/index_pl.html
INPUT FILE
|
V
|<-- This is the CipherSaber file ----->|
+-----------+---------------------------+
|init vector|cipher text |
+-----------+---------------------------+
USER | |
| | |
V | |
+--------+ | |
|password| | |
+--------+ | |
V |
+-----------+ |
|init vector| |
+-----------+ |
|<-10bytes->| |
V
+---------------------------+
|cipher text |
+---------------------------+
|
+--------+-----------+ |
|password|init vector| |
+--------+-----------+ |
|<-- RC4 key ------->| |
| V
+---------------> [RC4 decryption (same as encryption)]
|
V
+---------------------------+
|plain text |
+---------------------------+
|
V
OUTPUT FILE
CIPHERSABER IN QBASIC (Author: Gergõ Érdi)
DECLARE SUB createiv (outfile!)
DECLARE FUNCTION askmode! ()
DECLARE SUB encrypt (infilename$, outfilename$)
DECLARE SUB decrypt (infilename$, outfilename$)
DECLARE SUB readiv (file!)
DECLARE FUNCTION askinput$ ()
DECLARE FUNCTION askoutput$ ()
DECLARE SUB askkey ()
DECLARE SUB init ()
DECLARE FUNCTION cipher! (byte!)
DIM SHARED state(255) AS INTEGER
DIM SHARED keydata(255) AS INTEGER
DIM SHARED keylength AS INTEGER
infilename$ = askinput
outfilename$ = askoutput
IF askmode = 0 THEN
decrypt infilename$, outfilename$
ELSE
encrypt infilename$, outfilename$
END IF
FUNCTION askinput$
askinput:
INPUT "Enter input filename: ", tmp$
IF tmp$ = "" THEN
GOTO askinput
END IF
askinput$ = tmp$
END FUNCTION
SUB askkey
enterkey:
INPUT "Enter key: ", keystring$
keylength = LEN(keystring$)
IF keylength = 0 OR keylength > 246 THEN
GOTO enterkey
END IF
FOR i = 0 TO (keylength - 1)
keydata(i) = ASC(MID$(keystring$, (i + 1), 1))
NEXT i
END SUB
FUNCTION askmode
answer = -1
PRINT "Encrypt/Decrypt [e/d]?"
askmode:
char$ = INKEY$
IF char$ = "d" OR char$ = "D" THEN
answer = 0
END IF
IF char$ = "e" OR char$ = "E" THEN
answer = 1
END IF
IF answer = -1 THEN GOTO askmode
askmode = answer
END FUNCTION
FUNCTION askoutput$
askoutput:
INPUT "Enter output file name: ", tmp$
IF (tmp$ = "") THEN
GOTO askoutput
END IF
askoutput$ = tmp$
END FUNCTION
FUNCTION cipher (byte)
STATIC i, j
i = (i + 1) MOD 256
j = (j + state(i)) MOD 256
SWAP state(i), state(j)
n = (state(i) + state(j)) MOD 256
ret = byte XOR state(n)
cipher = ret
END FUNCTION
SUB createiv (outfile)
RANDOMIZE TIMER
FOR i = 0 TO 9
byte = RND * 256
keydata(keylength + i) = byte
PRINT #outfile, CHR$(byte);
NEXT i
keylength = keylength + 10
END SUB
SUB decrypt (infilename$, outfilename$)
infile = FREEFILE
OPEN infilename$ FOR BINARY AS #infile
outfile = FREEFILE
OPEN outfilename$ FOR OUTPUT AS #outfile
askkey
readiv infile
init
DO
char = ASC(INPUT$(1, #infile))
cchar = cipher(char)
PRINT #outfile, CHR$(cchar);
LOOP UNTIL LOC(infile) = LOF(infile)
CLOSE infile
CLOSE outfile
END SUB
SUB encrypt (infilename$, outfilename$)
infile = FREEFILE
OPEN infilename$ FOR BINARY AS #infile
outfile = FREEFILE
OPEN outfilename$ FOR OUTPUT AS #outfile
askkey
createiv outfile
init
DO
char = ASC(INPUT$(1, #infile))
cchar = cipher(char)
PRINT #outfile, CHR$(cchar);
LOOP UNTIL LOC(infile) = LOF(infile)
CLOSE infile
CLOSE outfile
END SUB
SUB init
FOR i = 0 TO 255
state(i) = i
NEXT i
j = 0
FOR i = 0 TO 255
n = i MOD keylength
j = (j + state(i) + keydata(n)) MOD 256
SWAP state(i), state(j)
NEXT i
END SUB
SUB readiv (file)
FOR i = 0 TO 9
byte = ASC(INPUT$(1, #file))
keydata(keylength + i) = byte
NEXT i
keylength = keylength + 10
END SUB
------------------------------
Date: 21 Oct 2000 21:43: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=====
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 ?
On Thu, 19 Oct 2000, Dido Sevilla <[EMAIL PROTECTED]> wrote:
>Seeker wrote:
>>
>> > One of the first option that has been suggested, is BIOS password. It is
>> > very short, about 5 characters long, but it could created about 60 minutes
>> > buffer.
>>
>> The window of protection on BIOS passwords is more like 5 minutes.
>
>If your machine has wide open physical access, then all that the
>attacker needs to do is remove and replace the battery which keeps the
>CMOS information powered, or to short a jumper on the board. Any
>competent person with an understanding of PC hardware could probably do
>all of these things in under five minutes with a proper screwdriver.
>
~~~
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 21:43:18 2000 GMT
From: [EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: 2.6.2
iQEVAwUBOfIN+U5NDhYLYPHNAQH3/wf/V2DFF+P/op5Y1yectIKvr02Sl3lyvqj+
be1OnDXNfTHrQ3Z+aur2ZTG/U6cU+0u7w/jBDJ92jTJ6x6gwZ/FUqejIZfJ01o8s
4RS8jm8+MYZX4ZHlZ3vTdhVw0iZefsZnSvJ5SWk2sC8mmuMCtFRJOk7H1qxvhqsk
Eqttsc6SlBFxcdjCP0nFw1WM3GkEmV3evIgsrrrRHBkh/Wf+j5RgqrhegJzxwKLS
wQx9EqIugAU1aTRoL/dYU6HmqNSzzb0QyXCuzzPKuSs1uTk6D2vAmR4NHystDHvR
+qPgEFO+IbfL9mrYXwdI+WTHovAWnnYz6rcalCKMVhoqiG/re7anpA==
=qcWC
=====END PGP SIGNATURE=====
------------------------------
Date: 21 Oct 2000 21:45:29 -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=====
After implementing ANTI Tampering Seal Tape, any attempt to open the box will be
higly visible.
On Sat, 21 Oct 2000, [EMAIL PROTECTED] wrote:
>why are we bothering to crack the BIOS password? Just open the case,
>pop the battery, which wipes the CMOS, boot up, set the disks back up
>in BIOS (which these days is automatic), and you are in
You are right, you are in, but all will know that you managed to break in.
It could be detected imediately when PC is on top of the office desk.
> - I've had to do that urmmm quite a few times.
It is fine when applied to "your people".
~~~
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 21:45:27 2000 GMT
From: [EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: 2.6.2
iQEVAwUBOfIOeU5NDhYLYPHNAQFnLwf+MEL79nDIqS3KkRc2D91ojjayC2cJMkQp
DFg/qYwkjjX6qK/HKrL0QTU1uk5ANhvmlNuCuWCqFsHpdlfr2AzvDQc9kCdocYhL
q9KaUiYmMXeqRr5IZrhtoKRqjTXy/SLFWvQ2i9s2+Wgn+w6GZBUyZX7dQIk8TLaI
RoQicMdXTWaBzKIWrkMcCFNuuOqhYzTJJIjFFmXqzb+g5REjHEctRO7VGgOUB6Ag
pbCp8xYWRpQfp3PH+BJjMWWwNVAC8Q0wAjPQZQvtubUfUn0qgDYesPpJI0rdK+qu
vMNJbgl1lGSyEFM6vRIIW/ZxrKEw9Ljn7dz0IESqZ1FoYONkpc090A==
=XLe9
=====END PGP SIGNATURE=====
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: My comments on AES
Reply-To: [EMAIL PROTECTED]
Date: Sat, 21 Oct 2000 21:36:58 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> How about the bit where he wrote (from the URL above):
:>
:> ``I believe that within the next five years someone will discover an
:> academic attack against Rijndael.''
: However, if an academic attack is only of interest
: academically and not a genuine menace in practice, then
: that would be only a happy and laudable success of some
: intellectual endeavour, nothing more.
No doubt it would be an inspiration for those wishing to embark on
further such intellectual endeavours.
Does anyone have any comments on the proposed timescale?
I suspect an academic break (of 128, 192 or 256 bit Rijndael) will come
to light eventually - but that it may well take more than five years.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Surf against sewage.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: xor algorithm
Reply-To: [EMAIL PROTECTED]
Date: Sat, 21 Oct 2000 21:50:36 GMT
Paul Pires <[EMAIL PROTECTED]> wrote:
: A PRNG for crypto needs to be irreversible and unpredictable. [...]
Somewhat more precisely for many cryptographic purposes, a PRNG needs to
be computationally difficult for an attacker to run backwards very far.
Actually making a PRNG irreversible can be a questionable way of doing
this - since irreversible generators gradually lose the entropy in
their internal states - and fail to attain maximal periods.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
** 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
******************************
