Cryptography-Digest Digest #642, Volume #13 Tue, 6 Feb 01 15:13:01 EST
Contents:
Re: Mod function (Richard Heathfield)
Re: Finite field/polynomial mathematics (Bob Silverman)
Re: RSA, discrete log Both not secure... (Bob Silverman)
Re: Pseudo Random Number Generator ("Tony T. Warnock")
Re: Callback security (Tom St Denis)
Re: Callback security (stanislav shalunov)
Nobody is on nobody´s side.... no contract is truely signed .... (Markku J.
Saarelainen)
Re: RSA, discrete log Both not secure... ("Carpe Diem")
Re: use of AES?? help (Mike Rosing)
Re: RSA: Finding the private exp instead of factoring (Darren New)
Re: Pseudo Random Number Generator (Bryan Olson)
Re: Pseudo Random Number Generator (Bryan Olson)
Re: Questions about Diffie-Hellman ("Joseph Ashwood")
Re: Phillipine math guy claims to have fast RSA Factoring... (David Schwartz)
RE: Disk Overwriting (Albert P. Belle Isle)
Re: Encrypting Predictable Files ("Joseph Ashwood")
Re: efficient coin flipping ([EMAIL PROTECTED])
Re: On combining permutations and substitutions in encryption (Bryan Olson)
----------------------------------------------------------------------------
Date: Tue, 06 Feb 2001 18:19:47 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Mod function
Nemo psj wrote:
>
> in VB mod is already built in
>
> Buf = 500 mod(255)
> that will mod 500 to 255
But the big question is - did MS check the legal position with Szopa
International before adding MOD support to VB?
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Finite field/polynomial mathematics
Date: Tue, 06 Feb 2001 17:22:01 GMT
In article <95ovud$dvv$[EMAIL PROTECTED]>,
"Brendan Lynskey" <[EMAIL PROTECTED]> wrote:
>
> Sorry for posting such a basic request, but does anyone out there
know of a
> well-made tuorial that covers the above types of mathematics?
See:
Lidl & Neiderreiter "Finite Fields", Encyclopaedia of Mathematics,
Vol 20.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: RSA, discrete log Both not secure...
Date: Tue, 06 Feb 2001 17:24:10 GMT
In article <95nkdj$iag$[EMAIL PROTECTED]>,
"Carpe Diem" <[EMAIL PROTECTED]> wrote:
> Well, you can factor an integer in polynomial time and I do not think
this
> made RSA less secure.
Where did you get this bit of nonsense???
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Pseudo Random Number Generator
Date: Tue, 06 Feb 2001 10:34:13 -0700
Reply-To: [EMAIL PROTECTED]
For two binary streams, the proof is short. Let the probability of a 1
bit be 1/2+P for one stream and 1/2+Q for the other. (This assumes an
excess of 1 bits in each stream, the other three cases workout the same
way.) Note that P and Q are less than 1/2 (except in the case of all 1's
or all 0's). Then the probablity of a 1 from combining two independent
sequences is: (1/2+P)(1/2+Q)+(1/2-P)(1/2-Q) =
1/4+1/2(P+Q)+PQ+1/2-1/2(P+Q)+PQ = 1/2+2PQ. As both P and Q are less than
1/2, 1/2+2PQ is closer to 1/2 than either 1/2+P or 1/2+Q. The other
cases follow by symmetry.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Callback security
Date: Tue, 06 Feb 2001 17:27:35 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Can anyone tell me the security problems with modems that use a simple
> password and callback facility. I'm not interested in how secure the
> password is, just the callback part of it.
These schemes are very old, the idea is that you can't fake a phone number.
You can however go to a friends house and make another account then access
both from your house. But other than that it's a secure way to avoid
duplicate accounts from the same number.
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: stanislav shalunov <[EMAIL PROTECTED]>
Subject: Re: Callback security
Date: 06 Feb 2001 12:56:41 -0500
Steve Amor <[EMAIL PROTECTED]> writes:
> Can anyone tell me the security problems with modems that use a simple
> password and callback facility. I'm not interested in how secure the
> password is, just the callback part of it.
Callback per se is a very good security measure, but, of course,
circumventable.
See, e.g., http://www.lonestar.texas.net/~dub/crack2i.html
Also, some guy used to reroute calls to Western Union customers to a
pay phone to get cash (subverting security of Western Union voice
callback [human] protocol).
And, of course, if you don't use a different modem to call back, you
may be vulnerable to the famous fake dial-tone attack.
Why are you asking sci.crypt? I don't think it ever had any
cryptography implications.
--
Stanislav Shalunov http://www.internet2.edu/~shalunov/
Sex is the mathematics urge sublimated. -- M. C. Reed.
------------------------------
From: Markku J. Saarelainen <[EMAIL PROTECTED]>
Crossposted-To: us.military.army,alt.politics.org.cia,alt.26000
Subject: Nobody is on nobody´s side.... no contract is truely signed ....
Date: Tue, 06 Feb 2001 17:52:36 GMT
What's going on around me
Is barely making sense
I need some explanations fast.
I see my present partner
In the imperfect tense
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Carpe Diem" <[EMAIL PROTECTED]>
Subject: Re: RSA, discrete log Both not secure...
Date: Tue, 6 Feb 2001 12:18:37 -0600
O.K. Mea Culpa! My irony was not clear.
Carpe Diem
"Bob Silverman" <[EMAIL PROTECTED]> wrote in message
news:95pbvc$dqr$[EMAIL PROTECTED]...
> In article <95nkdj$iag$[EMAIL PROTECTED]>,
> "Carpe Diem" <[EMAIL PROTECTED]> wrote:
> > Well, you can factor an integer in polynomial time and I do not think
> this
> > made RSA less secure.
>
> Where did you get this bit of nonsense???
>
>
>
> --
> Bob Silverman
> "You can lead a horse's ass to knowledge, but you can't make him think"
>
>
> Sent via Deja.com
> http://www.deja.com/
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: use of AES?? help
Date: Tue, 06 Feb 2001 12:40:05 -0600
[EMAIL PROTECTED] wrote:
> My questions are as follows:
> Am I ok just using Symmetric keys and hiding this
> key in a file??? In the component itself???
> What is my weakest link here - the act of hiding
> the key or the component wrapper that I built?
Hiding keys in a file is generally a bad idea. If the file gets stolen
all the data is exposed. You are much better off having some person
type in a key for every shift and use that to decrypt a master key which
decrypts all the data. When they log off for the day, the file gets
locked up. Use several people so you always have a way to unlock the
data!
If you have to run a 24/7 operation, then have the data unavailable for
10 minutes every shift change. This will ensure the file is locked before
the next guy shows up and it gives you a clear line of control (and blame).
As always, security depends on who you want to defend against. There
is always a way to steal information. The best you can do is raise the
price to where it is cheaper to rediscover the information rather than
steal it. Good luck!
Patience, persistence, truth,
Dr. mike
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: RSA: Finding the private exp instead of factoring
Date: Tue, 06 Feb 2001 18:43:37 GMT
Brian Wong wrote:
> Does nobody read errata anymore?
> http://www.counterpane.com/ac2errv30.html:
> "* Page 157: The section on "Thermodynamic Limitations" is not quite
> correct. It requires kT energy to set or clear a single bit because these
> are irreversible operations. However, complementing a bit is reversible and
> hence has no minimum required energy. It turns out that it is theoretically
> possible to do any computation in a reversible manner except for copying out
> the answer. At this theoretical level, energy requirements for exhaustive
> cryptanalysis are therefore linear in the key length, not exponential."
Except that, as I understand it, the less energy you use, the more time it
takes. You have to put *some* energy into the computation to keep it moving
forward and not spontaneously reversing. The less energy you put in, the
more often the calculation will backtrack at random. So the energy level
might be linear, but the time will skyrocket.
(I'm not a physicist, but I *did* read Feynman's Lectures on Computation.
;-)
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
Ignorance can be cured. Naivety cures itself.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Pseudo Random Number Generator
Date: Tue, 06 Feb 2001 19:09:37 GMT
Mok-Kong Shen wrote:
> Bryan Olson wrote:
> >
> > Douglas A. Gwyn wrote:
> > > Matthew Montchalin wrote:
> > > > On Sat, 3 Feb 2001, CR Lyttle wrote:
> > > > |XOR two "almost" random uncorrelated data streams,
> > > > | should result in
> > > > |a more nearly "white" data output stream.
> > > > I sure hope so. But are we relying on gut feelings here, or on
> > > > something we can prove?
> > >
> > > That's provable, since they are uncorrelated.
> >
> > I think we'd need streams to be independent, and even then
> > I don't think we can prove that the XOR is strictly closer to
> > white than either of the terms.
> >
> > (I'm assuming "white" means all streams equally likely, and thus
> > closer to white means lower redundancy.)
>
> What can be proved is the following:
>
> For m non-degenerate independent integer random variables
> over [0,n-1] their sum mod n approaches a uniform random
> variable as m increases. If one of the random varaible is
> uniform, then any value of m results in a uniform random
> variable.
Counterexample: Lent n = 49, and the distribution of each
variable be uniform over the 42 integers in [1..48] that are
not divisible by 7, and zero elsewhere.
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Pseudo Random Number Generator
Date: Tue, 06 Feb 2001 19:12:38 GMT
Tony T. Warnock wrote:
> For two binary streams, the proof is short. Let the probability
> of a 1 bit be 1/2+P for one stream and 1/2+Q for the other.
> (This assumes an excess of 1 bits in each stream, the other
> three cases workout the same way.)
That assumes the only deviation from random is a constant
bias, which was not given.
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Questions about Diffie-Hellman
Date: Tue, 6 Feb 2001 11:12:35 -0800
"Julian Morrison" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> 1) Can a wiretapper who sees *all* messages passed to and fro figure out
> the key?
With properly chosen keys, no. The information the attacker would have to
use, and the equation that would have to be solved are:
known
p - a large prime, on the order of 512 bits or above for a strong
implementation
g - a generator value, this is generally a smaller prime
X = g^x mod p
Y = g^y mod p
given p,g,X,Y solve for K=g^(x*y) mod p.
Given x or y this is easy, but solving for x or y given X or Y is the
discrete logarithm problem, which is currently hard
> 2) Do the two hosts need to know anything at all about one another prior
> to key exchange (public keys or any such)?
To avoid other forms of attack it is required that the possess each others
public keys, or some trust chain for a self-provided public key. Otherwise
Eve does the following
Xaviar has his public key X
Yolanda has her public key Y
g, and p and publically known
Eve creates her public key E=g^e mod p
Eve stands between Xaviar and Yolanda and impersonates each to the other.
Xaviar and Yolanda see:
X->Y: My public key is X, what is yours?
Y->X My public key is Y.
X and Y talk in some strange language they just agreed on.
What is actually happening is (where Ey means Eve is impersonating Yolanda):
X->Ey: My public key is X, what is yours?
Ey->X: My public key is E
Ex->Y: My public key is E, what is yours?
Y->Ex: My public key is Y
X and Ey, Ex and Y talk in different strange lanuages but Eve can repeat
what was said or change it.
Joe
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Phillipine math guy claims to have fast RSA Factoring...
Date: Tue, 06 Feb 2001 11:26:58 -0800
DJohn37050 wrote:
> Ron Rivest was gentle with him. hear hear
> Don Johnson
IMO, the reporter should not be treated so gently.
DS
------------------------------
From: Albert P. Belle Isle <[EMAIL PROTECTED]>
Subject: RE: Disk Overwriting
Date: Tue, 06 Feb 2001 14:32:35 -0500
Reply-To: [EMAIL PROTECTED]
Since, once again, we have posters authoritatively claiming either
(1) "Disk data can be recovered from under any amount of overwriting,"
or
(2)"Just overwriting once with FF is sufficient to preclude recovery,"
both of which statements are true, but only in context, it seems
useful to once again post the following overview in an attempt to
provide such context:
Forensic disk data recovery attacks attempt to read "deleted" (or
inadequately overwritten) magnetically stored data on your disk either
(1) through its drive controller connector, using PC-hosted software;
(2) through its drive heads, bypassing the disk's controller circuits;
or
(3) directly on each disk platter's recording surface in a clean-room.
Class 1 attacks can be mounted directly with forensic software, hosted
on your PC or on the attackers' PC. These software-based attack
measures can be countered with software-based countermeasures; viz.,
any kind of disk data overwriting (such as Clearing per DOD 5220.22-M)
that is applied to _all_ sensitive plaintext on the disk.
Class 2 attacks use special amplifiers and signal processing to
extract previously recorded data from under subsequent overwrites.
They rely on increased capabilities over the disk's on-board
electronics. Sanitizing per DOD 5220.22-M was designed to counter such
attacks by increasing the noise-to-signal ratio beyond their
capabilities.
Many (but not all) INFOSEC people believe that the increased
signal-processing sophistication of the on-board controllers required
to even read the last-written data has kept Sanitizing ahead in this
particular measure/countermeasure race. However, most question the
adequacy of Sanitizing in protecting older, lower-density disks
(especially diskettes) against the most modern and sophisticated Class
2 attacks.
Class 3 attacks (such as with magnetic force microscopy), are
generally considered able to penetrate any software countermeasures,
including _any_ kind of overwriting. They are very costly techniques
to use to recover the complete image-as-it-used-to-be of an
overwritten multi-gigabyte disk, as opposed to a few specifically
targeted bytes.
(Try getting a quote for recovery of overwritten data - not just
"reformatted" drive contents.)
Nevertheless, any data of sufficient value to intelligence services or
comparably funded adversaries should not have its confidentiality rely
upon overwriting countermeasures.
The value of your data to the kinds of attackers who can use each
class of techniques will determine whether you must counter that
class.
This is the basis for requiring defense contractors to use Clearing or
Sanitizing per DOD 5220.22-M (for re-use or for disposal,
respectively) of media containing data classified as Confidential or
Secret, while requiring NSA-approved degaussing and destruction for
Top Secret media.
The armed services' standards for disk data overwriting are NAVSO
P5239-26, AFSSI-5020 and AR 380-19, respectively.
All of them meet or exceed the requirements of DOD5220.22-M (the
latest ones, not the old 3-pass "character, complement and random"),
and all of which require READ-BACK VERIFICATION - which most
"overwriting software" neglects - to be sure that improper
cache-flushing leaks haven't resulted in the kind of "fast
overwriting" that never makes it to disk (like the PGP bug).
For an overview of the use of forensic software for side channel
attacks on Windows cryptosystems, and countermeasures to them, see the
tutorials on the Cerberus Systems web-site in my signature block.
Albert P. BELLE ISLE
Cerberus Systems, Inc.
================================================
ENCRYPTION SOFTWARE with
Forensic Software Countermeasures
http://www.CerberusSystems.com
================================================
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Encrypting Predictable Files
Date: Tue, 6 Feb 2001 11:37:14 -0800
[still on the topic of encryption, but leaving Encrypting predictable files]
Well let's see if we can take a look at these claims in detail, shall we.
D/s<[EMAIL PROTECTED]> wrote in message
news:95o26v$bbu$[EMAIL PROTECTED]...
> changes the lenght of files.
> uses Rijndeal in a way that can encrypt any file without adding
information.
Perhaps DS needs a review of reality once again. The above statements are by
themselves clearly in opposition. However there's an additional matter that
he apparently keeps forgetting. Encryption is itself an act of adding
information to a file, with decryption being an act of removing the same
information, that's what the key does. In good encryption it is impossible
to remove the added information (the key and algorithm) without knowing the
information, in bad encryption it is possible or likely possible that the
information can be removed. If DS had bothered paying attention for the
years that he has been a pain in the side of sci.crypt he would have known
that by now (it's at least the third time I've told him).
Now to get back on topic, when you are encrypting predictable files you
_want_ information to be added, or rather you want entropy added to obscure
the information in the file. This information can be in the form of padding,
cryptographic keys, IVs, etc depending on the requirements of the system.
Just to point out a rather painful example for the strict 1-1 onto mapping
without change of file length that certain individuals vocally support in
spite of being continually corrected, take a known transmission of one of 2
messages:
"yes"
"I'd like to discuss this in great detail with you at my earliest
convenience, how about you call me about 8:05 AM on December 26, 2007"
encrypting these using a non-padded method that retains the file length, it
is fairly easy to distinguish the two messages. I assume you want to use
encryption to hide what's being said. If you want a more real example take a
look at wha tthe US did to Japan during WWII repeatedly, Japan used code
under encryption, to break the code the US fed them false information. often
putting them in situations very similar to the above. What I recommend
instead is to pad the messages to certain chunking (note: this method is
virtually unused so terminology is hard to come by) lengths, 512 bytes or
whatever is most useful for you to hide the data, if you pad with random
data you shouldn't have any problems, then apply an
All-or-nothing-transform, and then encrypt. Yes you are going to have
transmission bloat, but you will also have quite a bit of security. The
chunk padding will protect the actual length of your messages, the AONT will
protect against many discovered weaknesses in the cipher, and distribute the
entropy from the padding across the entire file, the cipher will of course
protect the AONT.
Joe
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: efficient coin flipping
Date: Tue, 06 Feb 2001 19:43:11 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> I use dice to determine my password.
26+10=36, very nice! All alphanumeric values. I hadn't seen that
before. That implies your passwords have no capital letters or
ampersands or such.
If I wanted bits, I could ignore pairs of dice that hit the top 4 of the
36 states, giving me 5 bits per pair of dice thrown. The man on the
street would probably consider that suspicious, though. 8-sided or
16-sided dice would also seem awfully peculiar.
- Bob Jenkins
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: On combining permutations and substitutions in encryption
Date: Tue, 06 Feb 2001 19:42:11 GMT
Benjamin Goldberg wrote:
> Bryan Olson wrote:
[...]
> > The reduction time is polynomial in the size of input.
>
> What do you mean the size of the input?
The length of the input string.
Formally, a function f(s):string->string is polynomial time
iff there exists a Turing machine M and a polynomial p(x) such
that the M, when given any string s, terminates with f(s) in
p(length(s)) or fewer state transitions.
> Or, to put it another way, suppose you have AES with a 192 bit key.
As David Wagner explained, the constant cases are uninteresting.
[...]
> If conversion takes polynomial time, and P=NP, [solving the 3SAT takes
> polynomial time], then breaking any block cipher takes polynomial time
> in terms of the keysize.
True. Of course we have to assume enough plaintext and
ciphertext to determine the key (or just ciphertext to cover
the unicity distance for a plaintext language that is in P),
and that encryption is polynomial time.
Note that once we have the key, we can quickly verify it.
Informally, if P=NP, then answers that are verifiable in
polynomial time are also computable in polynomial time.
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
