Cryptography-Digest Digest #967, Volume #11 Wed, 7 Jun 00 10:13:01 EDT
Contents:
Re: An interesting page on the Rabin-Miller PP test (Robin Chapman)
Re: Brute forcing for Counterpane's Password Safe ("Dave Foulger")
Re: Brute forcing for Counterpane's Password Safe (Volker Hetzer)
Re: Brute forcing for Counterpane's Password Safe (Paul Rubin)
Re: Some dumb questions (Mok-Kong Shen)
Re: Statistics of occurences of prime number sequences in PRBG output as (Mok-Kong
Shen)
Re: Some dumb questions (Mok-Kong Shen)
Re: testing non linearity of arithmetic-logic combinations (tomstd)
Re: Observer 4/6/2000: "Your privacy ends here" (Paul Shirley)
Re: Thoughts on an encryption protocol? (Mark Wooding)
Re: software protection schemes (Runu Knips)
Re: Brute forcing for Counterpane's Password Safe (Rex Stewart)
Re: Evidence Eliminator, is it patented, copyrighted, trademarked ? (jungle)
Re: Some dumb questions (Volker Hetzer)
Re: Brute forcing for Counterpane's Password Safe (Volker Hetzer)
Re: software protection schemes (jungle)
Re: Is OTP unbreakable?/Station-Station (Tim Tyler)
----------------------------------------------------------------------------
From: Robin Chapman <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: An interesting page on the Rabin-Miller PP test
Date: Wed, 07 Jun 2000 09:13:05 GMT
In article <393db17a$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Andrew John Walker) wrote:
>
> Thanks, I don't fully understand the maths yet but it's good to
> see a result! Would this line of reasoning work with forms such as
p^2*q
> or p*q*r?
I expect so.
> If eventually a general result could be found it would allow for much
more
> accurate estimates of how often this test produces non-witnesses for
> a particular sized composite, forinstance by taking 100 50d numbers
> and factoring them.
I'm not so optimistic. The number of non-witnesses will depend
quite strongly on the form of the number n, as pq or pqr or p^2 q etc.,
and will also depend very strongly on how the primes p and q etc.
interact. For instance in the pq case d = gcd(p-1, q-1) can be
anything from 2 up to p-1, which may be of the order of sqrt(n).
--
Robin Chapman, http://www.maths.ex.ac.uk/~rjc/rjc.html
"`The twenty-first century didn't begin until a minute
past midnight January first 2001.'"
John Brunner, _Stand on Zanzibar_ (1968)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Dave Foulger" <[EMAIL PROTECTED]>
Subject: Re: Brute forcing for Counterpane's Password Safe
Date: Wed, 7 Jun 2000 11:15:52 +0100
Joeseph Smith <[EMAIL PROTECTED]> wrote in message
news:rab%4.30$[EMAIL PROTECTED]...
> I've been asked to help the executor of the estate
> of a fellow who recently died in Florida. The fellow
> was techno-savvy enough to use Password Safe
> from Counterpane to hold his various account names
> and passwords. Unfortunately, he was not real-world
> savvy enough to leave a way for his heirs to recover
> the data. The executor has tried various obvious
> passwords (names of grandchildren, significant dates
> and places, etc.), but they have not worked.
>
> Does anyone have a program that does brute
> force password guessing for Counterpane's
> Password Safe program? Alternatively, does
> anyone have the details of the file format and
> algorithms so I can write one? Bruce's website
> says that it uses Blowfish and that a 2.0 version
> would be published with source, but I don't think
> the 2.0 version was ever published. Does anyone
> have source to it?
>
> Please reply to the list, since I believe the answer
> will be generally useful.
>
> Joe
Ask Bruce for the backdoor nsa key ;-)
Dave
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: Brute forcing for Counterpane's Password Safe
Date: Wed, 07 Jun 2000 10:22:52 +0000
Dave Foulger wrote:
>
> Joeseph Smith <[EMAIL PROTECTED]> wrote in message
> news:rab%4.30$[EMAIL PROTECTED]...
> > I've been asked to help the executor of the estate
> > of a fellow who recently died in Florida. The fellow
> > was techno-savvy enough to use Password Safe
> > from Counterpane to hold his various account names
> > and passwords. Unfortunately, he was not real-world
> > savvy enough to leave a way for his heirs to recover
> > the data. The executor has tried various obvious
> > passwords (names of grandchildren, significant dates
> > and places, etc.), but they have not worked.
> Ask Bruce for the backdoor nsa key ;-)
I agree. Since you appear to have a legitimate reason, you
(or the executor) can propably count on the goodwill of
Counterpane. But I don't think that they designed weaknesses
into their product, so you'll IMHO be out of luck anyway.
Greetings!
Volker
--
The early bird gets the worm. If you want something else for
breakfast, get up later.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Brute forcing for Counterpane's Password Safe
Date: 7 Jun 2000 10:38:09 GMT
In article <[EMAIL PROTECTED]>,
Volker Hetzer <[EMAIL PROTECTED]> wrote:
>Dave Foulger wrote:
>>
>> Joeseph Smith <[EMAIL PROTECTED]> wrote in message
>> news:rab%4.30$[EMAIL PROTECTED]...
>> > I've been asked to help the executor of the estate
>> > of a fellow who recently died in Florida. The fellow
>> > was techno-savvy enough to use Password Safe
>> > from Counterpane to hold his various account names
>> > and passwords. Unfortunately, he was not real-world
>> > savvy enough to leave a way for his heirs to recover
>> > the data. The executor has tried various obvious
>> > passwords (names of grandchildren, significant dates
>> > and places, etc.), but they have not worked.
>> Ask Bruce for the backdoor nsa key ;-)
>I agree. Since you appear to have a legitimate reason, you
>(or the executor) can propably count on the goodwill of
>Counterpane. But I don't think that they designed weaknesses
>into their product, so you'll IMHO be out of luck anyway.
Um, I didn't feel like it was worth posting at first, but I'm
skeptical of the whole story. Password Safe is mostly used for stuff
like web site login credentials. Why would the heirs want access to
those? The heirs would normally care about stuff like bank accounts,
which the executor should be able to locate by knowing the SSN (tax ID
number) of the dead person.
If I were to die tomorrow, I'd want my financial assets (such as they
are) and material belongings to go to my family, but I don't think I'd
want anybody to get the contents of any password protected computer
files I might have, unless I made specific arrangements.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Some dumb questions
Date: Wed, 07 Jun 2000 13:50:35 +0200
Volker Hetzer wrote:
> Mok-Kong Shen wrote:
> >
> > Volker Hetzer wrote:
> > > As to "concreteness", what exactly do you want?
> > I like instructions that are practical enough for doing the work of
> > analysis.
> For the simple case (two messages of known character distribution
> xored together) you attack it like a book cipher.
> You compute the distribution of the xor-results based on the
> distribution of the characters going into the xor.
> Then you count the distribution of the ciphertext (the xored messages)
> and look for matches of probability.
> At least that's what I'd do.
[snip]
It is my fault for not having clearly/correctly stated what I had in
mind when I wrote that 'there is no plaintext knowledge available'.
I assume that the opponent knows the language used and even has
a good frequency distribution. But I assume (from what I know
about practical use of OTP) also that OTP is not used 'purely',
i.e. not used alone, and that there is a processing step before doing
the xor, in order to prevent the opponent from utilizing digram or
n-gram frequencies and locating certain headers in the messages
etc. etc. I thought that a simple transposition could be sufficient
for achieving that. If not, then some better techniques could be
applied. (I have no ready ideas at the moment for these but I
believe that something simple like polyalphabetic substitutions or
random bit rotations of computer words would work well.) This
in principle deals with your objections, I suppose. Now one could
certainly argue whether such additional processing is economically
justified, etc. etc. However, I should mention (it's my fault for not
having done it at the beginning) that my original post does not have
the intention to 'recommend' the multiple use of OTP (not to
mention to imply that multiple use could be provably strong) but
simply to learn whether and why an erroneous employment such
that an OTP is e.g. used twice is 'really' that fatal, if precautions
in other respects of the security system are all properly taken.
> > > > Note also that, if the
> > > > OTP is used exactly twice, then (1) the xor of different pairs of
> > > > messages (each pair has the same OTP segment, but different pairs
> > > > have different segements) are essentailly unrelated to each other and
> We are assuming that we are xoring messages with a known character distribution
> and that we are sure we've got the correct pieces to xor together.
My point is that if you have a large number of messages and you know
that these form pairs such that each pair comes from the same segment
of OTP but no two pairs share the same segment, then the task of
finding some such pairs is very difficult, as far as I can see. One could
try all the possible pairings, but that's a combinatorial explosion, in view
of the fact there is nothing to tell whether the pairing is correct, when
one picks two arbitrary messages from the pool.
> > > Just like the whole idea of re-using an OTP keystream, it relies on the
> > > stupidity of the people communicating. You test different variants
> > > of reuse.
> >
> > I am afraid I don't quite understand what you mean by testing different
> > variants of reuse. Assuming that each segment is used twice, one has
> > to find from a large number of messages the corresponding messages
> > (in pairs) that use the same segments. It is not apparent how one is
> > going to do that.
> Variant 1: every message uses the same pad.
> Variant 2: a pad of fixed length is rolled over at the end.
> Variand 3: <fill in with your own ideas> :-)
For simplicity of discussions, let's say that there are 2*m messages,
each of b bytes. The OTP is m*b bytes long. Each b byte segment
of the OTP is used by exactly 2 messages. I don't see how many
'varaints' are there which one should try according to your previous
post and what are these.
Cheers,.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Statistics of occurences of prime number sequences in PRBG output as
Date: Wed, 07 Jun 2000 13:52:30 +0200
"John A. Malley" wrote:
> I just read Bob Silverman's post on functions that do iteratively
> generate all primes starting from an initial value. A better
I am afraid there there is some disagreement between us up till now
about the notion of 'mathematical functions'. If I don't err, any (computer)
procedure that always terminates is one such. The following procedure
Nextprime in pseudo-code computes the next prime from a given prime
(no efficiency of computation is implied).
proc Oddprime (x) :=
begin
int k, sq;
if mod(x,2) = 0 then return(false) fi;
k:=1; sq:=floor(squareroot(x));
do
k:=k+2;
if k>sq then return(true) fi;
if mod(x,k)=0 then return(false) fi;
end;
proc Nextprime(p):=
begin
if p = 2 then return(3) fi;
do
p:=p+2;
if Oddprime(p) then return(p) fi;
od;
end;
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Some dumb questions
Date: Wed, 07 Jun 2000 13:52:24 +0200
Jim Gillogly wrote:
> In fact, the best "technique for combination with OTP" is to make it
> a OTP, not a 2TP or a 9TP. Once you allow n > 1, you open the door
> to potential analysis, so you may as well step back and take advantage
> instead of the modern ciphers available for which there's no known
> practical break.
I agree with you fully. As mentioned in other follow-ups of mine, the
intention of my original post is not to recomment the use of n-OTP but
simply to find out how serious/critical a misuse in e.g. employing 2OTP
could be, if appropriate complementary measures were properly taken.
M. K. Shen
------------------------------
Subject: Re: testing non linearity of arithmetic-logic combinations
From: tomstd <[EMAIL PROTECTED]>
Date: Wed, 07 Jun 2000 05:10:30 -0700
In article <[EMAIL PROTECTED]>, "cranky cransky"
<[EMAIL PROTECTED]> wrote:
>could somebody point me towards some research, if there is any,
on non
>linearity or linearity of certain chip level operations
(addition,
>subtraction, xor, shift, etc..) i was thinking of coding
something to try
>different combinations of these operands on integers and
examine the
>results for the combinations that produce the most non
linearity. is such an
>extensive test necessary? is this a well worn path? is it
possible to
>examine the nature of the function itself ( like boolean logic,
or addition
>axioms or whatever ) and work it out, instead of
testing????!?!?!
>aaargh...anywho, help appreciated.
>
Simple. Build a table using your arithmetic operations then
perform the WalshTransform (or FWT) on it. it will give you the
linearness of it.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Paul Shirley <[EMAIL PROTECTED]>
Reply-To: Paul Shirley <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,alt.politics.uk,alt.security.scramdisk,uk.telecom
Subject: Re: Observer 4/6/2000: "Your privacy ends here"
Date: Wed, 7 Jun 2000 13:21:28 +0100
In article <[EMAIL PROTECTED]>, U Sewell-
Detritus <[EMAIL PROTECTED]> writes
>How could you regenerate the random message unless you had
>stored the seed which itself would become a key.
1: its not the decryption key (which does not exist)
2: hand it over anyway, it does them no good at all ;)
--
Paul Shirley: reply address may change at short notice.
cc'ed news posts *unwelcome*
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Thoughts on an encryption protocol?
Date: 7 Jun 2000 13:00:10 GMT
Dido Sevilla <[EMAIL PROTECTED]> wrote:
> every client carries with it two 256-bit master keys which are known
> only to itself and to the server. The first key is used to encrypt
> data transmissions from the client to the server, the second is used
> to decrypt data transmissions from the server to the client.
Why have two keys? A single 256-bit secret per client is large enough,
I think.
> New keys are generated from the old one by applying the MD5 hash to
> the first 128 bits of the old key to get the first 128 bits of the new
> key, and again to the second 128 bits of the old key to get the second
> 128 bits of the new key. Under this system, no key information is
> ever transmitted across the network.
If any session key is broken (or compromised in any other way), all
subsequent `transactions' are insecure. You're also a bit stuffed if a
client and the server ever lose synchronization. It would be better, I
think, to have the client randomly invent a new session key and transmit
it to the server under the shared long-term secret, and then use the
session key for the rest of the session. Be careful about replay
attacks, though.
In this position, I'd recommend an authenticated Diffie-Hellman key
exchange rather than all the symmetric fiddling you're doing anyway.
You then need a set of DSA-ish parameters, which can be shared across
the entire system, and a private key for each client and the server; the
server must also know the public key for each client, and each client
must know the server's public key. The same parameters can probably be
used for the Diffie-Hellman exchange.
> At the end of the data transmission, the MD5 hash associated with the
> plaintext of the sent data is sent to the receiver to ensure that the
> data transmitted was correctly decrypted.
Use a proper MAC. For example, HMAC-SHA1 or HMAC-RIPEMD160. Encrypted
hashes as a poor-man's-MAC aren't a good idea.
> Are there any flaws in this "secure" protocol which I have described?
> Can clever manipulation of the protocol recover key information or any
> such sensitive variables? Are there any suggestions for improving the
> security of this protocol?
> Is there a better cryptographic hash than MD5 out there?
Yes. MD5 has managed to acquire a large mindshare, and for some reason
people haven't moved away from it yet. MD5's security is shaky. Better
alternatives are SHA1 and RIPEMD160, or such things as Tiger if you
don't mind hashes which aren't in wide use. (Tiger was invented by
Biham and Anderson; I don't really know why it's not more popular.)
-- [mdw]
------------------------------
Date: Wed, 07 Jun 2000 15:03:20 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: software protection schemes
RecilS wrote:
> They don't all currently suck. All mass-market schemes suck simply because
> they do not have the time to tailor computer-specific protection. An actual
> recompilation of source (not a key-code algorithm) which relies upon the
> processor's ID to decrypt necissary code seems to work for me.
Why ? You simply replace the assembly code which gets that "unique" id
with a routine which returns that unique id - then your "perfect"
protection is also broken.
> Remember though, nothing is completely secure and if someone wants it bad
> enough there will always be a way to take it.
I think many of these mass-market schemes "suck" less than yours.
However, it is clear there can't be an unbreakable way. One may
hack any copy-protection, no matter how nifty.
------------------------------
From: Rex Stewart <[EMAIL PROTECTED]>
Subject: Re: Brute forcing for Counterpane's Password Safe
Date: Wed, 07 Jun 2000 13:10:28 GMT
I thought of this as I wrote my initial response, (see
paragraph 3) but there are legit possibilities too.
I keep an encrypted container with my address book
and several other things including a book I am working
on. I leave a note on the system that this container
can be brute forced with three dictionary words (which
I will probably increase to four soon). I also have
one which contains things I have to remember which are
better laid to rest with me, and the note for that
container states that nothing in the container would
be worth brute forcing the passkey for it.
The more I think about it though, the more I agree
with your assessment.
--
Rex Stewart
PGP Print 9526288F3D0C292D 783D3AB640C2416A
In article <8hl8mh$3oc$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Paul Rubin) wrote:
> In article <[EMAIL PROTECTED]>,
> Volker Hetzer <[EMAIL PROTECTED]> wrote:
> >Dave Foulger wrote:
> >>
> >> Joeseph Smith <[EMAIL PROTECTED]> wrote in message
> >> news:rab%4.30$[EMAIL PROTECTED]...
> >> > I've been asked to help the executor of the estate
> >> > of a fellow who recently died in Florida. The fellow
> >> > was techno-savvy enough to use Password Safe
> >> > from Counterpane to hold his various account names
> >> > and passwords. Unfortunately, he was not real-world
> >> > savvy enough to leave a way for his heirs to recover
> >> > the data. The executor has tried various obvious
> >> > passwords (names of grandchildren, significant dates
> >> > and places, etc.), but they have not worked.
> >> Ask Bruce for the backdoor nsa key ;-)
> >I agree. Since you appear to have a legitimate reason, you
> >(or the executor) can propably count on the goodwill of
> >Counterpane. But I don't think that they designed weaknesses
> >into their product, so you'll IMHO be out of luck anyway.
>
> Um, I didn't feel like it was worth posting at first, but I'm
> skeptical of the whole story. Password Safe is mostly used for stuff
> like web site login credentials. Why would the heirs want access to
> those? The heirs would normally care about stuff like bank accounts,
> which the executor should be able to locate by knowing the SSN (tax ID
> number) of the dead person.
>
> If I were to die tomorrow, I'd want my financial assets (such as they
> are) and material belongings to go to my family, but I don't think I'd
> want anybody to get the contents of any password protected computer
> files I might have, unless I made specific arrangements.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.privacy.anon-server,alt.security.pgp
Subject: Re: Evidence Eliminator, is it patented, copyrighted, trademarked ?
Date: Wed, 07 Jun 2000 09:41:03 -0400
all together, it is NOT trademark in USA ...
contrary to the WEB site statements ...
[EMAIL PROTECTED] wrote:
>
> I'm not a lawyer, but I do know a little about trademarks. In the U.S.
> you can pretty much make anything your trademark. However, you need to
> establish your mark. The first step is to put a "TM" next to your mark.
> That tells anyone who sees the mark that you have/want to establish
> that mark as your trademark. The serious businesses will then
> "register" the trademark, which then allows one to put the infamous (R)
> next to the mark.
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: Some dumb questions
Date: Wed, 07 Jun 2000 13:45:37 +0000
Mok-Kong Shen wrote:
> It is my fault for not having clearly/correctly stated what I had in
> mind when I wrote that 'there is no plaintext knowledge available'.
> I assume that the opponent knows the language used and even has
> a good frequency distribution. But I assume (from what I know
> about practical use of OTP) also that OTP is not used 'purely',
> i.e. not used alone, and that there is a processing step before doing
> the xor, in order to prevent the opponent from utilizing digram or
> n-gram frequencies and locating certain headers in the messages
> etc. etc.
Depends on the quality of your key material. In theory it can't increase
the security of an OTP, only of a reused keypad.
If you want to hide source patterns and character distributions, why not
simply use the first 15 Bytes as Key and IV for CBC-DES and encrypt the
resulting random noise with your re-used keypad? That will *definitely*
make statistical analysis hard.
> However, I should mention (it's my fault for not
> having done it at the beginning) that my original post does not have
> the intention to 'recommend' the multiple use of OTP (not to
> mention to imply that multiple use could be provably strong) but
> simply to learn whether and why an erroneous employment such
> that an OTP is e.g. used twice is 'really' that fatal, if precautions
> in other respects of the security system are all properly taken.
When people use the OTP its IMHO because they won't bother with
additional stuff. Get a good keystream and you can encrypt anything you
want just perfectly without additional processing. So, if you encounter
a botched up OTP application, it's (IMHO) likely to be a pure OTP
botched up instead of a beefed up botched up OTP. But you might disagree.
If I had to develop an OTP package I'd put effort into ensuring that
the key is never reused by this app and that the random numbers are good.
It's much easier to show the security gain from those measures than from
any preprocessing.
> My point is that if you have a large number of messages and you know
> that these form pairs such that each pair comes from the same segment
> of OTP but no two pairs share the same segment, then the task of
> finding some such pairs is very difficult, as far as I can see. One could
> try all the possible pairings, but that's a combinatorial explosion, in view
> of the fact there is nothing to tell whether the pairing is correct, when
> one picks two arbitrary messages from the pool.
If you know the character distributions of the data just before the xor'ing
you can try all possible pairs. The number of pairs increases only quadratical
with the number of messages, so it's within range of todays computing
capacity.
> For simplicity of discussions, let's say that there are 2*m messages,
> each of b bytes. The OTP is m*b bytes long. Each b byte segment
> of the OTP is used by exactly 2 messages. I don't see how many
> 'varaints' are there which one should try according to your previous
> post and what are these.
This itself is a variant of key reuse. But I don't insist on that
terminology. Fact is, the attacker has to guess that that is what the
sender did. He can check this guess by working on that hypothesis
and looking how far he gets.
Greetings!
Volker
--
The early bird gets the worm. If you want something else for
breakfast, get up later.
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: Brute forcing for Counterpane's Password Safe
Date: Wed, 07 Jun 2000 13:50:43 +0000
Paul Rubin wrote:
> Um, I didn't feel like it was worth posting at first, but I'm
> skeptical of the whole story. Password Safe is mostly used for stuff
> like web site login credentials. Why would the heirs want access to
> those? The heirs would normally care about stuff like bank accounts,
> which the executor should be able to locate by knowing the SSN (tax ID
> number) of the dead person.
I was assuming that there is a legally defensible reason for this.
Is there any circumstance in your country where you can be legally forced
to hand over encryption keys to somebody else or where they can be seized
while you're absent or dead?
> If I were to die tomorrow, I'd want my financial assets (such as they
> are) and material belongings to go to my family, but I don't think I'd
> want anybody to get the contents of any password protected computer
> files I might have, unless I made specific arrangements.
You are right. Thre's got to be a way to make information die with
you. You might have promised this to somebody.
Greetings!
Volker
--
The early bird gets the worm. If you want something else for
breakfast, get up later.
------------------------------
From: jungle <[EMAIL PROTECTED]>
Subject: Re: software protection schemes
Date: Wed, 07 Jun 2000 09:49:50 -0400
all is perfectly true,
"perfect" protection does not exist ...
Runu Knips wrote:
>
> Why ? You simply replace the assembly code which gets that "unique" id
> with a routine which returns that unique id - then your "perfect"
> protection is also broken.
>
> I think many of these mass-market schemes "suck" less than yours.
> However, it is clear there can't be an unbreakable way. One may
> hack any copy-protection, no matter how nifty.
all is perfectly true, "perfect" protection does not exist ...
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Is OTP unbreakable?/Station-Station
Reply-To: [EMAIL PROTECTED]
Date: Wed, 7 Jun 2000 13:33:17 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Greg wrote:
[OTP known-plaintext attacks?]
:> Not if there was a continuous stream of noise to confuse where the
:> messages began.
: No, that's only a weak subterfuge that we could defeat without
: much more effort than needed to crack the message anyway.
It would probably be quite effective against an attacker who used known
plaintext attacks on the OTP to fake messages.
If the message were sandwiched at a genuinely random position within 1K of
random bytes before the OTP was applied (with some signal for stripping
the data off again), this attack would succeed only one time in a
thousand - rather than every single time.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
** 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
******************************
