Cryptography-Digest Digest #266, Volume #11 Mon, 6 Mar 00 14:13:01 EST
Contents:
Re: avoid man-in-the-middle known plaintext attack using a stream cipher (David
Hopwood)
Re: Cellular automata based public key cryptography (Tim Tyler)
Re: Problem running Platform SDK sample: WebServer on NT 4.0 ("Scott")
Re: differential cryptanalysis ([EMAIL PROTECTED])
Re: Passwords secure against dictionary attacks? (Mats Wichmann)
Re: Passwords secure against dictionary attacks? (Mats Wichmann)
Re: Can someone break this cipher? (Mark VandeWettering)
Re: Decompiling/Tamper Resistent (Paul Koning)
Re: ascii to binary (Vernon Schryver)
Re: Security Features of Pokerspot.com (Mike Rosing)
Re: Decompiling/Tamper Resistent (Jerry Coffin)
Re: math error? NOT AT ALL ... (Anton Stiglic)
Re: avoid man-in-the-middle known plaintext attack using a stream cipher
([EMAIL PROTECTED])
Re: Cellular automata based public key cryptography ([EMAIL PROTECTED])
Re: Passphrase Quality ? ("Stephen P.")
Re: Passphrase Quality ? ("Stephen P.")
Re: Excel password remover ("Tobiass Mai")
----------------------------------------------------------------------------
Date: Mon, 06 Mar 2000 16:44:17 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: avoid man-in-the-middle known plaintext attack using a stream cipher
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
>
> I would suggest an error propagating protocol. If you use e.g. WeakCipher
> which based on a "P-CFB" mode (is it really called that?) you will neither
> increase the bandwidth nor have to wait for a signature, and the entire
> message after any altered bit will be complete gibberish. A "bit flipping
> attack" won't work either.
I can think of two possibilities for a CFB-like mode with plaintext feedback.
One is:
C[i] = P[i] XOR E_K(C[i-1] XOR P[i-1])
P[i] = C[i] XOR E_K(C[i-1] XOR P[i-1])
where C[0] = IV and P[0] = 0.
However, that doesn't appear to be error-propagating, so maybe you meant
this:
C[i] = P[i] XOR E_K(C[i-1]) XOR P[i-1]
P[i] = C[i] XOR E_K(C[i-1]) XOR P[i-1]
If so, this appears to be vulnerable to the same type of block transposition
attack that works against PCBC. Suppose the original ciphertext C[1..3] is
changed to C'[1..3] = C[2], C[1], C[3].
Then the original plaintext was:
P[1] = C[1] XOR E_K(IV)
P[2] = C[2] XOR E_K(C[1]) XOR P[1]
= C[1] XOR C[2] XOR E_K(IV) XOR E_K(C[1])
P[3] = C[3] XOR E_K(C[2]) XOR P[2]
= C[1] XOR C[2] XOR C[3] XOR E_K(IV) XOR E_K(C[1]) XOR E_K(C[2])
whereas the receiver calculates:
P'[1] = C'[1] XOR E_K(IV)
= C[2] XOR E_K(IV)
P'[2] = C'[2] XOR E_K(C'[1]) XOR P'[1]
= C[1] XOR C[2] XOR E_K(IV) XOR E_K(C[2])
P'[3] = C'[3] XOR E_K(C'[2]) XOR P'[2]
= C[1] XOR C[2] XOR C[3] XOR E_K(IV) XOR E_K(C[1]) XOR E_K(C[2])
= P[3]
(and the subsequent plaintext blocks are also unchanged).
My advice is to be highly skeptical of modes that claim to be able to do
integrity checking at the same time as encryption.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOMMtQjkCAxeYt5gVAQGKpwf+KlYkegXX4JT8FqDZgJ6uCL+HMe2WZ3P5
I6WFwXUU/AcjXXVwTPujWEgb2zrhyJrrBPvJHiD3WqkqAktfgVU8m9UHpNbBAd+b
tdDNHPXZsAVN39v2rEMkzUMuPjQVIjdXVMeMlYTYH7ICgq7Wc+OuWjH48zj2PC9l
dJbj5J6+JcqaH0KC9XFJpexmeDt1Vvwf44WfYU0uFBxpyMiEK5viL4pJisseNkBV
wTArGCU6SCQgD5AOe2s+fr63K2Nw7Rua8LdjiEpXskEKo8stkFgbsl4YomBrwdBV
gtPja5Kxm7TbqhcBISOuWfrMMDj2wtee3eQnZFfJwD2FV6+TQMmOlg==
=Lhjj
=====END PGP SIGNATURE=====
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Cellular automata based public key cryptography
Reply-To: [EMAIL PROTECTED]
Date: Mon, 6 Mar 2000 16:57:17 GMT
Dr. Yongge Wang <[EMAIL PROTECTED]> wrote:
: Tim Tyler ([EMAIL PROTECTED]) wrote:
: : Both FSM and cellular automata are capable of simulating Turing universal
: : systems - anything one can do, so can the other.
: Are you sure??????
: Turing machine can acept any r.e (recursively enumerable, nowadays,
: the people in recursion theory like to call this concept c.e.,
: that is, computably enumerable) languages, while FSM can only
: accept regular languages which are very limited.
: You may recall that: FSM << pushdown automaton (context-free language)
: << Turing machines (r.e. language) :-)
All the systems discussed can perform the same types of calculations.
In reality there is no such thing as a system with infinite storage.
With this restriction, finite cellular automata, and finite state machines
can perform the same set of calculations as each other, or indeed any
other finite computer.
All these systems (including FSM) can compute recusive functions - at
least up to the point where they run out of memory.
I wasn't trying to say that FSM had the same infinite memory as the
theoretical abstraction that is a Turing machine.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Science asks why, I ask why not.
------------------------------
Reply-To: "Scott" <[EMAIL PROTECTED]>
From: "Scott" <[EMAIL PROTECTED]>
Subject: Re: Problem running Platform SDK sample: WebServer on NT 4.0
Date: Mon, 06 Mar 2000 17:07:50 GMT
All,
Has anyone been able to get this WebServer sample to run? I am running
NT 4.0 Server w/SP4, and have installed a certificate using the keyring.exe
application. I can connect securely to IIS using the certificate I
installed, but when I attempt to run WebServer I get an error during
initialization: Error 0x80092004 returned by CertFindCertificateInStore if I
run WebServer -UCertificateName. If I run WebServer -uCertificateName I get:
Error 0x80090304 returned by AcquireCredentialsHandle. I can successfully
get this sample application to run under Windows 2000, but I need it to also
run under NT 4.0. The readme.txt states this sample will run with NT 4.0 and
SP4.
It seems to me that AcquireCredentialsHandle cannot properly locate the
entire certificate.
Any ideas anyone?
Please try to provide response via e-mail as well.
Thank you,
Scott
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: differential cryptanalysis
Date: 6 Mar 2000 17:07:38 GMT
In a previous article, <[EMAIL PROTECTED]> writes:
>He means K'=K xor Ri, not K'=K to the power Ri, modulo or not. (^ is
>used as an XOR operator in C, and a 'contents of address' operator in
>Pascal, although it serves for exponentiation in BASIC, which was even
>more appropriate when it was an up-arrow instead of a caret.)
That explains it.
The most appropriate symbol for xor would be a "V" with a cross stroke. That's
how the boolean operator is denoted in formal logic.
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Mats Wichmann)
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: Passwords secure against dictionary attacks?
Date: Mon, 06 Mar 2000 16:57:22 GMT
Reply-To: [EMAIL PROTECTED] (Mats Wichmann)
On Wed, 01 Mar 2000 01:42:12 GMT, jungle <[EMAIL PROTECTED]> wrote:
>Ross Richards wrote:
>>
>> Having to type 10 english words with punctuation in would not go down
>> well with users who have screen saver passwords.....
>
>this discussion is NOT for pass for SCR saver ...
But very often the screen saver password IS the system password...
Mats Wichmann
(Anti-spam stuff: to reply remove the "xyz" from the
address [EMAIL PROTECTED] Not that it helps much...)
------------------------------
From: [EMAIL PROTECTED] (Mats Wichmann)
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: Passwords secure against dictionary attacks?
Date: Mon, 06 Mar 2000 16:57:26 GMT
Reply-To: [EMAIL PROTECTED] (Mats Wichmann)
On Fri, 25 Feb 2000 07:33:47 GMT, $[EMAIL PROTECTED]
wrote:
>In comp.security.misc Alun Jones <[EMAIL PROTECTED]> wrote:
>
>> Seriously though, this is often a failing of security policies - make your
>> security policy unwieldy and difficult to implement, and you run the risk
>> that your users will find their own ways to subvert it. I remember one
>
>Very, Very well said Alun.
>
>BTW, I'm in the process of implementing a password policy for my office of
>about ~30 people... what is a good password expiry... 30, 45, or 60 days?
I'd say, give some thought to the security vs. usability tradeoffs in
forcing frequent password expiry.... At least give folks enough time
to think of a new password - if one day they log in and are told "pick
a new password NOW" the likelihood of picking a lousy one seems to go
up (you're "on the spot"). I'd say if you're going to do this at the
least use PAM with libcrack to check out the new password for some of
the worst choices...
Mats Wichmann
(Anti-spam stuff: to reply remove the "xyz" from the
address [EMAIL PROTECTED] Not that it helps much...)
------------------------------
From: Mark VandeWettering <[EMAIL PROTECTED]>
Subject: Re: Can someone break this cipher?
Date: Mon, 06 Mar 2000 09:43:01 -0800
Mary - Jayne wrote:
>
> On Thu, 02 Mar 2000 15:03:41 -0800, Mark VandeWettering <[EMAIL PROTECTED]>
> wrote:
>
> >A copy of the program source code would be in order. It seems rather unfair
> >for you to ask people to analyze your algorithm without the source code to
> >find weaknesses that you can't with the source code.
>
> Dream on.
>
> > If you have come up with an encryption scheme, providing some
> > ciphertext from it is not adequate. Nobody has ever been impressed by
> > random gibberish. Any new algorithm should be secure even if the
> > opponent knows the full algorithm (including how any message key is
> > distributed) and only the private key is kept secret. There are some
> > systematic and unsystematic ways to take reasonably long ciphertexts
> > and decrypt them even without prior knowledge of the algorithm, but
> > this is a time-consuming and possibly fruitless exercise which most
> > sci.crypt readers won't bother with.
>
> Thank you for that. If most won't, then some might.
In other words, you'd prefer to gather the ill will of those who are most
capable of analyzing the cipher so that you can gather opinions from those
less qualified? Ah, yes, I suspect your cipher is _absolutely_ secure.
> If you are not interested, stop replying. Some postings have been quite
> helpful to me and I am grateful.
If you were actually interested in evaluating the security of your cryptosystem
rather than engaging in crypto-games, you'd both understand the reasonable nature
of what we ask, and comply. The fact that you don't indicates that you haven't
done your own homework. That doesn't bode well for your cryptosystem.
Mark
--
Mark T. VandeWettering Telescope Information (and more)
Email: <[EMAIL PROTECTED]> http://raytracer.org
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Decompiling/Tamper Resistent
Date: Mon, 06 Mar 2000 12:22:58 -0500
[EMAIL PROTECTED] wrote:
>
> I am refering to your post and the above poster. It appears that you
> dont have a clue of real crypto systems. Have you heard of FIPS-140
> levels 1-4. Most crypto manufacturers have a
> tamper-resistent/tamper-proof module (for keys and programs). This is
> not to stop customers having access to the source code...customers dont
> go snooping around bits of hardware and disassembling code.. There is
> an easier way of getting the source code.. You just ask...Isnt that
> simple..
You didn't state FIPS 140 as your reason for asking, you stated
concern about decompiling as your reason. The answers you received
were exactly correct for the latter. In fact, you specifically
indicated that you want people not to be able to see your software,
so why do you now say that all they have to do is "just ask" to
see the source code?
For the former, yes, there are some pieces that need to be protected.
The code needs only integrity, not confidentiality. The only thing that
needs confidentiality is a key encipherment key or analogous thing.
> And I would aprreciate that you dont answer threads about a subject you
> know little about...
Insulting your respondents when they answer the question you
asked rather than the question you later say you *meant* to
ask isn't going to get you very far... Especially when the
two are diametrically opposite.
paul
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: ascii to binary
Date: 6 Mar 2000 10:59:42 -0700
In article <[EMAIL PROTECTED]>,
wtshaw <[EMAIL PROTECTED]> wrote:
>> See Recommended USA Standard Code for Information Interchange (USASCII)
>> X.34-1967 (and predecessors) which define encoding some characters and control
>> codes into 7 (yes, only seven). I know of no standard encoding into
>eight bits,
>> other than adding parity.
>
>I don't know if I still have the manuels, but I remember the day that the
>the bigger keypunches started to arrive. Before there were 10 rows on
>punched cards, the characters were 0 to 9, A to Z (upper case only),12 or
>so symbols. Paper tape only had 7 rows of usable holes, with not all
>combinations being used.
Didn't cards have 12 rows and 80 columns for decades before the 96-column
cards arrived in the 1970's? Weren't the twelve holes on the classic
punched cards labeled 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, + and - (at least
by how you would punch individual holes to generate non-standard
combinations).
If you will bother to look at the ANSI standard mentioned above, you'll
find that it defines 128 different values, or all possible combinations
of 7 bits. Many UNIX boxes have a man page under `man ascii` that
distills ANSI X.34. Recall also that all 128 combinations of the 7
non-parity holes in paper tape could be punched with single keystrokes
on an Model 37 ASR Teletype.
I also don't agree that paper tape had only 7 useful bits. Using a
computer talking to Model 33, 35, and 35 ASR TTY's as well as Western
Electric and other paper tape punches, I've punched many cases of rolls
of paper (as well as paper-mylar and mylar) tape with 8-bit bytes.
Sometimes the 8th bit was merely parity, but most of the time each frame
carried 8 full bits of data, with a longitudinal checksum of some kind
before and/or after a block of frames.
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Crossposted-To: rec.gambling.poker
Subject: Re: Security Features of Pokerspot.com
Date: Mon, 06 Mar 2000 12:22:35 -0600
Tony L. Svanstrom wrote:
> - All user passwords are stored in encrypted form (using DES encryption) in
> our databases.
They ought to change it to one of the AES candidates. DES is crackable
by brute force in 2 days by EFF's specialized machine.
> - Finally, our random number generator has been designed to be completely
> non-deterministic. By utilizing a Geiger counter to detect radioactive
> decay of
> Americium 241 (a radioactive element, with a half-life of 432 years), we are
> able to
> generate true random numbers to drive our deck shuffling algorithm. This
> makes Pokerspot.com the first and ONLY cardroom on the Internet with a
> truly random number generator. For more information on this feature
> (including our deck shuffling algorithm), please visit
> http://www.pokerspot.com/random.html
Where it says:
:1) First and foremost, we do not believe in security by obscurity. We
believe
: full-disclosure is the best policy. In fact, if we
could open source our source
: code repository, we would.
:
: 2) We believe you will agree that Pokerspot is by far
the best cardroom on the
: Internet. We are so confident of this that we're
willing to let our competitors in
: on some of our methods.
:
: 3) Even if you do opt to play at another cardroom, we
hate cheaters just as much
: if not more than you do. If you are going to be
playing poker online, we wish you
: a safe and fun experience!
Damn good attitude! In general, the whole thing looks like they are
trying hard
to be really secure. It's not really open source, but you should be
able to test
their descriptions and see if the program responds the way they say it
should.
If not, they seem like the kind of folks who will listen to customer
comments (and
testing that is probably the first thing to try :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Decompiling/Tamper Resistent
Date: Mon, 6 Mar 2000 11:30:07 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> Tamper-resistance is sometimes done in industry by putting chips in
> potting compounds; I've heard a substance used by dentists is quite
> good; but I'm not sure that chipmakers offer this sort of thing to
> commercial customers.
Potting compound will only barely slow down a serious attempt at
reverse engineering a chip. Just for example, most automotive engine
control modules are potted to help physical integrity in a rather
hostile environment. The company I work for has torn into these on a
fairly regular basis for years.
If you want real protection, there are some rather special
passivation layers that can be used on chips that do some good -- I
don't know of any that absolutely CAN'T be worked around, but some of
them can certainly make life a LOT more difficult.
In fairness, I should point out that normal advances in technology
also make this sort of work a _great_ deal more difficult. Back when
chips were typically built with 2 or 3 micron technology, reverse
engineering circuits was quite easy. We're quickly reaching the
point that the sizes involved are close enough to the wavelengths of
light that it's soon going to be quite difficult to look at them with
optical microscopes no matter how good people are. That will mean
using scanning electron microscopes instead, which will (in turn)
take a cost that's already in the range of 10's to hundreds of
thousands of dollars, and probably multiply it by 10 or so (though
the increase will likely be a smaller percentage as the overall cost
goes up).
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: math error? NOT AT ALL ...
Date: Mon, 06 Mar 2000 13:39:44 -0500
Anton Stiglic wrote:
> I don't know if it's wort replying to this, but here goes.
>
> If you have a password system where a password is composed
> of 10 items, each item having 4 chars, then the total amount of
> different passwords that may exist in that system is 4^10, that
> is 4*4*4*4*4*4*4*4*4*4 = 4^10 (an *not* 4x10).
To clarify, if the initial poster was saying that a password is composed
of 10 items, where each item is a concatenation of 4 chars, where each
char has c bits long, then the total amount of possible passwords is
(2^(4*c))^10.
The correctness of the statement is left as an exercice...
> And a final thing, nPr = n!/ (n-r)!*r!
> I can't explain you that here, you need any descent calculus book
> for that.
Sorry, I got caught in the mistakes. nCr = n!/(n-r)!*r!, that's not the
definition of nPr.
Anton
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: avoid man-in-the-middle known plaintext attack using a stream cipher
Date: 6 Mar 2000 18:38:26 GMT
In a previous article, David Hopwood <[EMAIL PROTECTED]> writes:
>I can think of two possibilities for a CFB-like mode with plaintext
feedback.
This is what I meant. I cannot see that it have to be vulnerable to the same
type of block transposition attack that works against PCBC (it really has to
depend on E_K), but maybe I am just being blind.
Terminology:
P[I]: Ith byte of plain text,
C[I]: Ith byte of cipher text,
S[I]: Ith byte of an OTP,
B[I]: The 16-bit feedback buffer at step I, where B[0] is the IVector,
B[I,0], B[I,1]; The least and most significant byte of B[I] respectively.
E_K: A 16-bit table lookup cipher.
The symbol "|" denotes concatenation. B[I] = B[I,0]|B[I,1].
Encryption algorithm:
1. B[I] := E_K(B[I-1,1]|C[I-1] xor S[I-1])
2. C[I] := P[I] xor B[I,0] xor S[I]
Decryption algorithm:
1. B[I] := E_K(B[I-1,1]|C[I-1] xor S[I-1])
2. P[I] := C[I] xor B[I,0] xor S[I]
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cellular automata based public key cryptography
Date: Mon, 06 Mar 2000 18:42:06 GMT
In article <89v95q$hv9$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Dr. Yongge Wang) wrote:
> Tim Tyler ([EMAIL PROTECTED]) wrote:
>
> : Both FSM and cellular automata are capable of simulating Turing
universal
> : systems - anything one can do, so can the other.
>
> Are you sure??????
> Turing machine can acept any r.e (recursively enumerable, nowadays,
> the people in recursion theory like to call this concept c.e.,
> that is, computably enumerable) languages, while FSM can only
> accept regular languages which are very limited.
>
> You may recall that: FSM << pushdown automaton (context-free language)
> << Turing machines (r.e. language) :-)
>
>Dr. Wang is exactly correct. However, it is possible to define a
universal cellular automata (CA) such that given the code of a CA "B"
and input "x" it can simulate the behavior of "B" on input "x". Both
this universal CA and a turing machine (TM) cab be proven equivalent
(i.e. of the same power) via Roger's isomorphism theorem. To see how
this is done go to http://alife.santafe.edu and then, if I remember
correctly, to "CA" then "topics" then "faq" then "properties" then
"computability".
An "evolution" of CA called cellular neural networks (created by
Chau-Yang) is also universal and equivalent to TM.
In addition, CA are Turing complete, i.e. computer architectures can be
built from arrays of identical cells. David Cary believes that this may
be close to the optimum architectures for nanocomputers.
[A side question- Earlier, was the Garden of Eden problem (deriving the
starting pattern from an n-th iteration) the main obstacle to
implementing CA based cryptosystems, especially given the fact that some
CAs don't have a single inverse because of multiple inputs going into
the same output?]
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Stephen P." <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Passphrase Quality ?
Date: Mon, 06 Mar 2000 18:58:37 GMT
i wonder if you understand what i'm asking. let's say i easily say "Uncle"
so if i 'know' my password then when they make me say "Uncle" out comes my
password. but if i had some way of generating a password that i simply can't
remember because it's too long then they wouldn't be able to get the
password out of me. what would be a secure way to have a password that i
don't need to remember .. instead i would just need to know how to generate
when i want to use pgp?
for instance i could cut and past some password:
aklsdflkajsdlfjlkajsdfkljasldfjk
asdfkljasdlfkja;sdlkfjlkajsdklf
eworuoweiruoiweuroiuweioru
woeiroiwe
or some such next to impossible to remember password and so i couldn't be
able to tell them. however, it would not be that secure if there was a file
on my system with the text of the password, eh? so maybe there's another
way?
steve
Guy Macon wrote:
>
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Stephen P.) wrote:
>
> >tell them to use some poem as the passphrase !? no, sorry, i'm left
> >muddled. but i do have a question about all this. how can i go about
> >generating a password that i can't remember but can easily produce if at my
> >machine? and .. please .. don't tell me to go ask alice.
>
> Simple. write it on a postit note and stick it on your monitor.
> That's what millions of workers do every day when faced with idiot
> MIS departments that force them to use hard to remember passwords.
>
> For the rest of us who have a choice, here is one good method
>
> Write a sentence that you will remember. Something never published.
> Something hard to guess but easy to remember, like "how can i go about
> generating a password that i can't remember but can easily produce?"
>
> how
> can
> i
> go
> about
> generating
> a
> password
> that
> i
> can't
> remember
> but
> can
> easily
> produce?"
>
> h
> c
> i
> g
> a
> g
> a
> p
> t
> i
> c
> r
> b
> c
> e
> p
>
> Your password is hcigagapticrbcep.
> Easy to remember, hard to guess.
------------------------------
From: "Stephen P." <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Passphrase Quality ?
Date: Mon, 06 Mar 2000 19:01:41 GMT
x-no-archive: yes
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
i wonder if you understand what i'm asking. let's say i easily say "Uncle"
so if i 'know' my password then when they make me say "Uncle" out comes my
password. but if i had some way of generating a password that i simply
can't
remember because it's too long then they wouldn't be able to get the
password out of me. what would be a secure way to have a password that i
don't need to remember .. instead i would just need to know how to generate
when i want to use pgp?
for instance i could cut and past some password:
aklsdflkajsdlfjlkajsdfkljasldfjk
asdfkljasdlfkja;sdlkfjlkajsdklf
eworuoweiruoiweuroiuweioru
woeiroiwe
or some such next to impossible to remember password and so i couldn't be
able to tell them. however, it would not be that secure if there was a file
on my system with the text of the password, eh? so maybe there's another
way?
steve
Guy Macon wrote:
>
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Stephen P.)
> wrote:
>
> >tell them to use some poem as the passphrase !? no, sorry, i'm left
> >muddled. but i do have a question about all this. how can i go about
> >generating a password that i can't remember but can easily produce if at
> >my machine? and .. please .. don't tell me to go ask alice.
>
> Simple. write it on a postit note and stick it on your monitor.
> That's what millions of workers do every day when faced with idiot
> MIS departments that force them to use hard to remember passwords.
>
> For the rest of us who have a choice, here is one good method
>
> Write a sentence that you will remember. Something never published.
> Something hard to guess but easy to remember, like "how can i go about
> generating a password that i can't remember but can easily produce?"
>
> how
> can
> i
> go
> about
> generating
> a
> password
> that
> i
> can't
> remember
> but
> can
> easily
> produce?"
>
> h
> c
> i
> g
> a
> g
> a
> p
> t
> i
> c
> r
> b
> c
> e
> p
>
> Your password is hcigagapticrbcep.
> Easy to remember, hard to guess.
=====BEGIN PGP SIGNATURE=====
Version: 6.5.1ckt http://irfaiad.virtualave.net/
iQA/AwUBOMQAllMZCmMtHP6pEQIAHACfeb8eOiNZTzM/1Mh3Y8FBtytSxUQAoIdT
MX8E+A5tLvMnmlLeaRI1BNEs
=muEZ
=====END PGP SIGNATURE=====
------------------------------
From: "Tobiass Mai" <[EMAIL PROTECTED]>
Subject: Re: Excel password remover
Date: Mon, 6 Mar 2000 20:05:01 +0100
Hello!
But i think in one way the xls-files are the property of Microsoft!? Or?
Regards
Tobiass
<[EMAIL PROTECTED]> schrieb in im Newsbeitrag:
89uav2$1u7$[EMAIL PROTECTED]
> In a previous article, "Tobiass Mai" <[EMAIL PROTECTED]> writes:
> >I've written a program which removes the protection of
> >Excel-workbooks/-sheets.
> >Can anybody tell me if i can get in trouble with Microsoft?
>
> Maybe, but I do not see why: Each xls-file is the intellectual
property of the
> person who created it, and I guess it is the xls-files - not Excel -
your
> application will tamper with.
>
> ----- Posted via NewsOne.Net: Free Usenet News via the
eb -----
> ----- http://newsone.net/ -- Discussions on every
subject. -----
> NewsOne.Net prohibits users from posting spam. If this or other
posts
> made through NewsOne.Net violate posting guidelines, email
[EMAIL PROTECTED]
------------------------------
** 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
******************************
