Cryptography-Digest Digest #847, Volume #13 Fri, 9 Mar 01 17:13:00 EST
Contents:
Re: => FBI easily cracks encryption ...? (Jim D)
Re: Q: Tempest Systems (Jim D)
Re: NTRU - any opinions ("James Russell")
Re: Really simple stream cipher ("Scott Fluhrer")
Re: Really simple stream cipher ("Henrick Hellström")
Re: Really simple stream cipher (David Wagner)
Re: Help needed -- reverse-engineering stream-encoder/sequence generator ("Vlad
ROMASCANU")
Re: arbitrary-precision arithmetic ("Cristiano")
Re: Really simple stream cipher ("Henrick Hellström")
Re: Really simple stream cipher ("Henrick Hellström")
Re: Tempest Systems (Mok-Kong Shen)
Bell Systems Technical Journal (JPeschel)
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
Re: The Foolish Dozen or so in This News Group ("Trevor L. Jackson, III")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Jim D)
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Fri, 09 Mar 2001 19:51:08 GMT
Reply-To: Jim D
On Thu, 8 Mar 2001 13:09:05 -0800, Matthew Montchalin
<[EMAIL PROTECTED]> wrote:
>On Thu, 8 Mar 2001, Mxsmanic wrote:
>|By selecting specific frequencies with an antenna that can be aimed;
>|at least that is one method that comes immediately to mind.
>
>Not easy if you have to go through one monitor to get to the next one;
>there's bound to be interference sufficient to make it easier to tap
>a phone line physically than point a gizmo directly at a window. And
>if the communication is encrypted on both sides of the connection,
>then the gizmo is still a tough choice to make.
>
>It seems that having a "line of sight" to the target is something of
>a necessity.
You need to be much closer than that. A few tens of metres. The
inverse square law applies to the radiation, which isn't particularly
strong to start with.
--
___________________________________
George Dubya Bushisms No 4:
'Welcome to Mrs Bush and my
fellow astronauts.'
Posted by Jim Dunnett
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___________________________________
------------------------------
From: [EMAIL PROTECTED] (Jim D)
Subject: Re: Q: Tempest Systems
Date: Fri, 09 Mar 2001 19:51:09 GMT
Reply-To: Jim D
On Thu, 08 Mar 2001 18:46:37 +0100, Frank Gerlach <[EMAIL PROTECTED]>
wrote:
>> Any comments on this? Would never happen? Tempest systems aren't that good?
>> Etc.
>Only few people what kind of singnal processing software is running on
>NSA and GCHQ computers, but signal processing is a very mature science
>and a lot can be done to extract a signal even if it is buried in noise,
>which is hundreds of times stronger.
This is true. I have here a fairly expensive HF receiver which
uses DSP filtering. A noise reduction button sets up a system
which will cancel out noise (random) from the wanted signal
(coherent), provided there is a coherent signal there in the
first place. It works a treat.
What it won't do is separate two coherent signals from each
other.
--
___________________________________
George Dubya Bushisms No 4:
'Welcome to Mrs Bush and my
fellow astronauts.'
Posted by Jim Dunnett
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___________________________________
------------------------------
From: [EMAIL PROTECTED] ("James Russell")
Subject: Re: NTRU - any opinions
Date: 9 Mar 2001 20:53:57 +0100
Will somebody from RSA be joining the discussion next? : )
I appreciate all the feedback, especially the link to the apparently
unbiased paper from Helsinki. I didn't understand the math, but the
conclusion was understandable. Thanks, Sam.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
--
Posted from [206.156.202.110] by way of f66.law10.hotmail.com [64.4.15.66]
via Mailgate.ORG Server - http://www.Mailgate.ORG
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Really simple stream cipher
Date: Fri, 9 Mar 2001 11:46:41 -0800
Henrick Hellström <[EMAIL PROTECTED]> wrote in message
news:98b21q$edm$[EMAIL PROTECTED]...
> "Scott Fluhrer" <[EMAIL PROTECTED]> skrev i meddelandet
> news:98b067$on8$[EMAIL PROTECTED]...
> > I've never been a fan of error propagation, at least to detect delibrate
> > errors. I do not believe that it is good security practice to deliver
> > gibberish to the application, and hope it notices that it's invalid.
>
> Every application that utilizes any kind of security primitive has to be
> designed in a particular way in order not to weaken that security
primitive.
> For instance, passwords, keys etc always have to be carefully handled. It
is
> not principally different to demand that an application that relies on
error
> propagation for authentication purposes must treat input with special
care.
> This just goes to prove that there are good security products, and there
are
> bad, depending on various implementation issues.
>
>
> > IMHO,
> > It is far better to introduce an explicit cryptographic primitive (e.g.
a
> > MAC or a signature) which is designed specifically to reject errors with
> > high probability, and not rely on the behavior of the application under
> > random inputs.
>
> Well, I disagree. The user must always rely on the behavior of the
> application under specific circumstances, regardless of the kind of
security
> primitives it implements. A MAC or a signature does not necessarily reject
> errors with higher probability than a properly designed and implemented
> error propagating cipher.
That is incorrect. A MAC will reject errors with higher probability than
any error propagating cipher, for the simple reason that error propagating
ciphers will never reject errors -- they will just (in the best case) passes
gibberish to the application.
You may have the view that how applications deal with invalid data ought to
be a part of the security model, and so any security review must necessarily
consider the application as well. I humbly disagree: a sizable proportion
of applications are written without any particular cryptographical
properties in mind, and hence for security reasons, no particular
cryptographical properties can be assumed.
> The question is rather which one is most efficient
> and which one is (from the user's epistemic point of view) most likely to
> fail due to poor implementation.
Since we're talking about security, wouldn't the question as to which one is
easier to analyze and is less likely to provide security weaknesses also be
a consideration?
--
poncho
------------------------------
From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Re: Really simple stream cipher
Date: Fri, 9 Mar 2001 20:56:27 +0100
That's not entirely true. Any message authentication scheme have to have the
application reject faulty data, namely the messages that fail the
authentication tests.
Furthermore, many kinds of client/server system (pop, smtp, http, dns,
telnet, the ftp command channel, etc) have to check for faulty data anyway,
because they are expecting a strictly formatted input.
--
Henrick Hellström [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
"David Wagner" <[EMAIL PROTECTED]> skrev i meddelandet
news:98baf3$dap$[EMAIL PROTECTED]...
> Henrick Hellström wrote:
> >Every application that utilizes any kind of security primitive has to be
> >designed in a particular way in order not to weaken that security
primitive.
>
> I prefer to minimize the number of ways that a cipher can be misused.
>
> Since there are alternatives (e.g., MACs) that do not require the
> application to reject gibberish, I see no good reason to introduce
> unnecessary failure modes.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Really simple stream cipher
Date: 9 Mar 2001 20:06:02 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Henrick Hellström wrote:
>That's not entirely true. Any message authentication scheme have to have the
>application reject faulty data, namely the messages that fail the
>authentication tests.
No. The application does not reject that data; the crypto layer rejects
it, before the application ever gets a chance to see it. Any data returned
by the crypto layer is guaranteed to have been covered by a valid MAC, if
you have a well-designed crypto engine.
>Furthermore, many kinds of client/server system (pop, smtp, http, dns,
>telnet, the ftp command channel, etc) have to check for faulty data anyway,
>because they are expecting a strictly formatted input.
But this is not a *security* condition, and so they should not, IMHO, be
trusted to reliably get it right in the face of adversarially-chosen inputs.
------------------------------
From: "Vlad ROMASCANU" <[EMAIL PROTECTED]>
Subject: Re: Help needed -- reverse-engineering stream-encoder/sequence generator
Date: Fri, 9 Mar 2001 13:45:46 -0500
Thanks,
You put me on the right track, and I finally managed to 'crack' the thing.
It turned out it was indeed linear and differential. I still do not know
how to deduce the initial sequence (the one output for constant 0-input)
except by hard-coding the first four values in the sequence and then using
the S0[n+4] = S0[n] - 2 property (where S0 is the constant 0-input
sequence), but I got all the rest.
It turned out
S[n] = S[n-1] + (S0[n] - S0[n-1]) + SUM(INPUT[n] BINARY-AND (2^m) * f(m, n
MOD 4), m = 0..7)
where f can be tabulated as follows (all values in hex.):
+-----+-----+-----+-----+-----+-----+-----+-----+
m | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+---+-----+-----+-----+-----+-----+-----+-----+-----+
| 0 | 1 | -2 | -4 | 8 | -10 | 20 | 40 | -80 |
n MOD 4 | 1 | -1 | 2 | -4 | 8 | 10 | -20 | 40 | -80 |
| 2 | -1 | 2 | 4 | -8 | 10 | -20 | -40 | 80 |
| 3 | 1 | -2 | 4 | -8 | -10 | 20 | -40 | 80 |
+---+-----+-----+-----+-----+-----+-----+-----+-----+
I deduced this by 'perturbing' various bits at various positions in the
input stream, and saw how the error propagated. The values in the table are
nice (+/-(2^m)) and symmetrical. It works quite nicely for all inputs I
tried (constant and non-constant).
:)
Thanks,
Vlad.
------------------------------
From: "Cristiano" <[EMAIL PROTECTED]>
Subject: Re: arbitrary-precision arithmetic
Date: Fri, 9 Mar 2001 21:16:05 +0100
> What are the different arbitrary-precision arithmetic packages available?
> Which seem to be the best?
I've implemented elliptic curve cryptography with 3 math packages: vlong,
free-LIP v1.1 and miracl.
vlong is a C++ class, miracl is a C/C++ package, LIP is C only.
For speed comparison I ran the *identical* algorithm in a pentium II 450MHz
with winzozz98. The elliptic curve choosen is 160 r1 from "SEC 2:
Recommended Elliptic Curve Domain Parameters" (base point with prime order
of 160 bits). These are the times (in seconds):
vlong LIP miracl
ECKEP 8,684 0,748 0,033 (each user)
ECES 4,307 0,258 0,017 (encryption)
ECES 2,182 0,139 0,009 (decryption)
miracl has many optimizations (also in assembly) especially in elliptic
curves.
Cristiano
------------------------------
From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Re: Really simple stream cipher
Date: Fri, 9 Mar 2001 21:47:18 +0100
"Scott Fluhrer" <[EMAIL PROTECTED]> skrev i meddelandet
news:98bcf2$a9u$[EMAIL PROTECTED]...
>
> Henrick Hellström <[EMAIL PROTECTED]> wrote in message
> news:98b21q$edm$[EMAIL PROTECTED]...
> > Well, I disagree. The user must always rely on the behavior of the
> > application under specific circumstances, regardless of the kind of
> security
> > primitives it implements. A MAC or a signature does not necessarily
reject
> > errors with higher probability than a properly designed and implemented
> > error propagating cipher.
> That is incorrect. A MAC will reject errors with higher probability than
> any error propagating cipher, for the simple reason that error propagating
> ciphers will never reject errors -- they will just (in the best case)
passes
> gibberish to the application.
My English is not perfect, but I believe such remarks could be described as
"hairsplitting". You could just as well say that a MAC will never reject any
errors, because it will only output some code corresponding to the input.
Then the application have to compare that code with the code that was sent
along with the message, and take appropriate action on the basis of the
result of that comparison.
> You may have the view that how applications deal with invalid data ought
to
> be a part of the security model, and so any security review must
necessarily
> consider the application as well. I humbly disagree: a sizable proportion
> of applications are written without any particular cryptographical
> properties in mind, and hence for security reasons, no particular
> cryptographical properties can be assumed.
Hm? Are you talking about layer models, such as SSL, SSH etc? I am talking
about real security applications. I don't readily believe in the concept of
general purpose security, apprioriate for any kind of application.
> > The question is rather which one is most efficient
> > and which one is (from the user's epistemic point of view) most likely
to
> > fail due to poor implementation.
> Since we're talking about security, wouldn't the question as to which one
is
> easier to analyze and is less likely to provide security weaknesses also
be
> a consideration?
Certainly, did you have anything particular in mind?
--
Henrick Hellström [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Re: Really simple stream cipher
Date: Fri, 9 Mar 2001 21:57:02 +0100
"David Wagner" <[EMAIL PROTECTED]> skrev i meddelandet
news:98bd3a$e28$[EMAIL PROTECTED]...
> Henrick Hellström wrote:
> >That's not entirely true. Any message authentication scheme have to have
the
> >application reject faulty data, namely the messages that fail the
> >authentication tests.
>
> No. The application does not reject that data; the crypto layer rejects
> it, before the application ever gets a chance to see it. Any data
returned
> by the crypto layer is guaranteed to have been covered by a valid MAC, if
> you have a well-designed crypto engine.
I don't suggest that such layers ought to be used for special purpose
applications. But you could easily implement a "crypto engine" that would do
the same thing for you, using an error propagating cipher: Append an
encrypted string of zeroes to the end of the message, instead of a MAC. If
the message is not decrypted into plain text with a string of zeroes at the
end, then it is rejected.
> >Furthermore, many kinds of client/server system (pop, smtp, http, dns,
> >telnet, the ftp command channel, etc) have to check for faulty data
anyway,
> >because they are expecting a strictly formatted input.
>
> But this is not a *security* condition, and so they should not, IMHO, be
> trusted to reliably get it right in the face of adversarially-chosen
inputs.
Oh, but *is* a security condition, in so far that the server should
terminate the connection in case of any such error. Otherwise a malicious
hacker might cause the server to crash, e.g. by sending an infinite line of
random character without any line break.
--
Henrick Hellström [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Tempest Systems
Date: Fri, 09 Mar 2001 22:11:02 +0100
Steve Portly wrote:
>
> You would think that an adversary could distinguish the location of a noise
> generator from the true location to be monitored given sufficient time
> discrimination.
Dumb question: What are the major activities of a computer
that could be well monitored through electromagnetic
emanations? Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Date: 09 Mar 2001 21:35:36 GMT
Subject: Bell Systems Technical Journal
I just heard from the editor, Fran Grimes, of
the Bell Systems Technical Journal today. She
writes: "We will post Shannon's "Communications
Theory of Secrecy Systems. It should be up
sometime next week."
Right now the only version of this paper on the
web that I know of is in a horrible
image format.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Fri, 09 Mar 2001 13:52:23 -0800
Benjamin Goldberg wrote:
>
> Anthony Stephen Szopa wrote:
> >
> > Troed wrote:
> > >
> > > Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> > >
> > > >This is a personal use program for windows. I think it is fair to
> > > >say this program is for and intended for a non multitasking
> > > >environment.
> > >
> > > It's for Windows 3.x only? Windows 95 and up are pre-emptive
> > > multitasking - or what are you talking about?
> > >
> > > >Take a look at my floppy disk test results I just posted. They
> > > >seem to cramp everything pretty much all the detractors have been
> > > >saying.
> > >
> > > Floppy != Harddrive
> > >
> > > ___/
> > > _/ - Software Engineer working in the development of operating
> > > systems
> >
> > You should not have other programs running at the same time as you
> > are running the OverWrite program that will be making demands on the
> > system such that the overwrites to the hard drive will be delayed by
> > competition from these other programs for system resources. You
> > don't want to be running multiple tasks or programs while the
> > OverWrite program is running if at all possible.
>
> If your algorithm is designed properly, that should not make a
> difference.
>
> --
> The difference between theory and practice is that in theory, theory and
> practice are identical, but in practice, they are not.
Catch 22!!!
You've been all telling me that there is no way to design the
program properly to make sure 100% of the time that the physical
overwrites are taking place because of optimizations built in to the
Windows OS.
Now you are telling me that it can be done. Are you taking both
sides?
I have attempted to make the overwrites take place by allowing
enough time between subsequent calls to the write and fclose
functions in each pass so that the OS will make these overwrites.
The overwrites should physically take place as long as there are not
other competing physical writes such that any subsequent write and
fclose instructions are processed before the prior overwrite has
had a chance to physically take place.
I believe this was the issue.
This is why I recommend that other programs not be running.
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Fri, 09 Mar 2001 22:05:16 GMT
Anthony Stephen Szopa wrote:
> Benjamin Goldberg wrote:
> >
> > Anthony Stephen Szopa wrote:
> > >
> > > Troed wrote:
> > > >
> > > > Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> > > >
> > > > >This is a personal use program for windows. I think it is fair to
> > > > >say this program is for and intended for a non multitasking
> > > > >environment.
> > > >
> > > > It's for Windows 3.x only? Windows 95 and up are pre-emptive
> > > > multitasking - or what are you talking about?
> > > >
> > > > >Take a look at my floppy disk test results I just posted. They
> > > > >seem to cramp everything pretty much all the detractors have been
> > > > >saying.
> > > >
> > > > Floppy != Harddrive
> > > >
> > > > ___/
> > > > _/ - Software Engineer working in the development of operating
> > > > systems
> > >
> > > You should not have other programs running at the same time as you
> > > are running the OverWrite program that will be making demands on the
> > > system such that the overwrites to the hard drive will be delayed by
> > > competition from these other programs for system resources. You
> > > don't want to be running multiple tasks or programs while the
> > > OverWrite program is running if at all possible.
> >
> > If your algorithm is designed properly, that should not make a
> > difference.
> >
> > --
> > The difference between theory and practice is that in theory, theory and
> > practice are identical, but in practice, they are not.
>
> Catch 22!!!
>
> You've been all telling me that there is no way to design the
> program properly to make sure 100% of the time that the physical
> overwrites are taking place because of optimizations built in to the
> Windows OS.
Hardly.
There is no platform-independent mechanism able to make the desired
guarantee. Some platforms have specific features that allow for the support
of the guarantee.
>
> Now you are telling me that it can be done. Are you taking both
> sides?
Yes. They are two separate coins.
>
>
> I have attempted to make the overwrites take place by allowing
> enough time between subsequent calls to the write and fclose
> functions in each pass so that the OS will make these overwrites.
>
> The overwrites should physically take place as long as there are not
> other competing physical writes such that any subsequent write and
> fclose instructions are processed before the prior overwrite has
> had a chance to physically take place.
>
> I believe this was the issue.
No.
The issue was the non-trivial nature of the problem. Your approach was
simplistic and thus not able to provide the assurance you claimed it could.
This appears to be a consistent property of the software you write. Perhaps
you would be happier with a different hobby?
------------------------------
** 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
******************************
