Cryptography-Digest Digest #735, Volume #13 Thu, 22 Feb 01 23:13:00 EST
Contents:
Re: The Key Vanishes: Scientist Outlines Unbreakable Code, Read it and Weep Boys
("Paul Pires")
Looking for help build a open Trusted signature system (Darryl Wagoner)
Re: What does tempest stand for. (Anne & Lynn Wheeler)
Re: The Key Vanishes: Scientist Outlines Unbreakable Code, Read it and Weep Boys
(wtshaw)
Processing on cyphertext (Ian Woods)
Re: super-stong crypto, straw man phase 2 (David Wagner)
Re: Random number encryption (Gregory976)
Re: New unbreakable code from Rabin? ([EMAIL PROTECTED])
Re: The Key Vanishes: Scientist Outlines Unbreakable Code, Read it and (Steve
Portly)
Re: The Key Vanishes: Scientist Outlines Unbreakable Code, Read it and ("Douglas A.
Gwyn")
Re: The Key Vanishes: Scientist Outlines Unbreakable Code, Read it and ("Douglas
A. Gwyn")
Re: super-stong crypto, straw man phase 2 ("Douglas A. Gwyn")
Re: New unbreakable code from Rabin? ("Douglas A. Gwyn")
Re: The Key Vanishes: Scientist Outlines Unbreakable Code, Read it and
([EMAIL PROTECTED])
Re: Super strong crypto (Nicol So)
Re: New unbreakable code from Rabin? ([EMAIL PROTECTED])
Re: Processing on cyphertext ("Scott Fluhrer")
----------------------------------------------------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: The Key Vanishes: Scientist Outlines Unbreakable Code, Read it and Weep
Boys
Date: Thu, 22 Feb 2001 13:42:52 -0800
Mok-Kong Shen <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> "Douglas A. Gwyn" wrote:
> >
> > You guys are making it harder than it has to be.
> > It isn't hard to set up such a public random-bit stream
> > so that parties can agree which bit is which.
> > The proposed scheme then, as I understand it, has
> > the communicants generating *in any way they wish,
> > so long as both parties do the same thing and the
> > enemy can't guess how*, locations in the public stream
> > of the bits that are to be assembled into a one-time-pad
> > key, which is then used the usual way.
> > For example, the location generator could produce a
> > series of *skip counts* which are taken as the number
> > of bits to skip between the bits taken for the key,
> > starting at some publicly announced synch point.
> > Any standard crypto-quality sequence generator could
> > be used to generate those skip counts.
>
> Dumb questions: Employing a crypto-qualtiy generator,
>
> (1) Why doesn't one use that directly to do encryption?
Plausible deniability. One could say they used it but did not
record it so they cannot disclose it. They cannot re-generate
it since they never generated it before. I don't see a practical
use for this at all. The only ones who would be able to record
and playback are the only ones likely to force you to disclose.
It seems like a high end response to a high end threat that doesen't
materially effect the common threat. If your wife wants into your
communications, she's not going to hack RSA or AES but hire
bent nosed Louie to break your knee-capps.
(You didn't hear that sweety)
It really looks like a solution in search of a problem.
>
> (2) Couldn't the public stream be simply 01010101....
> instead of a random one?
It needs to be unpredictable to pass a sanity check. Otherwise,
if it is predictable, why broadcast? It probably wouldn't have to
be completely unbiased since it's going to get further processing
but it would loose any value if it was predictable.
Paul
>
> Thanks.
>
> M. K. Shen
------------------------------
From: Darryl Wagoner <[EMAIL PROTECTED]>
Subject: Looking for help build a open Trusted signature system
Date: Thu, 22 Feb 2001 17:15:16 -0500
Reply-To: [EMAIL PROTECTED]
Greetings,
The following message I posted a few days ago stating my intention
to build a trusted E-QSL system. QSL is the Amateur
radio term for what has been a card as proof of contact. I would
like to change this to an Open Source Trusted E-QSL system using
digital signatures. The important parts of this system needs
to be simple to use, secure, support for large number of CA,
simple to use, exportable, and oh yes, simple to use.
My goal isn't to make money from this, but to help Hams
in their hobby. Anyone interested in helping me?
ham text to follow:
I believe in E-QSL, but nothing I have seen so fair fills the bill.
I think the solution should be open source so that we don't get
locked in to one provider of trusted E-QSLs.
Here is the idea:
The system would use digital signatures based upon the RSA
encryption standard. The public key would be signed by a
trusted third party. Once the key has been signed, it can
be transmitted with the E-QSL or looked up in a trusted public
key server. The details is a little hard to explain, but
the jest is once a amateur has a signed public key, anyone
can validate their e-qsl information without using a active
protocol with a third part. This means that my log program
can email a qsl information almost in real time.
Everything needed to do this is public and free to use. We
will need the following functions:
1. Certification Authority software and libraries.
2. Signing libraries.
3. validation libraires.
The goal is to create a set of libraries and software which
will be licensed using LGPL (Lessier Gnu Public Licenses) or
open software licenses. This will allow trusted groups such
as ARRL to have a revenue on create certifications (signing
public keys) but no one will have a lock on the software.
This we allow logging software authors to incorporate digital
signature functions into their logging program without having
to pay a license fee.
I can do most of the design and some of the program, but I
can't do it by myself. Most important I DO NOT want to OWN IT.
For this to work it must be a free standard, with no strings
attached.
TQSL to be:
1. A trusted system
2. Free and open standards
3. Easy to use and implement. ie: Users pushs a button on
his/her logging program and a TQSL is created. This eqsl
could be sent via email, to a e-buro, etc. The important
thing is once created it can be authenicated at any point
by anyone, just by point software at it.
Any takers?
Darryl Wagoner WA1GON
[EMAIL PROTECTED]
------------------------------
Subject: Re: What does tempest stand for.
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Thu, 22 Feb 2001 22:19:21 GMT
[EMAIL PROTECTED] (Mark Healey) writes:
> I know that "tempest" is an acronym (really T.E.M.P.E.S.T.) but I
> forgot what it stands for. Surprisingly this isn't in any of the
> online sources I could find.
>
> Could someone please tell me.
>
> Mark Healey
> marknews(the 'at' thing)healeyonline.com
available number of online sources, including rfc2828
also see security glossary at
http://www.garlic.com/~lynn/secure.htm
TEMPEST
(O) A nickname for specifications and standards for limiting the
strength of electromagnetic emanations from electrical and electronic
equipment and thus reducing vulnerability to eavesdropping. This term
originated in the U.S. Department of Defense. [Army, Kuhn, Russ] (D)
ISDs SHOULD NOT use this term as a synonym for 'electromagnetic
emanations security'. [RFC2828] The study and control of spurious
electronic signals emitted by electrical equipment, such as computer
equipment. [AJP][NCSC/TG004][TCSEC] (see also approval/accreditation,
preferred products list) (includes compromising emanations,
emanations, emanations security, emission security)
--
Anne & Lynn Wheeler | [EMAIL PROTECTED] - http://www.garlic.com/~lynn/
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: The Key Vanishes: Scientist Outlines Unbreakable Code, Read it and Weep
Boys
Date: Thu, 22 Feb 2001 15:42:43 -0600
In article
<[EMAIL PROTECTED]>,
"Xavier Onassis" <[EMAIL PROTECTED]> wrote:
>
> I don't get the claim that the key vanishes.
>
I think it's rather a case that arguments for doing a private protocol
with private keys remain the same, that they can be more difficult to
trace and or reproduce than a system based on questionable mathematical
hyperbolae, sort of, and counting on refined procedures with having
someone else have anything to do with any of your keys.
--
Better to pardon hundreds of guilty people than execute one
that is innocent.
------------------------------
From: [EMAIL PROTECTED] (Ian Woods)
Subject: Processing on cyphertext
Date: Thu, 22 Feb 2001 22:25:57 +0000 (UTC)
Is anyone aware of any encryption schemes which allow some (restricted)
forms of processing on cyphertext? To make a bit more sense...
E(num1,key) * E(num2,key) = E(num1*num2,key)
Or in English: performing an operation on two encrypted numbers (num1 and
num2) creates a new cyphertext which when decrypted is the value of the
operation performed on num1 and num2.
I have 'cooked up' one (very insecure) scheme which exhibits this property
for a small number of operations (which isn't at all practical).
Ian Woods
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: super-stong crypto, straw man phase 2
Date: 22 Feb 2001 23:02:04 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Douglas A. Gwyn wrote:
>Now that you've assimilated my initial straw man, note that the
>idea is much the same applied to stream or to block ciphers.
>You can express this as another kind of "block chaining mode":
>each block encrypts PT plus a new batch of random key bits,
>which are (perhaps) shifted into the key register before
>encrypting the next block. The idea is to keep injecting
>fresh entropy into the channel; note that if the batch size
>is nonnegligible, it foils known-plaintext attacks.
I guess I don't understand. This is a heuristic trick, but there are
many other heuristic tricks, and they all have to be evaluated on a
cost-benefit basis. The cost of your proposal is very high: It doubles
bandwidth requirements. In comparison, doubling the number of rounds is
much cheaper (network bandwidth is scarcer than CPU cycles) and seems
likely to provide similarly strong-albeit-heuristic protection against
cryptanalysis. I'd like to understand what your proposal provides that,
say, Triple-DES-CBC doesn't already offer. Am I overlooking something?
------------------------------
From: [EMAIL PROTECTED] (Gregory976)
Date: 23 Feb 2001 00:06:05 GMT
Subject: Re: Random number encryption
I'm assuming that you mean some kind of one time pad system and, in fact, it is
used quite for those situations in which it is practical to occasionally
transfer large amounts of data securely.
Embassies and other government organizations which need a large degree of long
term security routinely use one time pads.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: New unbreakable code from Rabin?
Date: 23 Feb 2001 01:45:50 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> I think it is envisioned that a single constellation of satellites
> could broadcast the random bit streams for everybody in the world
> to use (each channel its own subset).
One problem with this is that you now have to trust whomever
controls these satellites that they are actually emitting
true random bit streams, as opposed to something algorithmically
generated and with a (known only to them) exploitable weakness.
Steve
------------------------------
From: Steve Portly <[EMAIL PROTECTED]>
Subject: Re: The Key Vanishes: Scientist Outlines Unbreakable Code, Read it and
Date: Thu, 22 Feb 2001 22:02:47 -0500
Paul Pires wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
> >
> >
> > "Douglas A. Gwyn" wrote:
> > >
> > > You guys are making it harder than it has to be.
> > > It isn't hard to set up such a public random-bit stream
> > > so that parties can agree which bit is which.
> > > The proposed scheme then, as I understand it, has
> > > the communicants generating *in any way they wish,
> > > so long as both parties do the same thing and the
> > > enemy can't guess how*, locations in the public stream
> > > of the bits that are to be assembled into a one-time-pad
> > > key, which is then used the usual way.
> > > For example, the location generator could produce a
> > > series of *skip counts* which are taken as the number
> > > of bits to skip between the bits taken for the key,
> > > starting at some publicly announced synch point.
> > > Any standard crypto-quality sequence generator could
> > > be used to generate those skip counts.
> >
> > Dumb questions: Employing a crypto-qualtiy generator,
> >
> > (1) Why doesn't one use that directly to do encryption?
>
> Plausible deniability. One could say they used it but did not
> record it so they cannot disclose it. They cannot re-generate
> it since they never generated it before. I don't see a practical
> use for this at all. The only ones who would be able to record
> and playback are the only ones likely to force you to disclose.
> It seems like a high end response to a high end threat that doesen't
> materially effect the common threat. If your wife wants into your
> communications, she's not going to hack RSA or AES but hire
> bent nosed Louie to break your knee-capps.
>
> (You didn't hear that sweety)
>
> It really looks like a solution in search of a problem.
>
> >
> > (2) Couldn't the public stream be simply 01010101....
> > instead of a random one?
>
> It needs to be unpredictable to pass a sanity check. Otherwise,
> if it is predictable, why broadcast? It probably wouldn't have to
> be completely unbiased since it's going to get further processing
> but it would loose any value if it was predictable.
>
> Paul
> >
> > Thanks.
> >
> > M. K. Shen
Moks example is quite sane, provided people receive separate esoteric keys in
advance. Solutions
for this small example range from Apriori to Ze*, depending on the person reading it.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: The Key Vanishes: Scientist Outlines Unbreakable Code, Read it and
Date: Fri, 23 Feb 2001 03:10:54 GMT
Mok-Kong Shen wrote:
> Dumb questions: Employing a crypto-qualtiy generator,
> (1) Why doesn't one use that directly to do encryption?
Because it doesn't have an associated proof of security
as the indirect scheme is claimed to have.
> (2) Couldn't the public stream be simply 01010101....
> instead of a random one?
No, because the regularity could be folded into the
location generator, which is presumably susceptible
to cryptanalysis.
What is claimed for the scheme is that the enemy would
have to access more information than his storage capacity
in order to mount any cryptanalytic attack. Therefore it
is essential that the bits in the key stream be random.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: The Key Vanishes: Scientist Outlines Unbreakable Code, Read it and
Date: Fri, 23 Feb 2001 03:14:15 GMT
Xavier Onassis wrote:
> I don't get the claim that the key vanishes.
It vanishes because there is too much of it to record
and the enemy doesn't know which bits are important
in time to record them.
> As I understand the proposal, the ciphertext isn't necessarily
> hidden.
Right.
> Then I obtain, abscond with, use rubber hose umm interrogation
> to get the plaintext.
> Do I not then retrieve the key? ...
It's rather pointless to retrieve the one-time key that
was used once you already have the plaintext. The scheme
is intended to protect information in transit, not to
protect the source of the information against physical
assault.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: super-stong crypto, straw man phase 2
Date: Fri, 23 Feb 2001 03:19:32 GMT
"Henrick Hellstr�m" wrote:
> ... brute-force attacks are theoretically possible:
I didn't consider it necessary to stipulate that the key
size would be chosen large enough to prevent brute-force
search of the key space; we generally take that for granted.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: New unbreakable code from Rabin?
Date: Fri, 23 Feb 2001 03:26:13 GMT
[EMAIL PROTECTED] wrote:
> One problem with this is that you now have to trust whomever
> controls these satellites that they are actually emitting
> true random bit streams, as opposed to something algorithmically
> generated and with a (known only to them) exploitable weakness.
I don't think that's as big a problem as you imagine.
If the satellite bit stream is used with a variety of
location generators not under control of the same
agency, and can pass all tests for nonrandomness
that are likely to be applied to it if it really
went into operation, it doesn't appear that there
would be any way to exploit whatever deeply hidden
pattern it might have.
I don't expect such a system to actually go into
operation..
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: The Key Vanishes: Scientist Outlines Unbreakable Code, Read it and
Date: 23 Feb 2001 03:52:14 GMT
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Organization: a2i network
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> Xavier Onassis wrote:
>> I don't get the claim that the key vanishes.
> It vanishes because there is too much of it to record
> and the enemy doesn't know which bits are important
> in time to record them.
If by "key" we mean information sufficient to decrypt the
ciphertext, I still maintain that:
(1) the "key vanishes" if and only if the sender/recipient destroy
the key rather than retain it;
(2) the exact same thing is true of any private-key cryptosystem.
Steve
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Thu, 22 Feb 2001 22:50:03 -0500
Reply-To: see.signature
Bryan Olson wrote:
>
> The key changes in real systems are there to limit the damage
> from exposed keys; ...
Rekeying is often done for other than the above reason. If your concern
is compromised traffic encryption keys (TEK) and you have a secure
mechanism for establishing new keys, changing the key does have the
effect of limiting the damage of an exposed traffic encryption key.
On the other hand, if you use symmetric encryption to secure key
distribution, the benefit you describe is not a good reason for
rekeying. If your key encryption key (KEK) is susceptible to compromise,
changing the TEK is not going to buy you anything. If you can secure the
KEK and the encryption scheme is secure for practically an unlimited
among of traffic, you may as well use the KEK as the TEK and forget
rekeying. So... rekeying makes sense only if you assume that it is not
safe to encrypt a large amount of traffic under the same key, *for
cryptographic reasons*. Presumably, for a practical cryptanalytic
technique to have a good probability of success, a certain minimum
amount of ciphertext generated using the same key is required. And when
the amount of ciphertext is below the true unicity distance, uniquely
recovering the key with a ciphertext-only attack is impossible.
I doubt if somebody would tell you how to calculate the "natural
lifetime" of a key for a cipher, as methods for such calculations, if
known at all, is probably beyond the public state of knowledge.
My understanding of Douglas Gwyn's proposal is that it does not purport
to achieve anything that information theory says is impossible. As a
heuristic, it does seem to make it necessary to use extraordinarily
clever techniques if cryptanalysis were to succeed.
--
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: [EMAIL PROTECTED]
Subject: Re: New unbreakable code from Rabin?
Date: 23 Feb 2001 03:58:41 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>> One problem with this is that you now have to trust whomever
>> controls these satellites that they are actually emitting
>> true random bit streams, as opposed to something algorithmically
>> generated and with a (known only to them) exploitable weakness.
>I don't think that's as big a problem as you imagine.
>If the satellite bit stream is used with a variety of
>location generators not under control of the same
>agency, and can pass all tests for nonrandomness
>that are likely to be applied to it if it really
>went into operation, it doesn't appear that there
>would be any way to exploit whatever deeply hidden
>pattern it might have.
If the "random" bit stream is in fact algorithmically
generated, then your adversary does not need to store it so the
"unbreakable if attacker has limited storage" claim falls apart.
In this case, if your secret "location generator" is later
compromised, then your adversary can now decrypt your ciphertext
since he can re-generate the bit stream.
Were the bit stream pure random and so large as to be unstoreable,
he couldn't.
I agree this might not be a problem in practice, since
you can layer on enough physical and information security
on your "location generator", but it does defeat the
entire purpose of the scheme.
Steve
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Processing on cyphertext
Date: Thu, 22 Feb 2001 19:54:42 -0800
Ian Woods <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Is anyone aware of any encryption schemes which allow some (restricted)
> forms of processing on cyphertext? To make a bit more sense...
>
> E(num1,key) * E(num2,key) = E(num1*num2,key)
>
> Or in English: performing an operation on two encrypted numbers (num1 and
> num2) creates a new cyphertext which when decrypted is the value of the
> operation performed on num1 and num2.
>
> I have 'cooked up' one (very insecure) scheme which exhibits this property
> for a small number of operations (which isn't at all practical).
RSA:
(x**e mod m) * (y**e mod m) = (x*y)**e mod m
--
poncho
------------------------------
** 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
******************************
