Cryptography-Digest Digest #910, Volume #13 Fri, 16 Mar 01 02:13:01 EST
Contents:
Re: SSL secured servers and TEMPEST (Paul Rubin)
Re: Computing power in the world ("Douglas A. Gwyn")
Re: Quantum Computing & Key Sizes (Tony L. Svanstrom)
Re: primes for BBS ([EMAIL PROTECTED])
Re: ANSI X9.17 Key Generation and Alternatives ("Spencer")
Re: Secure overwriting (Eric Lee Green)
Re: qrpff-New DVD decryption code (Benjamin Goldberg)
Re: primes for BBS (Benjamin Goldberg)
Re: Encrypt then HMAC or HMAC then Encrypt? (Paul Crowley)
Re: Encrypt then HMAC or HMAC then Encrypt? (Paul Crowley)
Re: Again on key expansion. (Paul Crowley)
Papers and the media (was Re: New unbreakable code from Rabin?) (Paul Crowley)
Re: PGP (Paul Crowley)
Re: Popularity of AES (Paul Crowley)
Re: Noninvertible encryption (Paul Crowley)
Re: Cheap hardware to break RSA? (Paul Crowley)
----------------------------------------------------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: SSL secured servers and TEMPEST
Date: 15 Mar 2001 19:15:17 -0800
[EMAIL PROTECTED] (Mark Currie) writes:
> OK, perhaps I didn't understand you. Many (most?) SSL servers don't
> use security modules, the private key is used in the app server
> itself. Some (many ?) SSL servers use a hardware signature
> accelerator to ease the load on the app server. The hardware
> accelerator has no tamper proofing or shielding and in fact the
> private key may even be sent to the accelerator by the app server.
> Some (few ?) use tamper-proof and shielded security modules.
Yes, it's those last that we're talking about.
> In the security module case, the private key can be generated,
> stored and used only within the security module. The FIPS 104-1
> level 4 spec is the highest commercial security module standard in
> America covering hardware security mechanisms. It only requires
> commercial EMI certification (FCC). Well designed security modules
> are much quieter than that.
The one FIPS 140-1 level 4 module that I know anything about (IBM 4758)
went to serious lengths to avoid leaking any data through EM emissions.
> Where your coming from is - can you completely hide emmissions ? No
> you can't, but for an outside attacker to exploit the emmissions
> that you are talking about you would probably need to have the
> resources that only government agencies may have. Commercial
> security can only hope to follow government security due to
> available resources and budget.
I'd tend to think any emissions monitoring the government can do,
anyone else can also do.
> Commercial security vendors can only charge so much for their
> products.
But I know from experience that they can charge an awful lot ;-)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Computing power in the world
Date: Fri, 16 Mar 2001 03:20:04 GMT
Ichinin wrote:
> MIPS Years is a well known measurement of a machine running at 1 Mips
> (i.e. ~386sx25) for a lenght of (you guessed it) a year.
But a measure of "power" would need to be converted back to a *rate*,
such as MIPS. On very simplistic assumptions, therefore, the total
computing power in the world would be the sum of MIPS of all machines.
------------------------------
Subject: Re: Quantum Computing & Key Sizes
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Date: Fri, 16 Mar 2001 03:36:39 GMT
Mike Rosing <[EMAIL PROTECTED]> wrote:
> "Tony L. Svanstrom" wrote:
> >
> > Reading the answer... hmmm... binary code that you get in dead / not
> > dead cats? ;-)
>
> Exactly. A lot of dead cats involved in quantum mechanics :-)
Only if you "look" at them. =)
/Tony
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: primes for BBS
Date: 15 Mar 2001 20:00:11 -0800
[EMAIL PROTECTED] (Terry Ritter) writes:
> On 15 Mar 2001 12:16:04 -0800, in <[EMAIL PROTECTED]>,
> in sci.crypt [EMAIL PROTECTED] wrote:
> >All true until the last part. You don't have to check that x doesn't
> >produce a short cycle. If you ever find an x that produces a short
> >cycle, you have cracked RSA and factored a 1024 bit modulus! If you
> >believe that RSA with a 1024 bit modulus is secure, you don't have to
> >check for short cycles. If short cycles can be found, RSA is insecure.
>
> Note the logic error above: If the sender does choose a short cycle,
> N *can* be factored. That is not an ability to factor N at will; that
> is a weakness deliberately allowed to exist. It is argued that such a
> thing hardly ever happens.
No, you can use this to factor N at will. Give me an N, I will choose
an x and unluckily find a short cycle. (If you think it can happen
with BBS you must grant me the ability to do it with your N.) I will
factor your N.
> A similar problem occurs in any system which has weak keys: typically,
> the implementor gets to decide whether checking for weak keys is
> worthwhile. The difference here is that the result is supposed to be
> "mathematically proven," so that users probably think it is
> indisputably secure. The proof, however, works asymptotically, over a
> huge universe of possible x0's. So if the sender "lucks out" and the
> system chooses a short-cycle x0, the resulting cipher is unarguably
> insecure anyway. That is not something the opponents must do to
> factor N; that is something the sender does for them.
The difference is that the analog of the "weak key" is a seed which
is chosen INDEPENTLY OF N! It would be as if your cipher had a "weak
key" which would break it regardless of what key you actually used.
I'd call such a cipher "broken". If you think RSA has this property
you think RSA is busted.
------------------------------
From: "Spencer" <[EMAIL PROTECTED]>
Subject: Re: ANSI X9.17 Key Generation and Alternatives
Date: Thu, 15 Mar 2001 20:34:31 -0900
Hey, I'm new to programming myself.... and cryptosystems in general... I'm
only a 10th grader in Algebra II, but I'm tryin to learn the math involved
on my own.... so if what I have to say is totally irrelivant, please forgive
me :)
Err... I don't have much to say, but this website does:
http://catalog.com/sft/encrypt.html
"Bjorn Forsberg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I have a blob of data to encrypt and persist to a file system for long
> term storage.
>
> I have a master key (fixed). I generate the actual encryption key for
> the data from the master and a piece of data stored with the blob on the
> file system. This piece of data is HMAC'd and included in the ciphertext
> so it can be relied upon.
>
> I use an algorithm like ANSI X9.17 to generate the encryption key from
> the master. However, this process involves two encryption operations
> itself and is hence very expensive in an environment were the number of
> encrypts/decrypts may be high.
>
> Given that, are there other published methods of generating a key from a
> master that are secure yet less expensive? I mean, I could simply xor
> the master key with the piece of data from the blob to get my encryption
> key and save those two extra encryption operations. But am I exposing
> myself to some sort of attack?
>
> Hardware is not an option at this time.
>
> Thank you.
>
> Bjorn Forsberg
> Roaring 30s
------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Subject: Re: Secure overwriting
Reply-To: [EMAIL PROTECTED]
Date: 15 Mar 2001 23:52:23 -0600
On Thu, 15 Mar 2001 03:52:21 +0000, David Hopwood <[EMAIL PROTECTED]> wrote:
>Eric Lee Green wrote:
>> There's another issue regarding overwriting blocks: Whether blocks are
>> re-used or not depends upon the filesystem. The Windows filesystem
>> will reuse the same blocks for the file. The traditional Unix and Linux
>> filesystems will reuse the same blocks for the file. However, the Reiser
>> filesystem, and probably NTFS (since NTFS also claims to be a transactional
>> filesystem), will *NOT* reuse the same blocks for the file.
>
>NTFS is not a fully transactional filesystem; it only guarantees
>transactional behaviour for file metadata. I think the rationale was
That was true for NT 4, at least. I do not know what the case is with
Windows 2000.
>> But even that may not be enough. To whit:
>[snip description of system with RAID-5 controller and 1 MByte cache]
>> Now, there does exist a BIOS
>> call on this beast to force it to flush its internal buffer. But you
>> must first know that a) this beast is connected, and b) how to call
>> that BIOS call. Right now, the Linux driver for this card, when its
>> "shutdown" routine is called (when the system is shutting down), knows
>> how to call this BIOS call (so that all data gets written to the disk
>> at shutdown), but a normal "fsync()" call doesn't touch it, because
>> the buffer cache knows nothing about the underlying hardware (that's
>> the driver's job).
>
>IMHO, fsync should be asking the buffer cache to ask the driver to
>force a hardware flush. That it doesn't, I would consider a bug.
I actually would consider it a bug too. But the implementers of the
buffer cache for the Linux 2.x kernel were not thinking about RAID
cards with large internal buffers when they designed that buffer
cache, and thus did not add such functionality. I agree that it would
be a Very Good Idea, and would definitely solve some problems with
filesystem consistency (the filesystem tells the buffer cache to fsync
when necessary in order to preserve filesystem consistency, but since
the data isn't actually making it to disk until some time later, it is
much easier to corrupt your filesystem with the write-buffering turned
on).
>However, there is not much that an application-level overwriting
>program can do to work around this, or similar situations. That is one
>reason why secure overwriting should be supported in the OS, rather
>than at the application level. Even if it is possible for an application
I agree. There are some interesting issues here with respect to the
buffer cache and maintaining cache consistency, and some definite
performance issues.
>The underlying problem, though, is that there are at least 3, and possibly
>up to about 8 layers (in the case of a remote RAID drive or similar)
>through which a flush command must pass in order to cause a write to
>some physical media. If *any* of those layers do not pass on the command,
>the write will not actually happen - and since flush commands have no
>easily observable effect, there is a temptation to simply ignore them at
>each layer. The implementors of some layers may not even see this as a
>bug, although it clearly is.
Sigh.
>The OS should support erasing a file, and/or marking a file as
>'sensitive' as a system call, which should tell the driver(s) to
>do the right thing at the IDE/SCSI/whatever level. Also, the virtual
>memory subsystem should be designed to allow secure overwrites of
>sensitive memory blocks. That's the only way to reliably ensure that
>data can be erased.
Ooof! I forgot about the swap file! Ouch. That's another ball of wax.
Whoosh.
>An encrypted filesystem does not in itself solve the problem; one of the
>purposes of erasing data is to prevent it from being recovered even when
>everything else is compromised. That can happen in any number of ways
>that don't involve direct cryptanalysis: dictionary attacks against
>passwords, exploiting bugs in the OS or application software, rubber
>hose methods, etc. In particular, relying on data being encrypted, rather
>than erasing it, is not sufficient to achieve forward secrecy, which I
>believe is an important goal in practice.
A reasonable approach. One problem with data erasure, however, is the
amount of time that it takes. One possibility is a combination of the
two -- make it so that there are certain key data areas that, if
erased or written with a particular pattern, render the scramdisk
unrecoverable. The question is how to deal with the situation if you
are in a country that has a military junta in control that has NSA and
CIA support for electronic snooping. These people can intercept your
every keystroke and mouse click. They swoop in when they realize that
you have started to erase your data. How do you prevent them from
restoring those lost sectors from the backup tape that they make of
your hard drive every morning after you go to work?
I think the answer has to be that the support has to be *AT THE ACTUAL
STORAGE DEVICE LEVEL*. The storage device must have support for storing
sectors in an encrypted manner, with the keys auto-generated by the
storage device and stored in an externally inaccessible manner. Then there
would be a command that you send to the storage device that tells it,
"Erase your keys in a secure manner." Game over. Within seconds the
data is still on the hard drive, but is useless, because without the keys
it cannot be decrypted. And the keys were never available for snooping,
because they never left the hard drive. Unless somehow the generals
managed to insert new firmware into your hard drive, but if that's the
case, then we're all screwed anyhow (sigh).
Of course, the problem with going down to that very deep level is that
the algorithms and software used become unavailable to analysis. That is
my problem with certain other products which have been discussed or mentioned.
Without access to source code, it is impossible for a security consultant
to detirmine whether it is, in fact, performing the desired function or
not. If a hard drive manufacturer decided to whimp out and not implement
a true "secure" erase, there's no way (as a random guy not under
contract to them) that I can tell whether this is the case or not.
--
Eric Lee Green [EMAIL PROTECTED] http://www.badtux.org
AVOID EVIDENCE ELIMINATOR -- for details, see
http://badtux.org/eric/editorial/scumbags.html
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: qrpff-New DVD decryption code
Date: Fri, 16 Mar 2001 06:28:07 GMT
Joe H. Acker wrote:
>
> Matthias Bruestle <[EMAIL PROTECTED]> wrote:
>
> > Mahlzeit
> >
> >
> > Douglas A. Gwyn ([EMAIL PROTECTED]) wrote:
> > > Matthias Bruestle wrote:
> > > > It is theft if the legal system thinks it is theft.
> >
> > > Theft is a moral/ethical concept, logically prior to legality.
> >
> > How do you define moral or ethics? If it is what most people do,
> > than copying of music is probably not theft.
>
> My God! It is *of course NOT* what most people do! As a German like
> you, I hate to bring this example, but do you believe that in the 3rd
> Reich in Nazi German what most people did was moral or ethical
> behavior? Certainly not! What the majority does or thinks can never be
> taken as an argument for or against moral judgements.
The problem with bringing up Nazis, is that *they* didn't believe that
what they did was unethical or immoral. In fact, if you were to accept
one single premise -- that anyone who isn't a male aryan isn't a person
-- you would consider everything they did to be perfectly reasonable.
Further, and possibly more importantly wrt your argument, the way they
acted towards those who they *did* consider persons, was as moral and as
ethical as you or I would act towards each other. The only thing that
made them evil was their perception and treatment of non-aryans as
non-persons.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: primes for BBS
Date: Fri, 16 Mar 2001 06:53:19 GMT
[EMAIL PROTECTED] wrote:
>
> Benjamin Goldberg <[EMAIL PROTECTED]> writes about BBS:
> >
> > Note that p, q, don't just have to be primes, they have to be
> > *special* primes (specifically "Blum integers" which are prime, aka
> > "Blum primes"), and when picking a starting value for x, you have to
> > make sure that it does not produce a short cycle.
>
> All true until the last part. You don't have to check that x doesn't
> produce a short cycle. If you ever find an x that produces a short
> cycle, you have cracked RSA and factored a 1024 bit modulus! If you
> believe that RSA with a 1024 bit modulus is secure, you don't have to
> check for short cycles. If short cycles can be found, RSA is
> insecure.
Not quite. If we can *intentionally* find a short cycle, then RSA is
insecure. The chances of us finding a short cycle by accident are about
the same as us guessing, at random, one of the factors of RSA. This
doesn't mean that it won't, or can't, happen, just that it's unlikely.
If the sender discovers a short cycle, then he has lucked on to the
factors of n. This is, as I said, an unlikely occurance, so we don't
have to worry that sender who has chanced upon a short cycle recording
it and breaking our key, but if they *use* that short cycle, rather than
discard it, and an enemy notices this, then the enemy learns the BBS
private key.
Now why do we worry that an enemy might observe someone else using a
short cycle, when they can't himself find one? Because the legitimate
BBS users are doing the majority of the computation, while the enemy has
the much simpler, computationally cheaper, task of looking for cycles.
Suppose you are using BBS as your PKE system, and hundreds of people
have your public key, and each sends you hundreds of messages daily.
Your enemy leaves a program on your router, and watches the messages
coming towards you. He doesn't need to perform the BBS crypto stuff,
which is quite expensive... he just has to check for a ciphertext which
looks like it was vernam enciphered with a short key.
As soon as the enemy program discovers a vernam-like ciphertext, it
sends it to the enemy's normal computer, where it's combined with the
public key to learn p and q.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
Subject: Re: Encrypt then HMAC or HMAC then Encrypt?
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Fri, 16 Mar 2001 06:32:45 GMT
[EMAIL PROTECTED] (David Wagner) writes:
> David A Molnar wrote:
> >They are worried about chosen-ciphertext attacks. Which become much harder
> >if a MAC is applied to the ciphertext.
>
> Don't chosen-ciphertext attacks also become much harder if a MAC
> is applied to the plaintext and if the decryption operation is
> bijective?
I'm not used to thinking of decryption as bijective. Usually there
are many possible ciphertexts that can decrypt to the same plaintext,
due to the use of an IV.
I've wondered about this question myself - it sounds like "MAC the
ciphertext" is the Right Thing.
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
Temporary address (due to email problems): [EMAIL PROTECTED]
------------------------------
Subject: Re: Encrypt then HMAC or HMAC then Encrypt?
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Fri, 16 Mar 2001 06:32:45 GMT
[EMAIL PROTECTED] (D. J. Bernstein) writes:
> Note that HMAC is rather slow. See http://cr.yp.to/hash127.html for a
> faster authenticator.
Interesting: how does this compare to UMAC?
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
Temporary address (due to email problems): [EMAIL PROTECTED]
------------------------------
Subject: Re: Again on key expansion.
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Fri, 16 Mar 2001 06:32:44 GMT
"Joseph Ashwood" <[EMAIL PROTECTED]> writes:
> > Doesn't a better method exist?
>
> A better method can't exist. You can only measure this by the
> time/cost/work, where work = time*cost. To double the work, you must double
> the time, or the cost. You simply cannot get around that.
What he said: the efficacy of your stretching is effectively measured
in milliseconds, and two shortcut-free methods that take the same
number of milliseconds are equally effective. The most you can do is
try and use a method that isn't particularly easy to optimise on
platforms other than the one you expect to use; for example, SALEK
recommends taking steps to make stretching a little memory-hungry, to
make life more expensive for anyone building passphrase-guessing
hardware.
I would certainly recommend strongly against a complex method like
the elliptic curve one you described, over a relatively simple one
with provable properties like that described in SALEK.
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
Temporary address (due to email problems): [EMAIL PROTECTED]
------------------------------
Subject: Papers and the media (was Re: New unbreakable code from Rabin?)
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Fri, 16 Mar 2001 06:32:44 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
> Tim Tyler wrote:
> > I seem to be justified in describing this claim as "apparently
> > ridiculous". It doesn't matter /what/ the details of the system
> > proposed are, there's no way such a description can be justified.
> > Provably unbreakable codes are simply not known to exist.
>
> Perhaps you should read the paper before you criticize the work.
I'd like to: where is it?
It would be great if we could encourage the idea that you should have
a paper describing your result on your webpage for download *before*
the press start making a hullabaloo about it, so the crypto community
could take part in the resulting discussion and spread some light. In
every recent instance I can think of where crypto has been in the
press (eg Twinkle), this would have helped. Or did help, in the case
of Cramer-Shoup.
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
Temporary address (due to email problems): [EMAIL PROTECTED]
------------------------------
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: PGP
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Fri, 16 Mar 2001 06:32:44 GMT
David Schwartz <[EMAIL PROTECTED]> writes:
> Print out the encrypted file and put it up on your wall. Pay to have it
> published in the classified section of the New York Times. Put copies of
> it on every floppy and hard disk you have. One good think about having
> an encryption scheme you trust is that you don't have to worry about
> trading off security against loss for secrecy against interception.
This is true only if the file is encrypted with a high-entropy
secret. If it's encrypted with a passphrase, these measures may
increase vulnerability.
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
Temporary address (due to email problems): [EMAIL PROTECTED]
------------------------------
Subject: Re: Popularity of AES
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Fri, 16 Mar 2001 06:32:45 GMT
Thomas Boschloo <[EMAIL PROTECTED]> writes:
> Will the final AES e.g. have extra rounds on it like they did with
> Square
No. The NIST team stated their reasons for not extending the rounds
in the paper explaining their choice of AES, and the draft FIPS has
the same number of rounds as the Rijndael specification.
It's pretty much certain that the final AES cipher will be the same
one as the cipher in the draft FIPS, which is the same cipher as that
specified in the original Rijndael paper. All that will change is the
precise description and associated text.
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
Temporary address (due to email problems): [EMAIL PROTECTED]
------------------------------
Crossposted-To: sci.math
Subject: Re: Noninvertible encryption
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Fri, 16 Mar 2001 06:32:44 GMT
David Schwartz <[EMAIL PROTECTED]> writes:
> In this case, it actually weakens things. Uncompressed data is much
> more likely to contain exploitable patterns than compressed data. In
> fact, compressibility is pretty much a measure of how patterned
> something is.
But there's no real security issue since our ciphers are designed to
resist known-plaintext attack.
To put this in perspective: I recently found a very slight bias in the
output of a cryptographic pseudo-random number generator (CPRNG). You
have to observe 64 GIGABYTES of output from the RNG before the bias is
detectible, and we've found no way to use it to find anything out
about the cryptographic key (or indeed any use for it at all beyond
detecting that this CPRNG is being used); yet to the community, this
is a devastating result that puts the CPRNG beyond use until the
problem is fixed. That's the sort of standard against which our
ciphers are measured.
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
Temporary address (due to email problems): [EMAIL PROTECTED]
------------------------------
Subject: Re: Cheap hardware to break RSA?
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Fri, 16 Mar 2001 06:32:46 GMT
"Andor Bariska" <[EMAIL PROTECTED]> writes:
> Sven Gohlke <[EMAIL PROTECTED]> schrieb in im Newsbeitrag:
> [EMAIL PROTECTED]
> ...
> >Why don�t You use analog computer to do this job?
>
> Do a search on TWINKLE.
The analog step in TWINKLE is one of determining when the Hamming
weight of a large vector of bits falls over a certain threshold. It's
efficient to do a generous analogue test first, then test again with a
digital test if the analogue test suggests a hit.
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
Temporary address (due to email problems): [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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
