Cryptography-Digest Digest #661, Volume #13 Thu, 8 Feb 01 23:13:00 EST
Contents:
Re: Encrypting Predictable Files [now on AONTs] (Splaat23)
Re: Disk Overwriting (Albert P. Belle Isle)
Re: Mod function (Darren New)
Re: Phillo's alg is faster than index calculus (Tom St Denis)
Re: Encrypting Predictable Files [completely about AONT, the file is completely
gone] ("Joseph Ashwood")
Re: relative key strength private vs public key (Bob Silverman)
Re: Phillo's alg is faster than index calculus (Bryan Olson)
Re: Encrypting Predictable Files (Bryan Olson)
Rijndael S-box derivation (mjconroy)
Re: crack my enkryption ("John A. Malley")
Re: CipherText patent still pending (Bryan Olson)
Re: Mod function (Darren New)
----------------------------------------------------------------------------
From: Splaat23 <[EMAIL PROTECTED]>
Subject: Re: Encrypting Predictable Files [now on AONTs]
Date: Fri, 09 Feb 2001 01:02:51 GMT
Definately right. Security _strictly_ through obscurity is bad - this
is what is generally meant when people say "security through
obscurity".
The trick is this: convincing people that your system is secure (aka
using secure elements) without compromising the knowledge of exactly
_which_ elements you are using. No real good solutions to this besides
having a private security analyst come in and, under NDA, check the
code/algorithm. But then everyone has to trust the verifier, and it
might prove to be cheaper to bribe the verifier for the cipher rather
than reverse-engineer.
Of course, the NSA has the best of all worlds: it can have secure
algorithms hidden through an extra layer of obscurity. They seem to
have handled the issue of public disclosure of classified info pretty
well. ;)
Unfortunately (or fortunately), we as cryptographers are paranoid, so
the only system that works for us is full disclosure, where we can
inspect the system ourselves and verify anything and everything.
- Andrew
In article <95u9jq$m7n$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] wrote:
> > > leave signatures in the result output. What I mean by this
> > > is that if someone studies enough of your messages why let
> > > them know what method your using for encryption. ... But why
> > > add weknesses in when it is not necessiary.
> >
> > The counterargument is that security should not depend on
> > the enemy not knowing the method you're using anyway, so
> > if you have sufficient security anyway then the fact that
> > the enemy learns your method doesn't help him any.
> >
> > Simplistic example:
> > filep -> [scott19u] -> filec1
> > filep -> [scott19u] -> [prefix with "SCOTT19U:"] -> filec2
> > While filec2 is about 10 bytes longer than filec1, which
> > is a different kind of drawback, I don't think you want to
> > argue that it is *less secure* just because the enemy can
> > readily identify the method of encryption by examining the
> > ciphertext.
> >
>
> Why not even the NSA keeps its ciphers secret and it thinks
> they are secure. Why give any information you don't have to.
> Sure I think my cipher is strong but I think any cipher can be
> broken to a degree far easier than most people let on. Also
> why advertise to an enemy so that they can focus all there
> resources on the methdos you used. If anysthing leave a false
> trail so they think you used something else. Or use two or
> more methods in series. Unfortunately this can't be done with
> Public key crypto. But even in PGP alot more of the structure
> of the file or method used could be hidden in the public key part.
>
> Dave
> I anwsered this yesterday but it did not post for some reason
>
> Sent via Deja.com
> http://www.deja.com/
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Albert P. Belle Isle <[EMAIL PROTECTED]>
Subject: Re: Disk Overwriting
Date: Thu, 08 Feb 2001 20:28:12 -0500
Reply-To: [EMAIL PROTECTED]
On 8 Feb 2001 15:07:49 GMT, [EMAIL PROTECTED] (Richard Herring) wrote:
>In article <[EMAIL PROTECTED]>, Albert P. Belle Isle
>([EMAIL PROTECTED]) wrote:
>> 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:
>
>How about turning it into an official FAQ ?
I guess that's the right thing to do, but no one else seems to have
done so, and somehow I haven't yet found time, either.
A fair amount of the above summary was taken verbatim from
http://www.CerberusSystems.com/INFOSEC/threats.htm
by the lazy expedient of cut-and-paste.
That material is, however, page 3 of a presentation focused on data
remanence vulnerabilities leading to side-channel attacks that must be
countered in order for a cryptosystem to meet or exceed FIPS 140-1 in
the security-hostile environment of Windows platforms.
One of these days I'll try to pull together a broader discussion.
Peter Gutmann's widely circulated Usenix paper presents an
unclassified discussion of the technical bases for various possible
approaches to data remanence attacks, and reasonable sounding
"home-brew" versions of disk overwriting countermeasures.
What I believe is needed is some perspective on the relative
probabilities of professional versions of those attacks being employed
in the context of threat profiles that are realistic for particular
types and values of data with which most of us are concerned.
One way to gain such perspective is to look at what DoD does to
protect various levels of sensitive data against professional
intelligence services, and try to draw some sort of parallels with
one's own data which, for most of us, is in an entirely different
universe of value and of potential adversaries.
An obvious set of Class 1 ("keyboard") data remanence attacks are
those that can be easily launched by anyone in possession of the
commercially available packages originally developed for computer
evidence recovery by law enforcement organizations and marketed to
"computer forensics" specialists-for-hire for "electronic discovery"
in litigation (and anyone else with the purchase price).
While Class 2 ("laboratory") attacks are not as difficult or expensive
to employ as Class 3 ("clean room") attacks, neither one is typically
available to local and state law enforcement organizations in the US,
except through federal laboratories (like the FBI's new regional lab
in San Diego) on a small number of very high-profile prosecutions.
(Note, however, that the owner of all those FBI Lab capabilities
employed the cheap expedient of a keyboard bug to sniff a PGP
passphrase in a recent, high-profile, organized crime case in NJ.)
Clearly, there are mining or oil companies with greater resources who
might find certain classes of data, such as resource exploration
results, of sufficient value to merit spending larger sums to acquire.
I'm personally unaware of any unclassified data on what the
cost-per-byte is for such work, but I do know that the leading
commercial "data recovery" services won't quote such jobs at all.
However, I personally believe that far more data is at risk from
forensic software attacks on laptop disk images quickly acquired in
hotel room "bag jobs" by Sam Spade the "competitive intelligence
expert," than from the sexier sounding, more technically
proficient/capital intensive, instrumentation-based attacks.
Obviously, it all comes down to thinking through your real threat
profile. Otherwise, you're at risk of focusing on countermeasures to
attacks that will never come and missing vulnerabilities that are the
avenue of attack most likely to be employed by your real adversaries.
Going into "analysis paralysis" about various esoteric vulnerabilities
can prevent you from employing practical countermeasures to the more
prosaic (and more probable) ones you should _really_ worry about.
(IMHO).
That's what really prompted my posting.
Albert P. BELLE ISLE
Cerberus Systems, Inc.
================================================
ENCRYPTION SOFTWARE with
Forensic Software Countermeasures
http://www.CerberusSystems.com
================================================
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: Mod function
Date: Fri, 09 Feb 2001 01:46:44 GMT
Jerry Coffin wrote:
> Reasonably recent US patents are available online at
> www.delphion.com. Offhand I don't have the number of the patent
> being discussed though...
And of course www.uspto.gov is the definitive source of online patents. And
searchable via a variety of means.
--
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: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Phillo's alg is faster than index calculus
Date: Fri, 09 Feb 2001 01:54:58 GMT
In article <95v7r3$itv$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> > My point is why would I make claims that I am not prepared to back up?
> If I
> > am not a theologian than I shouldn't stake claims.
> >
> > Likewise if he can't back up his algorithm with solving my system
> (using
> > relatively small parameters) then he shouldn't tote it as the next
> mesiah.
>
> You may have twisted my orginal post a bit.
> Let me try it in a different way.
>
> I said, "Phillo's alg is faster than index calculus...What do you
> think?"
>
> So you may answer one of the following:
> a. Yes, it is because __________.
> b. No, it isn't because ___________.
>
> The answer (with the real technical reason) can be as short as 1
> sentence. Now try fill in the blank.
I am not the right person to ask this. I implement crypto and design block
ciphers. This type of number theory isn't my "field" (excuse the pun). So I
would say "convince the pros" which you haven't or "convince me by solving my
simple challenge" which you haven't either.
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Encrypting Predictable Files [completely about AONT, the file is
completely gone]
Date: Thu, 8 Feb 2001 17:34:04 -0800
"Matt Timmermans" <[EMAIL PROTECTED]> wrote in message
news:1vng6.72440$[EMAIL PROTECTED]...
> "Benjamin Goldberg" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > If you're going to introduce AONT into your system, you need almost
> > nothing else. Simply XORing your key with the AONT'd text is enough,
> > even for a fairly short key (provided that key's long enough to avoid
> > being brute forced).
> Hmmm. XORing with the AONT output leaves you open to known plaintext
> attacks against the key, if I know the content of an entire message.
XORing
> with the plaintext, of course, does't prevent the AONT from being
inverted.
> Perhaps if you XORed your key into both? Seems like an interesting
question
> for someone who's actually good at determining the security of such
things.
Actually provided you use a K bit secret for the XOR, and have at least K
unknown bits, assuming the AONT is perfect you achieve something
astoundingly similar to a OTP. The logic is that because we know that if the
secret is not repeated we have a OTP on those bits, because all those bits
are required to have a better than 50% chance of guessing any bit of the
plaintext.
However there are competing factors, the XOR actually turns out to be a very
important example of near-perfection. Because it is currently impossible to
build perfect AONT (OAEP is probably the closest with a work factor that is
very high for recovery but it is not perfect). This imperfection leaves
competing goals, just as imperfection in ciphers leaves us with competing
goals.
Simply stated the conflicting goals that are most important for the
encryption are: encrypting as little as necessary (to avoid supplying enough
ciphertext for any analysis other than brute force), encrypting enough of
the AONTd data that the imperfection does not lead to leakage.
Joe
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: relative key strength private vs public key
Date: Fri, 09 Feb 2001 02:19:55 GMT
In article <[EMAIL PROTECTED]>,
Steve Portly <[EMAIL PROTECTED]> wrote:
> For purposes such as intellectual property protection you might have
the case where
> a key should last for 30 years or more.
I doubt whether you will find a single authority who suggests
selecting keys now that will be good for 30 years. Instead,
pro-active security is recommended.
> Current standards are fine for day to day
> E-commerce of course. For those of you that write your own programs
and generate
> large prime number composites
Huh? What is a "prime number composite"?? Please explain.
> you may have noticed that the spacing between prime
> numbers grows quite large. Prime numbers only occur about one in a
hundred thousand
> numbers at current key sizes.
Where did you get this piece of misinformation? The average
gap between primes for primes near a large integer n is about log n.
For 512 bit primes, this yields an average gap of 512 log 2 ~ 360
> I am wondering if there might be some point in the
> future (30 years down the road) in which prime numbers are not as an
attractive
> alternative for public key systems? Any math theory to prove
disprove this?
1) Alternative to what?
2) How do you propose to do away with needing them?
3) You have not made a mathematical statement. To talk about a
'disproof' is nonsense. One can only prove or disprove mathematical
statements.
4) You have failed to suggest a reason *why* you think they might
become unattractive.
>>Todays public key systems may prove just as easy to break in
> time.
This would require a major breakthrough in mathematics. It will
not occur simply because computers get faster. Such breakthroughs
are impossible to predict. When one says "may", the statement is
somewhat vacuous in absence of supporting evidence.
--
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: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Phillo's alg is faster than index calculus
Date: Fri, 09 Feb 2001 02:56:02 GMT
sisijojo wrote:
> If we have 2^k memory, we can do 2^k precomputations.
> Then we have 2^k special cases. That surely will speed
> up our computation. That's how the other cryptanalysis
> schemes work.
>
> Everyone is arguing that this method is not practical
> for large n. Yeah I know that. But index calculus is not
> practical either. So do you think this scheme can or
> cannot be faster than index calculus?
Of course not. It's time (and space) is obviously
proportional to the order of the generator, times some
polylogarithmic term, with or without the precomputation.
Even Pollard's Rho algorithm leaves it in the dust.
> Another point: I think this method creates a whole new class
> of trivial cases that we should avoid.
Your point is wrong. The current discreet log schemes use
generators of large (and prime) order.
> Just like Mersenne Primes should be avoided.
The intelligent method to avoid Mersenne Primes is to generate
primes randomly.
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Encrypting Predictable Files
Date: Fri, 09 Feb 2001 03:01:07 GMT
Joseph Ashwood wrote:
> Bryan Olson wrote:
> > RC4 is designed to resist known-plaintext attacks, and so far
> > no one has shown it doesn't.
>
> However it also suffers from plaintext substitution, that is
> to say that if the plaintext is known it can be replaced with
> a different more desirable plaintext, this may or may not be
> a problem depending on the situation.
> Because of this I'd suggest using at a minimum an
> AllOrNothingTransform. Realistically that'll be as expensive
> as using a block cipher that doesn't suffer from this problem.
RC4 only addresses privacy, not authentication. For symmetric
authentication use a MAC (_not_ a block cipher or AONT).
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: mjconroy <[EMAIL PROTECTED]>
Subject: Rijndael S-box derivation
Date: Thu, 08 Feb 2001 22:24:57 -0500
This may be a newbie question. Sorry.
I'm trying to gen out the S-box of Rijndael by hand. I understand the
affine transformation, but I'm unclear about the matrix that feeds it.
Does anyone know of a clear walkthrough of this derivation?
The AES proposal states that the S-box is constructed by the composition
of two transformations:
1. First, taking the multiplicative inverse in GF(2^8), with the
representation defined in Section 2.1. '00' is mapped onto itself.
Assuming that '00' is hex, I can calculate for x = 0 and x =1, and get
the expected values in the S-box, but these are basically special
cases. When I try x = 2, I get a result that appears further down in
the S-box than expected. I'm assuming that the multiplicative inverse
in GF(2^8) of 2 is 129, but I am somewhat new to this process, so that
could be my mistake.
Thanks for your time.
Cheers,
Mike
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: crack my enkryption
Date: Thu, 08 Feb 2001 19:16:45 -0800
Thomas Holenstein wrote:
>
[snip]
>
> But my real reason for posting this is: could you, John, do this
> again?
I can do so, if you mean posting a message like the prior one for others
posting in the same vein. :-)
> Furthermore, can I store your (really excellent) posting to
> post it on other questions like that?
Yes, please feel free. And add to it if you wish. In addition to the
sci.crypt FAQ, maybe suggest web sites, books or articles you found
personally valuable in your study of cryptology to the newcomers and the
curious who pop up like that.
Generally, most who post here hold a genuine interest in cryptology - no
matter what or how they post. Let's help them find out more.
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: CipherText patent still pending
Date: Fri, 09 Feb 2001 03:23:40 GMT
Mok-Kong Shen wrote:
> Bryan Olson wrote:
> > Hard to believe you are looking at the same world as am I.
> > There's a huge need, and call, for crypto research. But a new
> > symmetric cipher not known to be secure or insecure just makes
> > a large pile bigger.
>
[...]
> But don't you
> see that at schools the pupils are continuing to write
> compositions (after you have left school)? Should they
> stop writing??
Experts teaching writing say to write every day. I've never
heard an expert cryptologist recommend cipher design as an
exercise.
> It may be noted that there is a parallel
> (monitored) group sci.crypt.research which is supposed to
> be a forum for research stuffs. Since you apparently
> pose a rather high standard on materials you read, I warmly
> recommend you to switch to that group,
There's a myth that sci.crypt is for the less technical
material. Check the charter; you may be in the wrong place.
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: Mod function
Date: Fri, 09 Feb 2001 03:32:08 GMT
Darren New wrote:
> And of course www.uspto.gov is the definitive source of online patents. And
> searchable via a variety of means.
Errr, for US patents, of course.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
Ignorance can be cured. Naivety cures itself.
------------------------------
** 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
******************************
