Cryptography-Digest Digest #576, Volume #11 Thu, 20 Apr 00 06:13:00 EDT
Contents:
Re: Very Large S-Boxes VLSB's ("Adam Durana")
Re: password generator (Tom St Denis)
Re: BS on AES3 (from the latest Cryptogram) (Lonie M. Raky)
Re: Very Large S-Boxes VLSB's (Tom St Denis)
Re: One Time Pads Redux ("Joseph Ashwood")
Re: Books on maths behind NFS (Scott Contini)
potency of a congruetial generator (Tom St Denis)
Proving that you are who you say you are ([EMAIL PROTECTED])
Re: password generator ("Trevor L. Jackson, III")
Re: Books on maths behind NFS (Christof Paar)
Re: Proving that you are who you say you are (stanislav shalunov)
Re: Should there be an AES for stream ciphers? (Hideo Shimizu)
Re: Proving that you are who you say you are (Paul Rubin)
Re: ? Backdoor in Microsoft web server ? [correction] ("Douglas A. Gwyn")
Re: Q: Entropy (Bryan Olson)
Re: BS on AES3 (from the latest Cryptogram) (Roger)
Re: Regulation of Investigatory Powers Bill ("Scotty")
Re: Regulation of Investigatory Powers Bill ("Scotty")
Re: Regulation of Investigatory Powers Bill ("Ken D.")
----------------------------------------------------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Very Large S-Boxes VLSB's
Date: Tue, 18 Apr 2000 18:51:11 -0400
> > I would like to konw, why are we still using small S-Boxes with 70's
> > memory limitations..
> >
> > Has anyone designed a Block Cipher with VLSB (Very Large
> > S-Box)...something like 128x128 -----> 1024x1024
> >
> > Memory is pretty cheap these days...Non Linear VLSB's would be very
> > strong against Differential and Linear Attack....
>
> That's pretty silly actually. A 8x8 sbox takes 256 bytes of ram, a
> 128x128 sbox would take 2^128 bytes of ram. Apparently your thinking is
> quite flawed.
Actually if a 8x8 s-box uses 256 (2^8) 8-bit entries, then a 128x128 would
use 2^128 128-bit entries, or 16 * 2^128 bytes! I guess it all depends on
how you implement an s-box.
We have small s-boxes now that are very strong against differential and
linear analysis. The size alone will not make a s-box resistant to
analysis, the way the s-box is designed and used determines this.
- Adam
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: password generator
Date: Tue, 18 Apr 2000 22:55:26 GMT
Anton Stiglic wrote:
>
> Here are some comments on the code:
>
> static int trng_bit(void)
> {
> long a, b;
>
> b = 0;
> a = GetTickCount();
> while (a == GetTickCount())
> b ^= 1;
> return b&1;
> }
>
> Something seems wrong with this function. I don't know what exactly
> GetTickCount() returns, but if it's something greater or equal to 1,
> you will always be returning 0. Here is why: in your while loop,
> you XOR b with 1, b start at 0, so the first time in you get
> b = 0 XOR 1 = 1. Every other iteration, you simply do
> b = 1 XOR 1, which will always give you b = 1
> (you might want to do something like a logical AND instead).
> Now, when you go out of the while loop, you return b&1,
> which I believe you do so as to get the last bit (inverted), so
> you will always return 0 if you ever went in the while loop.
Um actually no. 1 xor 1 = 0 xor 1 = 1 xor 1 = 0 ....
Your analysis is wrong.
Tom
------------------------------
From: [EMAIL PROTECTED] (Lonie M. Raky)
Subject: Re: BS on AES3 (from the latest Cryptogram)
Date: Tue, 18 Apr 2000 22:58:34 GMT
Bruce Schneier is a regular on this newsgroup. I would think that if he
wanted that posted here, he would have done it himself.
--
"Lonie M. Raky" is actually 5384 279016 <[EMAIL PROTECTED]>.
01234 5 6789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Very Large S-Boxes VLSB's
Date: Tue, 18 Apr 2000 23:34:30 GMT
Adam Durana wrote:
>
> > > I would like to konw, why are we still using small S-Boxes with 70's
> > > memory limitations..
> > >
> > > Has anyone designed a Block Cipher with VLSB (Very Large
> > > S-Box)...something like 128x128 -----> 1024x1024
> > >
> > > Memory is pretty cheap these days...Non Linear VLSB's would be very
> > > strong against Differential and Linear Attack....
> >
> > That's pretty silly actually. A 8x8 sbox takes 256 bytes of ram, a
> > 128x128 sbox would take 2^128 bytes of ram. Apparently your thinking is
> > quite flawed.
>
> Actually if a 8x8 s-box uses 256 (2^8) 8-bit entries, then a 128x128 would
> use 2^128 128-bit entries, or 16 * 2^128 bytes! I guess it all depends on
> how you implement an s-box.
>
> We have small s-boxes now that are very strong against differential and
> linear analysis. The size alone will not make a s-box resistant to
> analysis, the way the s-box is designed and used determines this.
>
Foot in mouth mode...hehehe... Yeah sboxes upto around 12x8 were used in
loki right?
It's entirely possible to make a secure block cipher without the aid of
a sbox though. So while they are usefull and probably the most
efficient means, there are other ways.
Tom
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: One Time Pads Redux
Date: Tue, 18 Apr 2000 16:32:06 -0700
Thinking about this again, if you can find a function f(),
or a pair of function f() and g(), such that
f'(g(f())) = g()
the key of g() cannot be determined by knowing the plaintext
it can be secure.
However building such a system will be very painstaking and
the security will likely be suspect, because it is extremely
difficult (if not impossible) to prove that g will truly
satisfy the needed properties, especially the
non-determinability of the key given plaintext and
ciphertext. It would be necessary to use large blocks of
data and key, to avoid a rather brutish attack of simply
storing all possible mappings. It may be worth investigating
if you have some spare time.
Joe
------------------------------
From: [EMAIL PROTECTED] (Scott Contini)
Subject: Re: Books on maths behind NFS
Date: 18 Apr 2000 23:59:50 GMT
In article <8dhftu$87g$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>I'm trying to understand the Number Field Sieve, and to do this I need
you're not the only one!
>to learn the algebraic number theory behind it. Can anyone suggest
>any good books that cover this stuff?
I've only had one class on algebraic number theory, which used a book
called "Number Fields" by Daniel Marcus. I think this is a good book,
but it is perhaps not ideal for learning the mathematics behind the
number field sieve, since it is not algorithmic. Michael Pohst has
published some books and algorithmic algebraic number theory, but I
have not had the opportunity to look at them yet. And of course there
is Henri Cohen's book, which is always nice to have handy.
So far I have benefited the most from the following papers:
"Factoring Integers with the Number Field Sieve"
by Buhler, Lenstra, and Pomerance. This is *THE* paper to learn
the general number field sieve from. And you can be sure that
any paper that has Pomerance's name on it is readable and well
motivated. This is in the book edited by Lenstra and Lenstra.
"The Number Field Sieve"
by Lenstra, Lenstra, Manasse, and Pollard. This is maybe the first paper
that explains the (special) number field sieve in detail. However,
there have been nice improvements to the algorithm since this
paper has been written, so I wouldn't get too caught up in any of
the math that seems ugly, such as figuring out the ring of
integers, determining the unit contribution, and the way they handle
the matrix in section 9.1 (elimination over Z). This is in the book
edited by Lenstra and Lenstra.
"Polynomial Selection for the Number Field Sieve Integer Factorisation
Algorithm"
by Brian Murphy (PhD Thesis), available at Richard Brent's web site:
http://web.comlab.ox.ac.uk/oucl/work/richard.brent/students.html
This thesis not only treats polynomial selection, which is one of
the most important areas for optimizing an implementation, but also
gives a nice explanation of a lot of the mathematics behind the
number field sieve. It is a MUST read for anyone wanting to produce
a real NFS implementation.
"Factorization of the 9th Fermat Number"
by Lenstra, Lenstra, Manasse, and Pollard. You can get this
from Mark Manasse's web site:
http://www.research.compaq.com/SRC/personal/msm/common/f9paper.ps
In my opinion, this is the greatest factorization result ever, so this
paper is definitely a must read. It also contains a lot of nice
historical information.
There are still a lot of papers that I have yet to get my hands on.
I am constructing a web site for factoring information, at:
http://www.maths.usyd.edu.au:8000/u/contini/factoring/FactorWorld.html
The web site is called FactoWorld. I will be making updates to
it regularly.
I have 2 example number field sieve implementations on the web site,
which run under the Magma computer algebra system. These are not
optimized - their purpose is to give people an idea of how to write
a real number field sieve implementation. I will be making updates
to these programs upon finding bugs or improving implementations.
I expect to soon have some code up that does Murphy's polynomial selection
for non-skewed polynomials. Code for skewed polynomials will be up
some time in the future too. I also expect to do an implementation
of lattice sieving within a few months.
Scott
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: potency of a congruetial generator
Date: Wed, 19 Apr 2000 00:11:35 GMT
p: prime
a: multiplier
b: b <- a - 1
c: relatively prime to p
Where 'b' is a multiple of all the prime factors of p-1.
Therefore
Xi = aXi-1 + c mod p
Is a linear congruetial generator of period p-1.
Therefore the potency (dependancy on previous outputs?) is the s
variable in, b^s = 0 mod p.
What type of values for 's' are desirable?
Can this logic extend to lcg's with 'c = 0'?
Tom
------------------------------
From: [EMAIL PROTECTED]
Subject: Proving that you are who you say you are
Date: Wed, 19 Apr 2000 00:07:41 GMT
I'm going to be working on developing a client/server application pair
this summer in which the client will communicate with the server using
a closed, proprietary protocol. I need some mechanism to insure that
only _my_ client talks to the server. In other words, although the
protocol will not be documented, I want to guard against the
possibility that someone will reverse engineer the protocol using a
packet sniffer and write an alternative client that emulates my real
client and talks to the server. This application will be used inside a
large corporate intranet system, and, based on certain 'organizational
politics' type issues, it is extremely likely that someone will try to
create a rogue/imposter client. My job is to make sure that the person
who tries this does not succeed. :-)
This seems like the kind of problem that others may have faced before,
and I would like to know how this is generally dealt with. Obviously,
there is going to have to be some kind of authentification handshake in
the protocol in which my client identifies itself as being the real
McCoy before the server starts talking. I assume the best way to do
this is to use RSA encryption, i.e., the client transmits some data
that is encrypted with a private key and the server decrypts it with a
public key. However, I'm concerned about two things. First, if I
distribute an application with a key, won't it be rather easy for a
person with malicious intentions to get ahold of the key and then spoof
being the real client? Should I encrypt the key? Also, secondly, what
data should I encrypt and send? If I just send an encrypted version of
the same message each time (e.g, the word "HELLO"), it'll be pretty
easy to fake out the server because the crypt text will always be the
same. I thought about encrypting the current time (the requirements
for the project assume that the client machines are all set to the
correct time +/- 10 minutes) and sending that, but if anyone ever
figured out that that was what the crypt text was, it might be possible
to crack the key pair. (i.e., knowing that the crypt text was always
an encrypted version of the current time would give a cracker a very
large set of plain text/crypt text pairs, and this might make it easy
to determine the value of the key).
Does anyone have any suggestions? I feel like I must be missing an
obvious solution here...
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Tue, 18 Apr 2000 20:43:14 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: password generator
This is an interesting post. How did you become part of the ZKS development
team without learning about fundamental boolean logic?
These are fundamental logical operations AND and XOR. Their truth tables are
as follows:
0 XOR 0 = 0
0 XOR 1 = 1
1 XOR 0 = 1
1 XOR 1 = 0
0 AND 0 = 0
0 AND 1 = 0
1 AND 0 = 0
1 AND 1 = 1
Who taught you differently?
Anton Stiglic wrote:
> Here are some comments on the code:
>
> static int trng_bit(void)
> {
> long a, b;
>
> b = 0;
> a = GetTickCount();
> while (a == GetTickCount())
> b ^= 1;
> return b&1;
> }
>
> Something seems wrong with this function. I don't know what exactly
> GetTickCount() returns, but if it's something greater or equal to 1,
> you will always be returning 0. Here is why: in your while loop,
> you XOR b with 1, b start at 0, so the first time in you get
> b = 0 XOR 1 = 1. Every other iteration, you simply do
> b = 1 XOR 1, which will always give you b = 1
> (you might want to do something like a logical AND instead).
> Now, when you go out of the while loop, you return b&1,
> which I believe you do so as to get the last bit (inverted), so
> you will always return 0 if you ever went in the while loop.
>
> Anton
------------------------------
From: Christof Paar <[EMAIL PROTECTED]>
Subject: Re: Books on maths behind NFS
Date: Tue, 18 Apr 2000 20:45:38 -0400
A quite accessible book is:
@BOOK{Riesel,
AUTHOR = "H. Riesel",
TITLE = "Prime Numbers and Computer Methods for Factorization",
PUBLISHER = "{Birkh\"{a}user}",
ADDRESS = "Boston, Basel, Stuttgart",
EDITION = "2nd",
YEAR = "1994"
}
It does a really nice job balancing theory and applications. Starts with
the early factorization methods and goes all the way to elliptic curves and
NFS.
Just checked www.bn.com: For whatever reason they sell the hard-cover
(!) version for $15. No idea whatsoever why it's so cheap with them.
Regards,
Christof
! WORKSHOP ON CRYPTOGRAPHIC HARDWARE AND EMBEDDED SYSTEMS (CHES 2000) !
! WPI, August 17 & 18, 2000 !
! http://www.ece.wpi.edu/Research/crypt/ches !
***********************************************************************
Christof Paar, Assistant Professor
Cryptography and Information Security (CRIS) Group
ECE Dept., WPI, 100 Institute Rd., Worcester, MA 01609, USA
fon:(508) 831 5061 email: [EMAIL PROTECTED]
fax:(508) 831 5491 www: http://www.ece.wpi.edu/People/faculty/cxp.html
***********************************************************************
On Tue, 18 Apr 2000 [EMAIL PROTECTED] wrote:
> I'm trying to understand the Number Field Sieve, and to do this I need
> to learn the algebraic number theory behind it. Can anyone suggest
> any good books that cover this stuff?
>
> [I have Koblitz ("A Course in Number Theory and Cryptography") on order,
> but given that this dates from 1994 there may be more recent books that
> have more coverage of NFS.]
>
> TIA
>
> Chris
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
------------------------------
Subject: Re: Proving that you are who you say you are
From: stanislav shalunov <[EMAIL PROTECTED]>
Date: Wed, 19 Apr 2000 00:50:42 GMT
[EMAIL PROTECTED] writes:
> I'm going to be working on developing a client/server application
> pair this summer in which the client will communicate with the
> server using a closed, proprietary protocol. I need some mechanism
> to insure that only _my_ client talks to the server. In other
> words, although the protocol will not be documented, I want to guard
> against the possibility that someone will reverse engineer the
> protocol using a packet sniffer and write an alternative client that
> emulates my real client and talks to the server.
I do not sympathize with your goals, however...
The protocol itself should be documented. If keeping the protocol
closed helps you, the other protection methods are insufficient and
should be fixed.
PK systems would not buy you anything. The attacker is as likely
to obtain a secret key from your binary as a symmetric shared key.
You'll have to embed a some data into your binary that must be
obfuscated enough for an attacker to be unable to to get it. This
is outside of scope of sci.crypt, but techniques for hiding data in
executables include:
* Not putting it into the source as an ASCII NUL-terminated string.
* Hiding several pieces of information and using one to encrypt the
other, taking hashes of intermediate results, etc.
* Making pieces look like valid machine instructions.
Some "copy protection" experts might be of further use here.
The client has to authenticate itself to the server. This is where
some cryptography might help. Have all communications be encrypted
with a session key.
The client would produce by a complicated computation a fixed shared
secret string (e.g., 128-bit). We'll call it the master key.
You could further have the server, in the beginning of the session,
send a randomly generated 128-bit session key, encrypted with the
master key. The protocol would proceed with all exchanges encrypted
with the session key. The attacker can disrupt the session, so
appending an MD5 hash of each message to the message before encryption
might be useful.
It should be realized that this scheme only protects against a
network-based attack. No amount of obfuscation would hide the master
key from a sufficiently determined attacker who has your binary, a
debugger, and a lot of free time. No other scheme would protect
against such attacker, either.
--
stanislav shalunov | Speaking only for myself.
My address in From: is correct; if yours isn't, I don't want to hear from you.
Try to reply in newsgroup. I don't need courtesy copies.
------------------------------
From: Hideo Shimizu <[EMAIL PROTECTED]>
Subject: Re: Should there be an AES for stream ciphers?
Date: Wed, 19 Apr 2000 09:43:07 +0900
> RC4 seems to be about the only choice, SEAL hasn't had the
> cryptoanalysis time it should, and also, I don't know about speed, but I
> assume that Stream ciphers are (or should be) faster than block
> ciphers...
SEAL has been updated. Recent version is SEAL3.0.
Recently I hear that ISO standarization committee start the study period
for the purpose of standard of the stream cipher.
Hideo Shimizu
TAO, Japan
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Proving that you are who you say you are
Date: 19 Apr 2000 00:55:48 GMT
In article <8ditc3$scl$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>I'm going to be working on developing a client/server application pair
>this summer in which the client will communicate with the server using
>a closed, proprietary protocol.
That's your first mistake. Please correct it before going any further.
>I need some mechanism to insure that only _my_ client talks to the
>server. In other words, although the protocol will not be
>documented, I want to guard against the possibility that someone will
>reverse engineer the protocol using a packet sniffer and write an
>alternative client that emulates my real client and talks to the
>server.
Document the protocol. All secrets should reside in cryptography keys,
not implementation obscurity.
>This seems like the kind of problem that others may have faced before,
You'd kind of think so :).
>and I would like to know how this is generally dealt with. Obviously,
>there is going to have to be some kind of authentification handshake in
>the protocol in which my client identifies itself as being the real
>McCoy before the server starts talking. I assume the best way to do
>this is to use RSA encryption, i.e., the client transmits some data
>that is encrypted with a private key and the server decrypts it with a
>public key.
This is one approach that works and is reasonable. There are many others.
>However, I'm concerned about two things. First, if I
>distribute an application with a key, won't it be rather easy for a
>person with malicious intentions to get ahold of the key and then spoof
>being the real client?
Yes.
>Should I encrypt the key?
No. Don't distribute any private keys. The key pair (private/public)
should be generated BY THE CLIENT at client installation time, and the
public part given to the server. You have to authenticate the public
key by external means, such as contacting the authorized user by
telephone to verify the fingerprint. The secret key should never leave
the client. If the client computer is not considered secure in your
application, then you have to encapsulate the secret in a secure token.
If you say more about your application, I (or others on this group) might
be able to give more specific advice.
>Also, secondly, what data should I encrypt and send? If I just send
>an encrypted version of the same message each time ...
>
>Does anyone have any suggestions? I feel like I must be missing an
>obvious solution here...
Rather than answering your question about what data to encrypt, I
will give meta-advice that I hope you will take to heart:
You should not be messing with cryptographic protocol design at this
level, especially given your state of knowledge (that's not intended
to be snotty, it's just the way life is). Use an existing protocol
instead. Try looking at, for example, the TLS specification (RFC
2246) and you might want to simply use an SSL/TLS stack
(www.openssl.org) which encrypts your whole communication. Keep in
mind that TLS is basically a renaming of SSL 3.0 with some minor
updates, and the "3.0" in SSL 3.0 is because SSL 1.0 and 2.0 had
security flaws discovered after publication, even though they were
designed by experts, reviewed by other experts, and (per the RFC
process) had multiple independent interoperating implementations
developed before becoming standards. And yet they still had subtle
flaws.
It is *extremely* difficult to get this stuff right even if you know
what you're doing. It's best to use an open protocol that has already
been analyzed and debugged. Although TLS 1.0 has some blemishes, it
is generally believed robust and many high-value systems use it.
If you want some good reading on the subject (cryptography in general,
not specifically SSL/TLS), try Applied Cryptography (2nd ed.) by Bruce
Schneier, which is basically the standard reference for this
newsgroup.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: ? Backdoor in Microsoft web server ? [correction]
Date: Wed, 19 Apr 2000 01:10:15 GMT
Diet NSA wrote:
> Y'all might want to take a look at this
> recent & brief news article entitled
> "Gates and Gerstner Helped NSA Snoop"
> which discusses the _NSAKEY, etc.
We already thoroughly discussed and debunked that.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Q: Entropy
Date: Wed, 19 Apr 2000 01:59:49 GMT
In article Mok-Kong Shen wrote:
> I am ignorant but wonder whether a TM could determine if an infinite
> sequence contains any period at all.
I don't see how. One reason I like the definition I
suggested is that it avoids referring to a Turing
machine's behavior on any infinite input.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Roger <[EMAIL PROTECTED]>
Subject: Re: BS on AES3 (from the latest Cryptogram)
Date: Tue, 18 Apr 2000 20:03:21 -0700
Mark Wooding wrote:
> Paul Rubin <[EMAIL PROTECTED]> wrote:
>
> > Why do you say this is BS?
>
> Because it was written by Bruce Schneier and those are his initials.
>
> Just a guess.
Are you sure it wasn't written by Bob Silverman or Brian Snow? <g>
------------------------------
From: "Scotty" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk,alt.computer.security
Subject: Re: Regulation of Investigatory Powers Bill
Date: Wed, 19 Apr 2000 04:05:24 +0100
[EMAIL PROTECTED] wrote in message ...
>>>>>But Bob is forbidden to tell Papinski that the police are involved.
>>>
>>>No not in this case, you are forbidden under penalty of 5 years
>>>imprisonment if you tell anyone except you lawyer.
>
>
> What about a lack of statements?
>
> eg: Before sending his secret key and/or any
>encrypted material, Bob always asks Alice if
>she is under investigation.
>
> Normally, she will always answer
>
>"not that I know".
>
> But if one day she stays quiet or says something like
>
>"I can't answer under penalty of law"
>
> then Bob realises something is wrong and stops
>all communications.
>
If Bob realises something is wrong based on his communications with Alice
then he's been tipped off. How that communication occurs isn't important. It
could be little more than a 'nod and a wink' but if its enough to enable Bob
to work out that their communications are no longer confidential then Alice
is guilty.
------------------------------
From: "Scotty" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk,alt.computer.security
Subject: Re: Regulation of Investigatory Powers Bill
Date: Wed, 19 Apr 2000 03:52:21 +0100
Robert Stonehouse wrote in message
<[EMAIL PROTECTED]>...
>"Scotty" <[EMAIL PROTECTED]> wrote:
>...
>>Now compare that with the new clause in the RIP bill:
>>
>>"(2) If any person with the appropriate permission under Schedule 1
>>believes, on reasonable grounds-
>> (a) that a key to the protected information is in the possession of any
>>person,
>><snip>
>>the person with that permission may, by notice to the person whom he
>>believes to have possession of the key, require the disclosure of the
key."
>>
>>and
>>
>>"49. - (1) A person is guilty of an offence if-
>> (a) he fails to comply, in accordance with any section 46 notice, with
any
>>requirement of that notice to disclose a key to protected information; and
>> (b) he is a person who has or has had possession of the key. "
>
>The effect of this is to impose a duty on any person who uses
>encryption to keep a complete record of the keys he (or she) has
>used. Similarly, any person who enjoys the privileges of limited
>liability has to keep statutory records - register of members, books
>of account.
>
There is no statutory duty to keep any such records. If it was a requirement
it would be written into the act, you are reading something into the act
which isn't there. Keeping a written record of passwords is hardly conducive
to good security, and escrow was specifically dropped from the early version
of the e-commerce bill.
>>Clause 2 now requires the prosecution to show 'reasonable grounds' to
>>believe that you have a key. Reasonable grounds is in effect 'balance of
>>probabilities'. Notice the argument is not over whether you have a key or
>>not, but whether the police etc can *reasonably believe* that you do. Once
>>this hurdle is passed everything is automatic as before. Failure to comply
>>is still an offence and forgetting your key wont get you off, you have to
>>prove you've forgotten it.
>
>It won't get you off even then. You have a duty to know the key. If
>you prove you've forgotten it, you prove yourself guilty.
With respect that's nonsense, if you can satisfy a judge and jury that you
have forgotten the key you can't be found guilty.
>
>>Rather like driving with excess alcohol or speeding, failure to comply
with
>>a decryption notice is an absolute offence, i.e. you're automatically
guilty
>>until you can show you're innocent. (For example, a defence of 'I drove
with
>>excess alcohol because a terrorist hijacked my car and made me do it at
gun
>>point' would have to be proved by the defence beyond reasonable doubt).
>
>No, it is not 'guilty until proved innocent'. It has to be shown you
>are a person who has or has had the key.
That is what I wrote.
>If that is shown, then you
>have a duty to keep and produce the key.
No, same reason as before.
>
>Of course, if the data were not in fact encrypted, there would be no
>person who had the key.
>
>There seem to be plenty of problems with this proposed legislation.
>It just obscures the issue, attacking it for things that aren't
>there.
There is no mention in the act of any 'duty to know the key'. Most of the
time you will not know the actual key used since the password you type is
*not* the key. The key may have been destroyed making the password useless.
If you can satisfy a judge and jury that you have forgotten the key then you
can't be found guilty.
------------------------------
From: "Ken D." <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: alt.security.scramdisk,alt.computer.security
Subject: Re: Regulation of Investigatory Powers Bill
Date: Wed, 19 Apr 2000 04:23:01 GMT
"Trevor L. Jackson, III" wrote:
>
> _Andy_ wrote:
>
> > On Tue, 18 Apr 2000 06:40:47 +0100, Philip Baker <[EMAIL PROTECTED]>
> > wrote:
> > Papinski sends Bob only the public key, which Bob uses to encrypt the
> > file. For Bob to decrypt the file, he must request the private key
> > from Papinski. Papinski will not supply the key to anyone apart from
> > Bob, and will not supply it to Bob if the police are involved.
>
> But Bob is forbidden to tell Papinski that the police are involved.
but what if bob just happens to forget to mention that the police
are NOT involved... :)
------------------------------
** 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
******************************
