Cryptography-Digest Digest #676
Cryptography-Digest Digest #676, Volume #13 Sun, 11 Feb 01 15:13:00 EST
Contents:
Re: Scramdisk, CDR and Win-NT (Darren New)
Re: Steganography with ASCII text files (Mok-Kong Shen)
Re: Steganography with ASCII text files (Mok-Kong Shen)
Re: ideas of D.Chaum about digital cash and whether tax offices are ("Thomas J.
Boschloo")
Re: ideas of D.Chaum about digital cash and whether tax offices are ("Thomas J.
Boschloo")
Re: CipherText patent still pending (Mok-Kong Shen)
Re: Steganography with ASCII text files (JPeschel)
Re: OverWrite freeware completely removes unwanted files from hard drive (Hit1Hard)
Re: Steganography with ASCII text files (Benjamin Goldberg)
Re: Anonymous communications (Benjamin Goldberg)
WiSCy99 v4.24 Calculator/Graph Suite (Windows'95/98/NT/2000) is the complete
and-to-use scientific calculator. ("Igor Evsikov")
Re: Steganography with ASCII text files ("John A. Malley")
Re: Anonymous communications (Splaat23)
From: Darren New [EMAIL PROTECTED]
Crossposted-To: alt.security.scramdisk
Subject: Re: Scramdisk, CDR and Win-NT
Date: Sun, 11 Feb 2001 18:14:15 GMT
Daniel James wrote:
You should be aware that this doesn't give you a normal CD-formatted disk -
you'll only be able to read it on machines that have suitable software (i.e.
a copy of DirectCD).
AFAIK, the ability to *read* these disks comes (at least) with Win98.
There's also an option to put an ISO9660 header on the disk to change it
into a "normal" read-only format, but I imagine that could seriously mess up
scramdisk.
It's also not germane to OP's question, as he says he is using CD-R not
CD-RW, and his disks will most definitely be read-only.
This works on CD-R's too. You just don't get space back when you delete a
file.
--
Darren New / Senior MTS Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
Ignorance can be cured. Naivety cures itself.
--
From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: Steganography with ASCII text files
Date: Sun, 11 Feb 2001 19:15:27 +0100
JPeschel wrote:
Mok-Kong Shen [EMAIL PROTECTED] writes, in part:
Modern steganography is commonly done on graphical files
through manipulation of pixel values. The operations done
are in my humble view not very convenient to implement and
require, above all, the availability of graphical files.
What's difficult about finding graphical files, or, for that matter, audio
or video files?
We note that in general the sender will not send the HTMLfile but publish his
document at a site such that the receiver can access and get a copy of the
HTML file at his convenience, thus rendering it easier for the latter to keep
his anonymity.
If the sender has web access, he should be able to find plenty
of files (graphical, audio, or video) suitable to use as carriers.
It is a relative matter. At least in my personal case,
I have plenty of text files ready for use and don't
need to get these other files. What I find is more
inconvenient with graphical files is either to have to
get those algorithms to process or have to implement them
myself, while what I suggested is very elementary so that I
could easily start from scratch (composing my own cover
text) and be entirely independent of other people.
M. K. Shen
--
From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: Steganography with ASCII text files
Date: Sun, 11 Feb 2001 19:15:35 +0100
"John A. Malley" wrote:
[snip]
From a security viewpoint, the more people know about this means, the
easier it gets to monitor the means - "Eve" could patrol web sites with
'bots to download and autoscan the HTML files for hidden messages.
You are certainly right in principle. However, I think
the situation is 'proportionately' unfavourable to Eve,
for the volume of informations on the internet, and with
it the subset of HTML materials, is growing at an almost
incredible speed, so that scaning would be barely possible
(the attack involves dealing with the PRNG or its eqivalents
and means at least some non-trivial computing work). This is
similar to the hypothetical scenario where everybody on the
internet encrypts all his e-mails such that Echelon-like
apparatus would be bogged down due to the sheer volume
of work load, I believe.
M. K. Shen
--
From: "Thomas J. Boschloo" [EMAIL PROTECTED]
Crossposted-To: sci.crypt,talk.politics.crypto,alt.cypherpunks
Subject: Re: ideas of D.Chaum about digital cash and whether tax offices are
Date: Sun, 11 Feb 2001 19:08:54 +0100
"Trevor L. Jackson, III" wrote:
"Thomas J. Boschloo" wrote:
I am not talking about a one grand GPS bullet or some other form of
smart bullet. Ju
Cryptography-Digest Digest #676
Cryptography-Digest Digest #676, Volume #12 Wed, 13 Sep 00 23:13:01 EDT
Contents:
Re: MIRACL ("bubba")
Re: security of SKID based msg authentication. ("Scott Fluhrer")
Re: Disappearing Email redux (Tommy the Terrorist)
From: "bubba" [EMAIL PROTECTED]
Subject: Re: MIRACL
Date: Thu, 14 Sep 2000 02:35:45 GMT
I was able to build factor.exe with M$ VC6.
Ignore the warnings for now. You are closer
than you realize. It looks like I had to edit
mr87v.c and mrmuldv.c.
"Soeren Gammelmark" [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
First I tried to run BC32DOIT.BAT directly from the /lib directory but
the compiler couldn't find the source code (MRCORE.C etc...), so I
copied the batch-file to the /source directory. When I run the batchfile
there the compiler compiles the majority of the files, however, when it
compiles mrmuldv.c (I've chosen the standard one, because I belive it
fits my compiler and computer)
Here is some of the error/warningmessages I get:
Warning MRCORE.C 335: Condition is always false in function brand
Warning MRCORE.C 337: Unreachable code in function brand
Error: Unable to execute command 'tasm32.exe'
Warning mrmuldv.c 19: Function should return a value in function muldiv
Warning: '*.OBJ' file not found, where * is multiple files (e.g.
mrmonty.obj)
Error: Unresolved external '*' referenced from module file.CPP, where *
is quite a bit of functions, and file.CPP is BRENT.CPP,
BIG.CPP,MRIO2.C,MRPRIME.C, MRXGCD.X, MRPOWER.C and so on...
It is clear to me that the final bundle of errormessages (unresolved
external...) is the result of the previous warnings and errors.
SG
"Douglas A. Gwyn" wrote:
Soeren Gammelmark wrote:
When I try to run the BC32DOIT.BAT to create the
library I get tons of error messages.
The content of the error messages, especially the first few,
should provide a clue as to what is wrong.
Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International
MRCORE.C:
Warning MRCORE.C 335: Condition is always false in function brand
Warning MRCORE.C 337: Unreachable code in function brand
Warning MRCORE.C 361: Condition is always false in function brand
Warning MRCORE.C 363: Unreachable code in function brand
Warning MRCORE.C 830: 'mr_mip' is assigned a value that is never used in
function mirexit
Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International
MRARTH0.C:
Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International
MRARTH1.C:
Error: Unable to execute command 'tasm32.exe'
Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International
MRARTH2.C:
Error: Unable to execute command 'tasm32.exe'
Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International
MRALLOC.C:
Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International
MRSMALL.C:
Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International
MRIO1.C:
Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International
MRIO2.C:
Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International
MRGCD.C:
Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International
MRJACK.C:
Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International
MRXGCD.C:
Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International
MRARTH3.C:
Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International
MRRAND.C:
Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International
MRPRIME.C:
Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International
MRCRT.C:
Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International
MRSCRT.C:
Warning MRSCRT.C 79: Restarting compile using assembly in function scrt
Error: Unable to execute command 'tasm32.exe'
Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International
MRMONTY.C:
Error: Unable to execute command 'tasm32.exe'
Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International
MRPOWER.C:
Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International
MRCURVE.C:
Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International
MRFAST.C:
Warning MRFAST.C 179: Restarting compile using assembly in function
mr_dif_fft
Error: Unable to execute command 'tasm32.exe'
Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International
MRSHS.C:
Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International
MRAES.C:
Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International
MRSTRONG.C:
Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International
MRLUCAS.C:
Borland C++ 5.2 for Win32 Copyright (c) 1993, 1997 Borland International
MRBRICK.C:
Cryptography-Digest Digest #676
Cryptography-Digest Digest #676, Volume #11 Mon, 1 May 00 06:13:01 EDT
Contents:
Re: How would a 15 year old start? (Diet NSA)
Re: What is the strongest encryption rate so far possible/achived? ("Scott Fluhrer")
Re: Autocorrelations ("Marty")
Re: Autocorrelations (Mok-Kong Shen)
Re: Joystick as RNG (Mok-Kong Shen)
Re: Another naive question (Mok-Kong Shen)
Re: about search and seisure of computers again (Mok-Kong Shen)
Re: Command Line Cypher? ("DD")
Re: Intel drops serial number (Vernon Schryver)
Re: sci.crypt think will be AES? (Vernon Schryver)
Re: Intel drops serial number (David Formosa (aka ? the Platypus))
Re: Command Line Cypher? (Richard Heathfield)
Re: U-571 movie (Nick Barron)
Re: Sunday Times 30/4/2000: "MI5 builds new centre to read e-mails on the net" (Nick
Barron)
Subject: Re: How would a 15 year old start?
From: Diet NSA [EMAIL PROTECTED]
Date: Sun, 30 Apr 2000 22:20:25 -0700
In article
js4ogsso9q3ro049lfdle7744gko392o4h@4
ax.com, Andy Dingley
[EMAIL PROTECTED] wrote:
Like many software geeks (non-crypto), I trained as a
physicist. In
the last decades I've only twice felt a lack of comp sci
background,
and they were minor. OTOH, the serious crypto people I work
with all
have a maths degree (and doctorate) behind them, not comp sci.
Quite a few of the greatest breakthroughs
ever in the history of IT were made by
people with a physics background.
Currently, most, and perhaps all, of the
(leading) researchers in quantum
computing crypto have some kind of
training in physics (and may not have
degrees in math or cs). If you are willing
to think of crypto broadly then you might
want to check out the employment section
of the NSA's website to see that they are
interested in hiring people from a variety
of different areas- electronics, AI, etc.
" V hfdt afogx nfvw ufo axb (o)(o) " - Gtnjv
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
--
From: "Scott Fluhrer" [EMAIL PROTECTED]
Subject: Re: What is the strongest encryption rate so far possible/achived?
Date: Sun, 30 Apr 2000 23:10:47 -0700
Monolo [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Just curious? Anyone know?
Assuming you are asking about the fastest encryption algorithm that is
generally believed secure (that is, has been published, and has no results
published against it), and assuming you are asking about performance on a 32
bit processor, that would be Seal 3.0, which runs somewhere around 4
cycles/byte on most modern 32 bit processors.
Warnings: Seal is patented by IBM, and we're talking about bulk encryption
speed -- its key expansion is a *bear*.
--
poncho
--
Reply-To: "Marty" [EMAIL PROTECTED]
From: "Marty" [EMAIL PROTECTED]
Subject: Re: Autocorrelations
Date: Sun, 30 Apr 2000 22:34:13 -0700
"Perfect" autocorrelation is a property of primitive Galois polynomials
which are notoriously poor for encryption as OTP's.
Good crypto will produce the same auto and cross correlations as random
number sources. This might be described as necessary but insufficient.
-Marty
Mok-Kong Shen [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Real bit sequences encountered in crypto are never perfect and
hence have autocorrelations to more or less extent. Thus I think
the following question may be of interest:
If one has autocorrelations of X_t and of Y_t and also the
crosscorrelations of X_t and Y_t, can one obtain something
useful (quantitative or qualitative) about the autocorrelations
of X_t + Y_t?
Thanks in advance.
M. K. Shen
--
From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: Autocorrelations
Date: Mon, 01 May 2000 10:14:24 +0200
Marty wrote:
"Perfect" autocorrelation is a property of primitive Galois polynomials
which are notoriously poor for encryption as OTP's.
Good crypto will produce the same auto and cross correlations as random
number sources. This might be described as necessary but insufficient.
But it might under circumstances be beneficial to obtain sequences that
have
somewhat reduced autocorrelations. I conjecture that in most cases the
autocorrelations of X_t + Y_t will be better than those of X_t and Y_t.
However, that's pure intuition. I have nothing to substantiate that.
M. K. Shen
--
From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: Joystick as RNG
Date: Mon, 01 May 2000 10:14:29 +0200
Tom St Denis wrote:
It's a "gravis-gamepad"... What I do now is take X samples (sample =
y_axis xor x_axis) (where X = 32) and xor them together. With 20,000
Cryptography-Digest Digest #676
Cryptography-Digest Digest #676, Volume #10 Fri, 3 Dec 99 17:13:02 EST
Contents:
Re: NSA should do a cryptoanalysis of AES (Eric Lee Green)
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: How can you tell? ("Douglas A. Gwyn")
Re: What part of 'You need the key to know' don't you people get? ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES (Eric Lee Green)
Re: NSA should do a cryptoanalysis of AES ("karl malbrain")
Re: Peekboo Ideas? Question ... ([EMAIL PROTECTED])
Re: cookies ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: cookies ("karl malbrain")
Re: NSA should do a cryptoanalysis of AES ("karl malbrain")
From: Eric Lee Green [EMAIL PROTECTED]
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Fri, 03 Dec 1999 14:02:07 -0700
"SCOTT19U.ZIP_GUY" wrote:
In article [EMAIL PROTECTED], "Brian Gladman"
[EMAIL PROTECTED] wrote:
Jim Gillogly [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Keith A Monahan wrote:
My concern is that if they DID break one of the algorithms and
didn't tell us(or NIST) about it. I don't know how likely that
is, but it is certainly a possible case.
It wouldn't be _as_ bad as if the NSA broke it, told us about it,
but didn't tell us how. That would still keep me wondering, but
at least we'd know the cipher isn't secure. Even without telling
us how they did it, we might be able to draw some conclusions about
ciphers of that same nature.
If they say they broke it and demonstrate that they can break an
arbitrary challenge, then I agree that's useful information. If
they say they have an attack that reduces a 128-bit keyspace to
a 70-bit keyspace, I'd want to see the attack before making a
decision to eliminate the candidate. Sorry if this appears paranoid,
but we must always remember that NSA has two responsibilities: to
read traffic, and to protect US infrastructure (mainly military).
If you're going to accept their help uncritically, you'd better
know which side of the house is giving it to you. There's no
question that they could provide valuable insight on the candidates;
the only question is how they can convey it credibly.
As others have said, those that distrust NSA are not going to be swayed by
their arguments but for those of us who believe that they are a force for
good in respect of the strength of cryptographic algorithms would consider
what they have to say very seriously. I also believe that they should say
something and I don't see much reason why they should not do so this time
round.
In retrospect, all the ***covert*** actions that NSA took on DES improved
the algorithm and it is not obvious why they would behave differently now.
The US is the most advanced 'information economy' in the world and this
means that the US has more to loose than anyone if AES turns out to be weak.
And this also allows those of us outside the US to trust AES since we are in
a sort of 'Mutually Assured Destruction (MAD) situation' where any NSA
action to bring us down would bring the US down as well.
NSA did reduce the key length of DES from 64 to 56 bits and many thought
that this was so that they could break it but I very much doubt this. Given
the technology available at the time, and their 'volume' cracking needs, I
cannot see that this conclusion stands up under retrospective scrutiny.
This is one fact where your wrong the design of MECL logic boards
was will known at that time. It would be foolish to think they did not build
hardware to conviently break the 56 bit keys.
Although I do not know the answer here, I suspect what it might be. My
guess is that NSA were breaking much poorer algorithms than DES at the time
and desperately needed a way of convincing their targets not to move to DES.
The key length reduction, leaving people to draw the (wrong) conclusions,
was a masterful bit of psychological warfare that did exactly this.
You have got to be joking. Who would belive such nonsense.
As a result of this brilliant deception I suspect that NSA targets went on
using broken algorithms for years even though a great algorithm - DES - was
right in front of their very eyes. And the fact that DES was strong and yet
seemed to outsiders to be weak provided a rare occasion in which the good
guys were able to 'have their cake and eat it' by being able to use DES for
true protection while ensuring that the bad guys were far too suspicious of
it to ever contemplate its use.
You are not even close to reality.
The sad fact is that computer security is many orders of magnitude less
effective than algor
