Cryptography-Digest Digest #197, Volume #12 Tue, 11 Jul 00 00:13:00 EDT
Contents:
Re: Steganographic encryption system ("Joseph Ashwood")
Re: SCRAMdisk or PGPdisk? (Early Minko)
Re: Random Numbers (Terry Ritter)
Re: Proposal of some processor instructions for cryptographical applications
(Terry Ritter)
Re: One plaintext, multiple keys (Terry Ritter)
Re: Proposal of some processor instructions for cryptographical applications (Jayant
Shukla)
Re: Steganographic encryption system (jungle)
Re: Random Numbers (Nicol So)
Re: A thought on OTPs (Nicol So)
Re: Use of EPR "paradox" in cryptography (Roger Schlafly)
Re: One plaintext, multiple keys (S. T. L.)
Re: Steganographic encryption system ("Chris Severn")
Re: A new cipher........ (wtshaw)
Re: Proposal of some processor instructions for cryptographical (Boris Kazak)
Re: Another AONT (less expensive, this time) (Benjamin Goldberg)
Who was that girl? (An Metet)
Re: One plaintext, multiple keys (Joaquim Southby)
Re: Proposal of some processor instructions for cryptographical applications
("Stephen Fuld")
Re: Compression & Encryption in FISHYLAND ("Douglas A. Gwyn")
Re: Proposal of some processor instructions for cryptographical ("Douglas A. Gwyn")
Re: Proposal of some processor instructions for cryptographical ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Steganographic encryption system
Date: Mon, 10 Jul 2000 16:52:00 -0700
Crossposted-To: comp.os.linux.development.apps
> If I have an encrypted file, and a key which purports to be a valid key
> for my system, then surely anyone who knows the algorithm I'm using will
> be able to easily find out whether the key is valid, by getting the data?
> (Or are you saying that invalid keys should produce random-looking
> data, but no indication that the key is bad?)
If you use an All-or-Nothing-Tranform on the files, an attacker MUST go
through attempting to get information from the entire file, in order to
determine if the file contains information from that key (otherwise the data
is difficult to distinguish from random), it's just another way to slow down
the attacker. This also makes it more difficult for your application to leak
information, but will make it more difficult to edit files, you'll be forced
to remove then create them.
Joe
------------------------------
From: [EMAIL PROTECTED] (Early Minko)
Subject: Re: SCRAMdisk or PGPdisk?
Date: Tue, 11 Jul 2000 00:28:34 GMT
[EMAIL PROTECTED] (Simon Hogg) wrote:
>Forgive me, but I can't find any information comparing these two (SCRAMdisk or
>PGPdisk), so what's the consensus?
See Sarah Dean's page:
http://www.fortunecity.com/skyscraper/true/882/index.htm
--
"Early Minko" is actually 5680 714392 <[EMAIL PROTECTED]>.
01234 56789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Random Numbers
Date: Tue, 11 Jul 2000 00:42:55 GMT
On Sun, 09 Jul 2000 10:33:37 -0700, in
<[EMAIL PROTECTED]>, in sci.crypt Roger Schlafly
<[EMAIL PROTECTED]> wrote:
>David Hyde wrote:
>> Does anyone know how to convert a random bit stream into random 16-bit
>> numbers with uniform distribution?
>
>I assume that the original random bit stream is not uniform,
>or the question is trivial.
>
>The standard procedure is to run the numbers thru a crypto
>hash function like MD5 or SHA-1.
A CRC should be just fine and faster.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
applications
Date: Tue, 11 Jul 2000 00:43:14 GMT
On Sun, 09 Jul 2000 23:30:14 +0200, in
<[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>Iain McClatchie wrote:
>
>> Why bother supporting cryptography in the CPU? I agree that general-
>> purpose substitution and diffusion operations might make software
>> encryption faster. But why do crytography in software, especially
>> if you have to hack the hardware ISA to do it?
>
>One may want to use algorithms that don't have specific hardware
>implementations. (Not everyone agrees which is THE best algorithm.)
>One saves the cost of the hardware. A very personal reason is that I
>have more confidence in software code that I can examine than in a
>piece of hardware that I can't examine.
Another answer might be: Because it is difficult to impossible for
users to certify that hardware cryptography does nothing beyond what
we think it should.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: One plaintext, multiple keys
Date: Tue, 11 Jul 2000 00:46:26 GMT
On 10 Jul 2000 22:09:01 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (S. T. L.) wrote:
>[...]
>Plaintexts are not keys. Nothing can be leaked by an
>OTP used properly. Other algorithms can leak if you repeatedly send the same
>plaintext enciphered with different keys.
If two different pads are used to send the same data -- a very
reasonable situation when a central command distributes information to
its controlled entities -- then exposing the plaintext also exposes
each other pad.
Now, if the other ciphertexts have been interfered with and not
delivered, it becomes possible to invent fraudulent messages, then
encipher each under each exposed pad, and substitute them for the
originals. Each receiving entity will accept those messages, because
an OTP "cannot leak."
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Jayant Shukla)
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical applications
Date: 11 Jul 2000 01:11:54 GMT
[EMAIL PROTECTED] (David A. Wagner) writes:
>Iain McClatchie <[EMAIL PROTECTED]> wrote [excerpts only]:
>> Why bother supporting cryptography in the CPU?
>>
>> - Hardware implementations of the speed-critical cyphers are _tiny_.
>>
The AES candidates are not too _tiny_. In fact, the fully pipelined
version of the AES candidates could not be fitted on Xilinx XC4000
FPGA. The NSA paper shows that even the most efficient implementation
of these algorithms in hardware takes up > 23 mm^2 of silicon.
Don't even ask about the fully pipelined versions ( ~1000 mm^2).
>> - Popularly-used cryptographic algorithms change very slowly.
>>
>> - Connection speeds are increasing. Software encryption can keep
>> up with a 56 Kb/s modem just fine, but a 10 Mb/s cable modem is
>> a problem,
>>
>> - Popular cryptographic algorithms now appear to be exportable.
>Those are good points. Still, there's a definite cost, and I wonder
>how compelling a need there is for hardware crypto.
Very.
>Until the AES is chosen, there's no obvious single candidate for hardware
>implementation. Each crypto protocol has a different favorite cipher
>(SSL -> RC4; IPSEC -> DES; SSH -> IDEA). That will likely change some
>years after after the AES is chosen, but even so, I'm not convinced
>there's a compelling need for hardware implementation. No matter which
>AES candidate is chosen, it is likely to run at about 20 cycles/byte,
>so encrypting at even 10 Mb/s should take only something like 4% of the
>CPU speed, if I'm not mistaken. Is that a significant enough burden to
>justify hardware implementation?
apart from 20 cycles/byte you also have to consider the key
setup time (1,500-10,000 cycles for the AES candidates).
If you have a network gateway, you might have several
security associations (SA) and for each SA you have
the key setup problem. Suddenly for a 10Base-T network,
your effective encryption load is greater than 10Mb/s.
The problem only gets worse when you transmit many small
packets.
To that add the key exchange overhead and encryption in
hardware starts to look very attractive.
Now consider the same problem in a 100Base-T or 1000Base-T Ethernet
network. Most AES candidates can encrypt/decrypt at 100Mb/s, but
they chew up 100% of the CPU of a 600MHz PIII. Would you employ a
$500 CPU just for the encryption task? (assuming it can do it, for
100Base-T... yes, but for 1000base-T...no way!)
There is a big need for hardware to accelerate encryption. Network
gateways and routers are where encryption is used more often than
in the desktops and they have to deal with much higher bandwidth.
This is why almost all VPN solution rely on hardware to improve
performance.
>I'm truly interested in your thoughts.
I hope it was interesting.
regards,
Jayant
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Mon, 10 Jul 2000 22:03:51 -0400
what is the reason to decrypt into many different plaintext ?
phil hunt wrote:
>
> I am thinking of developing a steganographic encryption system that
> will enable a particular cyphertext to be decrypted into two or more
> different plaintexts, depending on which key is used.
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Random Numbers
Date: Mon, 10 Jul 2000 10:24:09 -0400
Reply-To: see.signature
Herman Rubin wrote:
>
> Independence is MUCH harder to approximate than lack of
> bias. It is also much harder to detect.
Both statements above relate to the existence of secure encryption
algorithms. Since I tend to believe in their existence, I tend to agree
with the latter statement (but I also believe that independence cannot
be *too* hard to approximate).
Strictly speaking, what I'm going to say depends on how the notion of
security is formalized, but to keep the discussion informal, I'll
handwave. So bear with me.
If secure encryption is indeed possible, one can construct a secure
pseudorandom number generator out of a secure cipher. What a secure PRNG
does is essentially to "stretch" a short random bit string (the seed)
into a longer one in such a way that the resulting string can pass for a
truly random bit string of the same length. That is, no efficient
algorithm have more than a negligible chance of success in telling apart
output of the PRNG from the "real thing".
If secure PRNGs exist, they can fool all efficient algorithms, including
statistical tests. So... independence cannot be too hard to approximate
(when you have the right tools). On the other hand, independence should
be hard to detect, since you can't tell how much randomness there really
is in an apparently random string.
So... in order to do it right, one really needs to have a good model of
how redundancy in the output of a random source manifests.
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: A thought on OTPs
Date: Mon, 10 Jul 2000 10:33:45 -0400
Reply-To: see.signature
Mok-Kong Shen wrote:
>
> Let's have the hypothesis of independce of two random variables.
> You test for their correlation with the chi-square test and find that
> the correlation is extremely small. How could you claim that the
> given hypothesis of independence is not rejected at certain given
> confidence level (since one knows that two dependent variables
> MAY even have zero correlation)? If you in fact want to test
> independence, you have to use the definition of independence.
> That definition is stated in textbooks. However, there has, as far
> as I am aware, yet been no practical test developed by the
> mathematicians for that, at least for the bit sequences we are
> interested in.
See my message in the thread "Random Numbers", which discusses why
independence is hard to test for in the general case. For sources that
don't exhibit complicated forms of redundancy, efficient test for
independence may be possible. For sources that contains a cryptographic
filter, efficient test may not be possible.
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Crossposted-To: sci.physics
Subject: Re: Use of EPR "paradox" in cryptography
Date: Mon, 10 Jul 2000 19:36:58 -0700
Bill Unruh wrote:
> ... They can now do a running hash of the bits, (
> eg, each 128 bits of key is run through say MD5 to give 128 bits of new
> key which depends on all of the 128 bits-- since the probability is
> negligible that E listened in on 128 bits and was not detected (.75^128
> =10^-16), this gives a key which Eve does not know any bits of.
>
> Ie, the security is probablistic.
Yes, and depends on the security of conventional constructions
like MD5 as well. Not absolute security.
------------------------------
From: [EMAIL PROTECTED] (S. T. L.)
Subject: Re: One plaintext, multiple keys
Date: 11 Jul 2000 02:38:03 GMT
<<If two different pads are used to send the same data -- a very
reasonable situation when a central command distributes information to
its controlled entities -- then exposing the plaintext>>
That would be improper use of an OTP, eh? You expose the plaintext to anyone
else than the intended, trusted recipients, and bad shit happens. Fact of
life.
<<What do you mean "Other algorithms can leak if you repeatedly send the same
plaintext enciphered with different keys." ? All others or just some others?>>
Bad ones or ones used improperly. That was implied. Rather, explicitly stated
because I used the word "can" and not "will". I ain't some quack who'll claim
that DES or the eventual AES winner is breakable. Good ones used properly
shouldn't leak any information. Someone gave an example of one that leaks: RSA
with e=3, no padding. RSA used properly won't, of course.
-*---*-------
S.T.L. My Quotes Page * http://quote.cjb.net * leads to my NEW site.
Now **108** reviews of my 169 science books. Other pages up:
Review of the _Foundation_ series, Jet Fighter Paper Airplane page,
LASTLY Shrine, Files for Download!
------------------------------
From: "Chris Severn" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Tue, 11 Jul 2000 10:48:55 +0800
I'd assume it's so that when the FBI comes knocking at your door demanding
you give them the keys to your encrypted data, that you can do just that.
You just give them the key that decrypts it to some non-sensitive
information - not the good stuff.
Sounds fair to me.
"jungle" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> what is the reason to decrypt into many different plaintext ?
>
> phil hunt wrote:
> >
> > I am thinking of developing a steganographic encryption system that
> > will enable a particular cyphertext to be decrypted into two or more
> > different plaintexts, depending on which key is used.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: A new cipher........
Date: Mon, 10 Jul 2000 19:57:15 -0600
In article <[EMAIL PROTECTED]>, Runu Knips <[EMAIL PROTECTED]> wrote:
> If cryptography would be simple, why does the NSA have more
> mathematicans (~40,000) than any other organization arround the
> world ?
The weakeness of the approach to problems through theory is that you still
have to hire someone else to change a light bulb
--
Ralph Nader must not be a politician, he makes sense. Those that
hype confusion about understandable issues are the anarchists.
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Date: Tue, 11 Jul 2000 02:53:23 GMT
Mok-Kong Shen wrote:
> It seems to be the majority opinion that the IP and inverse IP of
> DES are entirely useless. Does anyone know any probable
> design rationale for that?
>
> M. K. Shen
======================
This made the design of PCboards and specialized chips for DES
far more simple, many of the wire crossovers were untangled.
Best wishes BNK
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Another AONT (less expensive, this time)
Date: Tue, 11 Jul 2000 02:42:56 GMT
Mark Wooding wrote:
>
> John Myre <[EMAIL PROTECTED]> wrote:
> > Mark Wooding wrote:
> >
> > > Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> > >
> > > > b = a XOR SHA1( x )
> > > > y = ARC4( b, x )
> > > > c = b XOR SHA1( y )
> > > > transformed-message = c || y
[snip]
> Indeed, we can see that no deterministic transform can
> be as strong as a randomized one, even in a weaker scenario than the
> non- adaptive case given: given two messages x and y and partial data
> of their transforms, the adversary can compute the full transform of
> each of x and y and compare against the partial transforms given.
> Compare this against the definition in which the adversary is
> permitted to /choose/ the two messages to be transformed.
This confuses me. I'll assume when you say x and y, you aren't refering
to the variables described in the transform, but rather two distinct
(and incedentally complete) messages. And you've got part of a
transformed message (i think; you're not exactly clear). What is this
supposed to get you?
------------------------------
Date: Mon, 10 Jul 2000 23:44:58 -0400
From: An Metet <[EMAIL PROTECTED]>
Subject: Who was that girl?
Please accept my apologies for this tyro question. I scanned the FAQ and
didn't see any reference to this.
About a year ago there was a news item in the popular press that a young
girl (age 13-16) had created a rather sophisticated new cipher (I hope I
have that right). I've not seen anything on the subject since then, and I
would very much like to follow up on it.
If someone could direct me to a good URL that discusses this, I would be
most appreciative. I recall reading the list of research topics undertaken
by the young people that won (whatever prize it was), and it too was most
impressive. A link to those topics would be very helpful too.
Probably this is old news to you regulars in here, but I'm still learning.
Thanks in advance for any guidance anyone can give me.
------------------------------
From: Joaquim Southby <[EMAIL PROTECTED]>
Subject: Re: One plaintext, multiple keys
Date: 11 Jul 2000 03:57:23 GMT
In article <[EMAIL PROTECTED]> Terry Ritter, [EMAIL PROTECTED]
writes:
>If two different pads are used to send the same data -- a very
>reasonable situation when a central command distributes information to
>its controlled entities -- then exposing the plaintext also exposes
>each other pad.
>
I don't see the damage beyond the exposure of the plaintext here. If you
recover the keystream used for that plaintext (which you already have),
all you've done is recovered a stream of random numbers that I will not
use again, that being the idea behind OTP's, right? Since that portion
of both pads will not be used again, where is the damage?
------------------------------
From: "Stephen Fuld" <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical applications
Date: Tue, 11 Jul 2000 04:00:49 GMT
"Terje Mathisen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Stephen Fuld wrote:
> >
> > "Terje Mathisen" <[EMAIL PROTECTED]> wrote in message
> > > Since I (with 3 others) wrote the asm code for one of the original AES
> > > submissions,
> >
> > Terje, I continue to be amazed with the things you have done. And you
> > presumably find time to do the stuff that Hydro pays you for!
>
> As others have remarked in email to me, the secret is to not allow your
> work to impede upon your hobbies.
>
> Sometimes the stuff I learn doing what I love actually comes in handy in
> my daytime job as well. :-)
>
> > > The one thing that's missing from the AES code is bignum arithmetic,
for
> > > setup/authentication, but this is being adressed anyway.
> >
> > Well, I am sure you know that AES, being for a DES replacement was for a
> > private key system where bignum isn't needed. This is where the big use
of
> > cycles is as the public key stuff (needing bignums) is typically used
only
> > for session key exchange, etc. with the bulk of the data using private
key.
> > but you knew that :-).
>
> I hope we all know that, but session setup is still important enough
> that the server end, at least today, needs dedicated hw assist. The
> problem is "simply" to make cpu cycles cheaper at a faster rate than the
> WAN guys are increasing the bandwidth of their fibers, and as we
> discussed a few days ago re. dense wavelength division multiplexing,
> this is a tough task. :-)
>
> It does look like IA64, if not Merced, could be capable of doing this,
> since it becomes feasible to keep even 2048-bit keys inside a range of
> cpu registers.
OK, but this brings up one of my questions about IA64. It appears that
there is no carry flag and that the add instructions can't set a predicate
bit if there is a carry (similarly for subtract / borrow). Wouldn't that
help bignum addition and subtraction. I know you can get around it, but it
seems a curious omission.
--
- Stephen Fuld
>
> This is close to (or maybe over) the limit though, since a bignum-style
> mul really needs to work with carry-save format numbers, thereby
> requiring twice as many regs: 64 instead of 32 for a 2048-bit value.
>
> Terje
>
> --
> - <[EMAIL PROTECTED]>
> Using self-discipline, see http://www.eiffel.com/discipline
> "almost all programming can be viewed as an exercise in caching"
>
>
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Compression & Encryption in FISHYLAND
Date: Tue, 11 Jul 2000 00:01:23 -0400
John Savard wrote:
> The traditional block cipher chaining modes do nothing to increase
> the fundamental security of the underlying block cipher;
Not for a single block, how could they?
> nor do they protect against a true known-plaintext attack, ...
They protect against *other* attacks.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Date: Tue, 11 Jul 2000 00:05:05 -0400
Konrad Schwarz wrote:
> Personally, I disapprove of this, because bit addressing requires
> atomic read/modify/write, which I expect will slow the memory
> subsystem down (esp. for multi-processors).
Why do you think that? Octet addressing is almost universal despite
the actual memory bus being 16, 32, 64, or more bits. The technology
is known.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Date: Tue, 11 Jul 2000 00:07:21 -0400
Konrad Schwarz wrote:
> From an abstract point of view, possibly. From a practical
> point of view, I beleive not: the investment in byte addressable
> hardware is just too large and the payoff of bit-addressing too small.
Spoken like somebody who does not program communication protocols,
error-correcting codes, etc.
There is no fundamental obstacle. The main issue is that bit
addresses require 3 more bits than octet addresses. Whoopdeedo.
------------------------------
** 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
******************************
