Cryptography-Digest Digest #907, Volume #13 Thu, 15 Mar 01 16:13:01 EST
Contents:
Re: An extremely difficult (possibly original) cryptogram (Jim Gillogly)
Re: An extremely difficult (possibly original) cryptogram (Jim Gillogly)
Computing power in the world (AirBete)
Secure overwriting (David Hopwood)
Re: Text of Applied Cryptography .. do not feed the trolls (David Hopwood)
Re: SSL secured servers and TEMPEST ("Lyalc")
Re: ANSI X9.17 Key Generation and Alternatives ("Lyalc")
Re: primes for BBS ([EMAIL PROTECTED])
Re: The Art of Cryptography (was: Super strong crypto) (Mok-Kong Shen)
Re: How to eliminate redondancy? (Mok-Kong Shen)
----------------------------------------------------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Crossposted-To: rec.puzzles
Subject: Re: An extremely difficult (possibly original) cryptogram
Date: Thu, 15 Mar 2001 11:43:18 -0800
daniel mcgrath wrote:
> Seriously, for anyone who is actually interested in breaking my
> cryptogram, I'll say that it contains the phrase "Eppur si muove". (I
> was hoping that Jim Gillogly would be interested and respond to my
> posting.)
>
> Here is a shorter message that is (basically) in the same code:
>
> 34619 24112 61612 20346 69455 75457 12060 11296 67744 12504
> 63708 94452 04025 04608 14435 61402 04608 04137 57610 09465
...
> 56460 20460 89100 85426 85761 00804 03709 01614 40955 50413
> 85764 55204 03579 24137 53706 012
>
> ..... tysoizbyjoxs ... good luck
> ... daniel mcgrath
Perhaps it would be worth reviewing the bidding and hintage from the
previous time Daniel was trying for feedback on this cipher.
1. I noted that there were lots of long repeats at odd intervals,
suggesting that it's basically a substitution cipher, but not with
strict dinomes or any other fixed-length character substitution.
2. In most of the ciphers Daniel's posted, the dinomes 98 and 99 do
not occur. 99 occurs a few times in the long one posted recently,
but 98 is still unrepresented.
3. The first two observations suggest something like a monome-dinome
system, where some digits may indicate that following digits represent
less common letters, rather like a Huffman code.
4. It's probably not homophonic, since if it were we wouldn't expect
such long identical repeated strings -- at some point a homophone
would be chosen in the middle.
5. Daniel responded to these observations, saying
OK, I will tell you that, of the ten digits, six of them behave one
way, while the other four behave a different way. And the "plaintext"
is really a sort of code to begin with.
...
The code that the plaintext is in, however, is something that we all
know. It is an important thing these days.
The first hint is consistent with my monome-dinome hypothesis, and the
second hint could mean something like HTML.
6. Daniel gave a big clue, as follows:
You came 620711143 close with 54006 of the 806648
first hypotheses 711015 you had 450103. The code
696690137 used here, 27465680662, is based 7774
the same 20650362042 idea as 71112 system used
1743 my cryptograms.
7. He further said:
The system used is one of changing bases (base 10 is derived from
another base).
Internally, it's all binary (base 2).
I would think that #6 and #7 should be enough. All the ciphers are in
the same key (assuming it's keyed), since they have long common strings.
Evidently 620711143 means very or fairly or rather or something like that.
54006 probably means "one".
806648 may mean "very".
711015 may mean "that".
450103 may mean "made".
696690137=?
7774 probably means "on".
20650362042 may mean "basic" or "fundamental".
71112 = "the"?
1743 = "in"?
With this base conversion going on, we should probably simply unleash
Bill Shaw on it and watch it crumble.
--
Jim Gillogly
Highday, 23 Rethe S.R. 2001, 19:24
12.19.8.0.19, 6 Cauac 2 Cumku, First Lord of Night
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Crossposted-To: rec.puzzles
Subject: Re: An extremely difficult (possibly original) cryptogram
Date: Thu, 15 Mar 2001 12:07:19 -0800
Oh, another note: "100" is very common, and may well represent
a sentence break, such as a period followed by two spaces or
some such thing. "300" also occurs (rarely), but 00 is preceded
by no other digit.
--
Jim Gillogly
Highday, 23 Rethe S.R. 2001, 20:05
12.19.8.0.19, 6 Cauac 2 Cumku, First Lord of Night
------------------------------
From: AirBete<[EMAIL PROTECTED]>
Subject: Computing power in the world
Date: Thu, 15 Mar 2001 20:09:54 GMT
Hi all,
What is the up-to-date estimate of the total computing power in the world in
mips-years?
In 1994 (Odlyzko), it was beleive that the total computing power in the world
was 3 x 10^8 mips-years. A safe estimate for the next 20 years was then between
10^10 - 10^11 mips-years. This is why 10^12 mips-years was considered to be
infeasable. But what about today and what is the forecast for the next 20 years?
Thanks.
AirBete.
------------------------------
Date: Thu, 15 Mar 2001 03:52:21 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Subject: Secure overwriting
=====BEGIN PGP SIGNED MESSAGE=====
[alt.hacker removed from Newsgroups]
Eric Lee Green wrote:
> There's another issue regarding overwriting blocks: Whether blocks are
> re-used or not depends upon the filesystem. The Windows filesystem
> will reuse the same blocks for the file. The traditional Unix and Linux
> filesystems will reuse the same blocks for the file. However, the Reiser
> filesystem, and probably NTFS (since NTFS also claims to be a transactional
> filesystem), will *NOT* reuse the same blocks for the file.
NTFS is not a fully transactional filesystem; it only guarantees
transactional behaviour for file metadata. I think the rationale was
that given this level of transaction support, it is possible for an
application to implement full transactions on top, albeit somewhat
klunkily and inefficiently. Needless to say, such fine distinctions
don't register with Microsoft's marketing department.
[...]
> Now, assuming that you're using a filesystem that reuses blocks when
> you write to an already-existing file in r+a mode
You mean "r+b"; "r+a" would append to the end of the file.
> (i.e., you're *NOT*
> using Windows NT or Windows 2000 with an NTFS filesystem): there is a
> call on Unix called 'fsync', which supposedly guarantees that all
> blocks currently in the buffer cache will be flushed out to disk
> before 'fsync()' returns.
I believe (although this is not based on definite observation), that when
compression is not enabled, NTFS will reuse the same blocks for a file
opened in "r+b" mode (or the Win32 API equivalent, which it's probably
better to use in this case).
> Since I am not a Windows programmer, I do
> not know whether Windows has a similar call, and if so, what it is
> named. Use of 'fsync()' or its Windows equivalent would thus be needed
> to flush your buffer cache between your passes over the file.
fsync does not seem to exist in the MSVC++ 6 run-time library.
The Win32 API equivalent appears to be 'BOOL FlushFileBuffers(HANDLE)'.
> But even that may not be enough. To whit:
[snip description of system with RAID-5 controller and 1 MByte cache]
> Now, there does exist a BIOS
> call on this beast to force it to flush its internal buffer. But you
> must first know that a) this beast is connected, and b) how to call
> that BIOS call. Right now, the Linux driver for this card, when its
> "shutdown" routine is called (when the system is shutting down), knows
> how to call this BIOS call (so that all data gets written to the disk
> at shutdown), but a normal "fsync()" call doesn't touch it, because
> the buffer cache knows nothing about the underlying hardware (that's
> the driver's job).
IMHO, fsync should be asking the buffer cache to ask the driver to
force a hardware flush. That it doesn't, I would consider a bug.
However, there is not much that an application-level overwriting
program can do to work around this, or similar situations. That is one
reason why secure overwriting should be supported in the OS, rather
than at the application level. Even if it is possible for an application
to work around this kind of problem, it can only do so by reaching down
into structures that should really be private to the OS (which has
negative implications both for security, and compatibility in case
those structures need to be changed).
> Then finally, the SCSI hard drive has its own internal cache. The SCSI
> hard drive may be entirely inaccessible, though. For example, the
> ICP-Vortex card works by making the three to five drives of a RAID-5
> array look, to the operating system, as if they were a single SCSI
> hard drive. SCSI commands that the operating system tries to send to
> that "fake" hard drive are intercepted by the ICP-Vortex controller,
> and it does what it thinks are appropriate with them. Thus you have no
> way of actually going into individual SCSI hard drives and turning off
> their disconnect or their caching.
The SCSI command to the Vortex controller to flush its buffers, should
also cause it to send flush commands to each of the drives. If it
doesn't, that is a bug in the Vortex controller: it is not correctly
implementing the SCSI specification.
The underlying problem, though, is that there are at least 3, and possibly
up to about 8 layers (in the case of a remote RAID drive or similar)
through which a flush command must pass in order to cause a write to
some physical media. If *any* of those layers do not pass on the command,
the write will not actually happen - and since flush commands have no
easily observable effect, there is a temptation to simply ignore them at
each layer. The implementors of some layers may not even see this as a
bug, although it clearly is.
> >Do you have any thoughts on this since this is going for the issue's
> >jugular?
>
> My thought is that on Windows 9x you can probably get by with the
> Windows equivalent of the 'fsync()'.
I'm not sure about that - does anyone with a better knowledge of Windows
internals know *precisely* what 'FlushFileBuffers' does? I frankly don't
trust the MSVC++ documentation, from bitter experience.
[snip]
> My basic thought: Eventually, everything is going to Windows 2000 or
> Linux and to transactional filesystems such as NTFS or Reiser FS. So
> in the long run, it becomes impossible to securely erase data.
The OS should support erasing a file, and/or marking a file as
'sensitive' as a system call, which should tell the driver(s) to
do the right thing at the IDE/SCSI/whatever level. Also, the virtual
memory subsystem should be designed to allow secure overwrites of
sensitive memory blocks. That's the only way to reliably ensure that
data can be erased.
An encrypted filesystem does not in itself solve the problem; one of the
purposes of erasing data is to prevent it from being recovered even when
everything else is compromised. That can happen in any number of ways
that don't involve direct cryptanalysis: dictionary attacks against
passwords, exploiting bugs in the OS or application software, rubber
hose methods, etc. In particular, relying on data being encrypted, rather
than erasing it, is not sufficient to achieve forward secrecy, which I
believe is an important goal in practice.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOrA7nzkCAxeYt5gVAQHL0gf/XpMbM47sGsbOYB7Xed7lBmbVXj2dy3m7
guqty4QxAFfEVGwk+zmPK/2IJcd1GTldxXVDghv3JG2MgzfJZU5T0faHSn+c7OLU
fISCCbRJQmkdXkmxFknk8s/TG0RxqhiQMHvxQr8u5Bh3anrEyUpAjJKcrfyzF64k
QNB3G71YvPv814xTSpx764dueQcHQvhoOrUlp1aRFeCuHbDdJ4E024zVLeKkdeNI
ej0D9yOmn9/ovOc7jkf+lxl6M6z/AJW50DSjbVZLN8ID92Qk04BHgHeK7xfJP/uU
ZYnj+p6PpNzToatffECmhxMi196vMLF/Bg0GYaQmcoiDsXfrpEyYAA==
=8has
=====END PGP SIGNATURE=====
------------------------------
Date: Thu, 15 Mar 2001 03:54:47 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Subject: Re: Text of Applied Cryptography .. do not feed the trolls
=====BEGIN PGP SIGNED MESSAGE=====
dlk wrote:
> On 3/10/2001, 7:37:38 PM, "Tom St Denis" <[EMAIL PROTECTED]> wrote
> <snippage>
>
> > I dunno who wrote the code in the back of Applied crypto
LOKI91, IDEA, 3-Way, RC5, and SEAL are based on the reference implementations
by the algorithm designers or their companies. I don't know who wrote the
A5 implementation, but DES, Blowfish, and (I think) GOST are by Eric Young.
The code should really have been properly attributed, though.
> > BUT IT SUCKS!.
> > It's the most sloppiest poorly written code I have ever seen. My blind
> > dog with only three legs (that we call "tripod") can write better code
> > by randomly typing keys on the keyboard.
>
> That's because it's function is not to be working or elegant code
> but to be clear, easily understood code that models the given algorithm.
How could it be that, without working or being elegant?
In any case, most of the AC code is not particularly clear or easily
understood - it is non-portable (including byte order, alignment, and
type size problems), and does not use any consistent API or coding
conventions. It's also partially optimised (hence not ideal for
understanding the structure of some of the algorithms, but not very
*well* optimised, either). The code for some of the algorithms checks
test vectors, but in a haphazard fashion that would not be expected to
catch several kinds of common problem. Finally, the Blowfish
implementation doesn't compile, and some of the non-portable assumptions
are arguably bugs.
It's *not* the sloppiest, most poorly written code I've ever seen (not
by a long chalk), but it is pretty bad. There are only two mitigating
factors:
- including the code in a published book played a significant part in
pointing out the absurdity of the US export restrictions,
- at the time the first edition was published, free crypto libraries
weren't available (except an early version of SSLeay, which I think
was where the DES, GOST and Blowfish code came from?)
Today, someone wanting to obtain cipher or message digest code in C would
be much better advised to use something like Crypto++ or OpenSSL (which
has improved quite a bit since that version of SSLeay).
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOrACNDkCAxeYt5gVAQE69wf+LyLtBaOU0IRBTmiFQ9nLOZfTtyjjePn5
YnjMQiggRt/oRlzkUI3ZLNX8WraBaXVIArCNCRt3wyYx9wg3wF5Vu2AZtWy23Wvo
t0Ok+AUfhEmvqzMxppSVfqycU42y3qFEO0lBsQ7etPnhZP2BrRxg/TkWOr2XD4PN
GLje3REgpc8+UuTlrTrERdiSTKerAnNANoepjP3cIjE6xkOlxhpr/PN7dBPN+tNF
VLIyJWvYfErftmgLO25PrGLH0v+9ZApPFPMFEPMragOmwurvKR79PfNl/34DXIfb
djjQMZltXJ4m34sluGTDG9ecNNI6Fojbw+lvbZkA92g8JQruGaUTQQ==
=oYMn
=====END PGP SIGNATURE=====
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: SSL secured servers and TEMPEST
Date: Fri, 16 Mar 2001 07:10:10 +1100
Look at the cryptome site, where copies of the released portions of the
TEMPEST standards, NACSEM 5100 et al reside.
Not much useful material.
Minimum idea is that the signal needs to be above the noise floor in it's
bandwdith required for detection. Do the math for noise floor at the
bandwidth in question assuming, say a standard 50 ohm antenna/sensor
impedance, 20 deg room temperature.
Basically this used as the TEMPEST benchmark, with subtle, minor variations.
In effect most modern COTS equipment/components are not any issue at a
distance greater than 20m, while the TEMPEST spec works on a test distance
of 1m. If you can maintain a perimeter of 20m where it would be difficult
to site a sensor, then your confidence should be higher. Your paranoia is
your choice.
Lyal
Frank Gerlach wrote in message <[EMAIL PROTECTED]>...
>Lyalc wrote:
>>
>
>> - is very unpredictable, timing wise. But a variaton of the Kocher
timing
>> attacks might/might be theorised as feasible - by careful analysis of SSL
>> handsaking start times etc. But I think (without empirical evidence)
that
>> multi-tasking OSs will be too unreliable, timing wise. Any comments out
>> there?
>I also thought about that and was somehow relieved, although my attack
>does not work as easy any more :-(
>Still, variations might only increase the "search space" for the signal
>processors.
>
>> - assume the emanations can be detected at all. Most cpus don't emanate
>> enough to be above the themal noise floor. n is proportional to KTBR -
with
>> a CPU clock and thus bandwidth of say 500Mhz, the noise floor is pretty
>I think the discussion should be limited to special crypto coprocessors
>in (some more or less shielding)faraday cage. This is what most
>high-traffic sites use (that is because they want to take load off the
>CPU).
>I looked briefly at FIPS 140-1, but could not find anything related to
>TEMPEST (EMI/EMC has nothing to do with TEMPEST). I'll look at it in
>more detail tonight..
>It would be usefuly to have some certification measurement procedure,
>like "emanations from x to y Mhz must be below z dB".
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: ANSI X9.17 Key Generation and Alternatives
Date: Fri, 16 Mar 2001 07:12:23 +1100
Hash them together to preclude working backwards if one piece is
compromised.
Bjorn Forsberg wrote in message <[EMAIL PROTECTED]>...
>I have a blob of data to encrypt and persist to a file system for long
>term storage.
>
>I have a master key (fixed). I generate the actual encryption key for
>the data from the master and a piece of data stored with the blob on the
>file system. This piece of data is HMAC'd and included in the ciphertext
>so it can be relied upon.
>
>I use an algorithm like ANSI X9.17 to generate the encryption key from
>the master. However, this process involves two encryption operations
>itself and is hence very expensive in an environment were the number of
>encrypts/decrypts may be high.
>
>Given that, are there other published methods of generating a key from a
>master that are secure yet less expensive? I mean, I could simply xor
>the master key with the piece of data from the blob to get my encryption
>key and save those two extra encryption operations. But am I exposing
>myself to some sort of attack?
>
>Hardware is not an option at this time.
>
>Thank you.
>
>Bjorn Forsberg
>Roaring 30s
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: primes for BBS
Date: 15 Mar 2001 12:16:04 -0800
Benjamin Goldberg <[EMAIL PROTECTED]> writes about BBS:
>
> Note that p, q, don't just have to be primes, they have to be *special*
> primes (specifically "Blum integers" which are prime, aka "Blum
> primes"), and when picking a starting value for x, you have to make sure
> that it does not produce a short cycle.
All true until the last part. You don't have to check that x doesn't
produce a short cycle. If you ever find an x that produces a short
cycle, you have cracked RSA and factored a 1024 bit modulus! If you
believe that RSA with a 1024 bit modulus is secure, you don't have to
check for short cycles. If short cycles can be found, RSA is insecure.
Alpha
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: The Art of Cryptography (was: Super strong crypto)
Date: Thu, 15 Mar 2001 21:52:58 +0100
John Savard wrote:
>
[snip]
> The question that would be very *nice* to be able to answer about both
> of these systems, with their bandwidth costs, is whether (for the
> brute-force infeasible case, so the meet-in-the-middle attack is not a
> concern) they have an advantage over double encryption.
Just some tiny remarks: It is my impression that such basic
or general questions in crypto could barely be settled
entirely objectively for any concrete applications, let
alone for general situations. The word 'Art' in the title
line of the post in fact implies that subjectivity (which
varies from person to person) plays a non-trivial role.
It's fine that in some treatments of crypto issues one
succeeds to apply mathematical tools but unfortunately one
apparently can't utilize as much math as one would have
otherwise desired. In my humble view this is not much
different in engineering disciplines, where nowadays
much numerical mathematics are employed but one is
nevertheless dependent on pretty amount of sound judgements
of experienced engineers.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: How to eliminate redondancy?
Date: Thu, 15 Mar 2001 22:03:19 +0100
br wrote:
>
> I'm trying to find any document about how to eliminate the redondancy of
> english language (except compression algorithm).
> Is there any work about this question?
Writing in the 'telegram style' could correspond to
your need, I suppose.
M. K. Shen
------------------------------
** 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
******************************
