Cryptography-Digest Digest #122, Volume #10 Fri, 27 Aug 99 16:13:03 EDT
Contents:
Re: How to apply for security clearance? (Medical Electronics Lab)
Re: How Easy Can Terrorists Get Strong Encrypt? (Medical Electronics Lab)
Re: receiving a piece of message (SCOTT19U.ZIP_GUY)
Re: receiving a piece of message (Keith A Monahan)
Re: 512 bit number factored (DJohn37050)
Re: receiving a piece of message (wtshaw)
Re: 512 bit number factored (Robert Harley)
Re: passphrases (Keith A Monahan)
Re: How to apply for security clearance? (Jerry Coffin)
Re: 512 bit number factored (DJohn37050)
Re: Can americans export crypto when in another country? (Jerry Coffin)
Re: Fooling Key Escrow (Enterrottacher Andreas)
----------------------------------------------------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: How to apply for security clearance?
Date: Fri, 27 Aug 1999 13:07:23 -0500
[EMAIL PROTECTED] wrote:
>
> and how much it cost for the clearance?
In what country? In the US there are a great
many types of security clearence, with costs
any where from $50k to $500k and time of 6 months
to 2 years. (Actually, the time might be less
now, it's been a long time since I've been thru
this crap.)
Patience, persistence, truth,
Dr. mike
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: How Easy Can Terrorists Get Strong Encrypt?
Date: Fri, 27 Aug 1999 13:00:23 -0500
Trevor Jackson, III wrote:
>
> TI apparently likes belt, suspenders, and straightjacket.
That's why lawyers get paid so much. They know how to attach
them all at once!
:-)
So if I loan the CD to an Iraqi student, it *might* be illegal.
But the student can take the CD, copy it onto their portable,
and go home for holidays. At home, her government copies the
disk and hands it over to a few terrorists.
Suppose the US has a spy with the terrorists, and traces the
source back to me (with help of the FBI back in the US). Would
the Feds get me for breaking a *law* or a *regulation*?
I agree that TI is just doing CYA, but there's a presumption
on their part that somewhere, there may be a law which does in
fact prohibit or restrict the distribution of their software.
I presume it's because there *is* a law or regulation that has
bit them in the butt once before. Otherwise they wouldn't waste
their breath, lawyers cost too much to waste time on useless
boiler plate.
The whole thing is pretty dumb, code moves at light speed and
beauracrats move at snail speed. It's a fair bet that most
"bad guys" at the level US Feds worry about have good crypto.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: receiving a piece of message
Date: Fri, 27 Aug 1999 17:39:03 GMT
In article <7q615u$mel$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Keith A
Monahan) wrote:
>Gary,
>
>So, if its ECB(electronic code book) only mode, he is safe -- because there
>is a one to one mapping of plaintext -> ciphertext but any of the other
>modes that involve chaining or feedback require the previous ciphertext
>block to properly set the IV , in which case, if he does not have
>he would be screwed.
>
>Right?
>
No your WRONG. THE IV only effects the next BLOCK in standard encryption.
It is designed that way. And most people like you are lead astray. It is very
very easy to test this.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: receiving a piece of message
Date: 27 Aug 1999 17:51:52 GMT
I wrote,
: >Gary,
: >
: >So, if its ECB(electronic code book) only mode, he is safe -- because there
: >is a one to one mapping of plaintext -> ciphertext but any of the other
: >modes that involve chaining or feedback require the previous ciphertext
: >block to properly set the IV , in which case, if he does not have
: >he would be screwed.
: >
: >Right?
: >
dscott wrote,
: No your WRONG. THE IV only effects the next BLOCK in standard encryption.
: It is designed that way. And most people like you are lead astray. It is very
: very easy to test this.
When you say standard encryption, are we including CBC in that description?
Because most of the CBC implementations I have seen look like this for the
CBC decryption function.
oldiv = original first IV
for (length=0 to bufferlength)
{
newiv = data = srcbuffer // ciphertext
ECB_Decrypt(data, key)
outputbuffer = data xor oldiv // plaintext after xor
oldiv = newiv
}
So looking at this function, you need to have the ciphertext block prior
to the current block in order to have the iv to decrypt the current block.
Without the oldiv, the very first(and subsequent) decryption(s) would
fail.
Keith
: David A. Scott
: --
: SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
: http://www.jim.com/jamesd/Kong/scott19u.zip
: http://members.xoom.com/ecil/index.htm
: NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: 512 bit number factored
Date: 27 Aug 1999 17:01:34 GMT
I humbly learn my lesson. Thanks for all in responding.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: receiving a piece of message
Date: Fri, 27 Aug 1999 11:57:26 -0600
In article <7q615u$mel$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Keith A Monahan) wrote:
> Gary,
>
> So, if its ECB(electronic code book) only mode, he is safe -- because there
> is a one to one mapping of plaintext -> ciphertext but any of the other
> modes that involve chaining or feedback require the previous ciphertext
> block to properly set the IV , in which case, if he does not have
> he would be screwed.
>
> Right?
>
Wrong, since there is another approach to the concept of strength, that
each block can be encrypted into many forms itself. The only excuse for
chaining is to try to strengthen an algorithm that is already known to be
too weak.
The thrust of this question gets at why the concept of inductive
algorithms is most compatable with message survivability; neither loss of
a part destroying the whole message nor a weaknesses of a single mapping
need be accepted.
The work around is to use the less than adequate techniques most commonly
used, but cut the message into small parts. But, if an adequate inductive
encryption algorithm is used in the first place, the whole message can be
repeated N times to insure it getting there, without appreciably assisting
in an attack.
--
I'd rather have prime rib than prime numbers.
Moore's Law always yields to Les's Rule.
------------------------------
From: Robert Harley <[EMAIL PROTECTED]>
Subject: Re: 512 bit number factored
Date: 27 Aug 1999 20:39:59 +0200
Don Johnson writes:
> Also look at
> http://www.certicom.com/press/RSA-155.htm for more analysis of the results.
In the section called "The ECC ALTERNATIVE" this paragraph appears:
>The fastest algorithm today known for the ECDLP is the parallelized
>version of Pollard's rho algorithm. Unlike the case of the NFS
>algorithm for the integer factorization problem, the behaviour of
>Pollard's rho algorithm is very well understood.
I find the suggestion that the ECDL case is very well understood
amusing given the subtleties that don't show up when running tiny
examples but make a difference when doing big problems (i.e.,
trillions of elliptic curve operations).
They aren't described properly in papers that I'm aware of but they
will be in my thesis eventually (some are described in an upcoming
paper by Duursma, Gaudry and Morain).
The paragraph continues:
>Concrete estimates
>are known for both its expected running time and its memory
>requirements, and these estimates have been confirmed by practical
>experience (see the Certicom ECC Challenge [8]).
This is great F.U.D.
The most recently solved problem from the Certicom Challenge was
solved in a tenth of the time that was originally expected (by using an
algorithm discovered by Ari Singer and myself and independantly by
Wiener and Zuccherato on one hand and Gallant, Lambert and Vanstone on
the other).
Practical experience only confirmed estimates after those estimates
were downgraded to take the new algorithm(s) into account.
A little honesty in the "analysis" wouldn't hurt.
Bye,
Rob.
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: passphrases
Date: 27 Aug 1999 19:20:11 GMT
Justin,
I understand your point - but I don't think it's valid. First off, when
I talk about changing your passphrase OFTEN, I'm referring to perhaps
once a month. This is a very small fraction of the total time, perhaps
just a few packets. The eavesdropper would have to be listening exactly
at that moment in order to intercept the password change. BESIDES,
if your password is being sent in the clear then your data is probably
being sent in the clear, so why have anything encrypted?
And it depends on the type of encryption as well. If we are using
a symmetric encryption model, then the keys are assumed to be secure
and are definitely NOT supposed to be transmitted EVER over the
same communication channel as the ciphertext. That would certainly be
instant death. Let me quote section 8.3 of Bruce S's _Applied Cryptography_
"Alice could send Bob the symmetric key over their communications channel -
the one they are going to encrypt. this is foolish; if the channel warrants
encryption, sending the encryption key in the clear over the same channel
guarantees that anyone eavesdropping ......can decrypt all communications"
Public Key crypto comes into play here.
In order to completely analyze this, we would have to be much more specific
as to the environment. Changing a passphrase on an encrypted disk is
different from say changing a passphrase on a local network server, from
telnetting to a unix host to change your pw, from changing your password
over a secure shell(ssh) connection.
Despite the environment, I would still recommend changing any passphrase
on a frequent(contrast from regular) basis.
Keith
Justin Scribner ([EMAIL PROTECTED]) wrote:
: One thought that came to my mind is that the more often you have to
: change
: your passphrase, the more often it is transmitted. Often the
: transmission is unencrypted; thus, susceptible to eavesdropping. Please
: feel free to argue this point as I am always eager to learn.
: Sincerely,
: Justin G. Scribner
: Si hoc legere scis nimium gruditionis habes.
: On Thu, 26 Aug 1999, Anton Stiglic wrote:
: > Keith A Monahan comment is right. Just the fact that someone could
: > see you typing your password (or get partial info), or just someone
: > listening on the back bone of your network, scanning for passwords
: > if you connect to the internet without ssh or somethig (this has happend
: > at a university in Montreal), is good enough a reason to change your
: > password every so often.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: How to apply for security clearance?
Date: Fri, 27 Aug 1999 13:10:00 -0600
In article <7q6e65$pbc$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> and how much it cost for the clearance?
Generally speaking, you don't apply for a security clearance --
somebody applies for one on your behalf. First of all, anything
that's secure is only supposed to be distributed on a need-to-know
basis.
If you're working in some area that convinces the government that you
need to know something they consider secure, then they try to get you
a security clearance so they can tell you what you need.
IOW, a security clearance by itself doesn't get you access to
anything. I had a TS/SCI clearance for years (I hope saying that
won't get me in trouble... <G>) but offhand I don't remember seeing
anything above secret level, and what I did see was definitely
necessary for my job.
With that said, I'm sure the cost varies depending on the level of
clearance involved -- a secret-level clearance gets done on LOTS of
people, and I believe only costs a few thousand dollars. A TS/SCI
clearance undoubtedly costs a LOT more -- at that point, they not only
check up on you, but your relatives and friends, to see if (horrors)
one of your cousins might have hung out with somebody who had too long
of hair in the '70s...
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: 512 bit number factored
Date: 27 Aug 1999 19:47:30 GMT
>In the section called "The ECC ALTERNATIVE" this paragraph appears:
>
>>The fastest algorithm today known for the ECDLP is the parallelized
>>version of Pollard's rho algorithm. Unlike the case of the NFS
>>algorithm for the integer factorization problem, the behaviour of
>>Pollard's rho algorithm is very well understood.
>
>I find the suggestion that the ECDL case is very well understood
>amusing given the subtleties that don't show up when running tiny
>examples but make a difference when doing big problems (i.e.,
>trillions of elliptic curve operations).
>
>They aren't described properly in papers that I'm aware of but they
>will be in my thesis eventually (some are described in an upcoming
>paper by Duursma, Gaudry and Morain).
>
Yes, size can make a difference, but the
basic Pollard rho algorithm is understood and one can understand why it is
expected to succeed when it is expected to succeed.
>
>The paragraph continues:
>
>>Concrete estimates
>>are known for both its expected running time and its memory
>>requirements, and these estimates have been confirmed by practical
>>experience (see the Certicom ECC Challenge [8]).
>
>This is great F.U.D.
>
>The most recently solved problem from the Certicom Challenge was
>solved in a tenth of the time that was originally expected (by using an
>algorithm discovered by Ari Singer and myself and independantly by
>Wiener and Zuccherato on one hand and Gallant, Lambert and Vanstone on
>the other).
Research is always ongoing. In some sense, the fact that the structure of some
curves has now been taken into account is GOOD news as this allows a more
precise analysis of the security of these curves. For example, see the
recently announced NIST curves. There, one can use a random curve over Fp,
random curve over F2**p or Koblitz curve over F2**p. So the "fudge factor" for
Koblitz over random (and for the negative of a point speedup) has now been
accounted for.
>
>Practical experience only confirmed estimates after those estimates
>were downgraded to take the new algorithm(s) into account.
>
Yes, these were new insights, which is EXACTLY the purpose of the ECC
challenge, to give an practical example of what is thought to be a hard problem
and see how hard is really is.
>
>A little honesty in the "analysis" wouldn't hurt.
>
Notice that Certicom did not revise any of its challenges or change amounts of
money for solutions. Certicom researchers were one of the groups that found a
(slightly) better way to attack some curves.
I for one do not see any need for more "honesty".
The basic facts seem to be:
1. Keysizes considered secure grow over time due to advances in algorithms and
compute power.
2. ECC uses shorter keysizes than alternatives, being based on a harder general
problem (apparently).
3. Refinements for complexity estimates continue to be found.
4. Algorithmic breakthroughs are possible. RSA 512 was thought totally
unbreakable just a few years ago.
>
>Bye,
> Rob.
>
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Crossposted-To: talk.politics.misc,talk.politics.crypto
Subject: Re: Can americans export crypto when in another country?
Date: Fri, 27 Aug 1999 13:09:58 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> I find it strange if not amusing that cryptographers from the US, civilian
> and government, travel frequently to foreign locations where they share
> their thoughts and ideas with other foreigners.
Irrelevant -- sharing thoughts and ideas is (at least according to US
law) an entirely different sort of thing from sharing software that
takes specific actions. I.e. the difference is between sharing
thoughts (falls under free speech) and giving you a machine that takes
an action (no longer speech, and therefore not protected).
If you read the reasoning in the recent court case, this specific
point was emphasized: the defense for exporting source code was that
the source code was being used primarily to communicate ideas to
another person. As such, it was considered protected as free speech.
Object code, which wouldn't normally be used for communication to
another person, but would be used primarily for directing the actions
of the computer, would (probably) no longer fall under the same
protection.
In short, writing, speaking, etc., about nearly any subject is pretty
much free unless you sign some sort of agreement to the contrary ahead
of time (e.g. an NDA or a release form when you receive a security
clearance).
Of course, in many cases, as with source code, it's difficult to
separate the two -- in particular, if you describe an algorithm
extremely explicitly and unambiguously, chances are pretty good that
you'll end up using some sort of notation that _could_ be converted to
a computer program by reasonably automated means; in many cases, the
most obvious unambiguous language for describing many algorithms is a
programming language.
> Indeed, even the
> government had one meeting of the AES in Rome last Spring, and I might
> add, adjacent to a Fast Encryption Workshop.
...which is perfectly fine as long as they didn't distribute machine-
readable versions of the encryption algorithms to non-US citizens.
------------------------------
From: Enterrottacher Andreas <[EMAIL PROTECTED]>
Subject: Re: Fooling Key Escrow
Date: Fri, 27 Aug 1999 21:29:13 +0200
Gary schrieb:
>
> Are there cryptographic systems that can produce decoy keys for key-escrow
> that yield a decoy message?
>
> Can it only be feasibly done with One Time Pad (OTP)?
What you need is a system that produces a ciphertext C with
enc(P1, K1) = C
enc(P2, K2) = C
If you want as well P1 as P2 to be a freely chosable plaintext you get
almost
the definition of the OTP. (If randomly chosen K1 and K2 may not be
equiprobable,
but that's the only difference.)
For messages of 1 block each you could chose a strong and a weak
blockcipher:
The real plaintext P1 produces
enc(P1, K1) = C
And you'll have to calculate K2 to get
dec(C, K2) = P2
I'd say keysize should be at least blocksize to get a key for every
possible P2.
The main problem is that this system doesn't work for larger messages or
the keysize
has to become as large as the whole message.
Did you think about public-key algorithms with a hidden channel?
Enterrottacher Andreas
[EMAIL PROTECTED]
[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
******************************
