Cryptography-Digest Digest #295, Volume #13 Fri, 8 Dec 00 23:13:00 EST
Contents:
Re: File Deleter/Nuker ? (Will Simmons)
Re: DES_BCE64 (Tom St Denis)
Re: document signing, XML canonicalization and why EDDF is a better choice (Tom St
Denis)
Re: weten we die PIN? (Olaf Biemond)
Re: which is the most secure algo for me? (Ray Dillinger)
Re: which is the most secure algo for me? (Eric Lee Green)
Re: How to embed a key in executable code? (Eric Lee Green)
Re: How to embed a key in executable code? (David Schwartz)
Re: Hamming Distance (Jeremy Buhler)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Will Simmons)
Subject: Re: File Deleter/Nuker ?
Date: Fri, 8 Dec 2000 23:21:39 GMT
In article <90bl8k$m6t$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
>Most of the time hard disks are so dense that writing over the data
>once is often enough. "Multi-pass" file wipers are just plain paranoia
>food. On floppy disks your best bet is to burn them since they are
>cheap. But because hard disks store information so densely the
>probability of left over data is next to nill.
Apparently, this is wrong. Please don't take my word for it. I'm no expert.
See, instead, "Secure Deletion of Data from Magnetic and Solid-State
Memory" by Peter Gutmann Department of Computer Science University of
Auckland; URL: http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html
He explains how the big boys do it. Sure, it costs lots of money, but it's
yours -- so why not ?
-- Will --
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: alt.sources.crypto,list.cryptography
Subject: Re: DES_BCE64
Date: Sat, 09 Dec 2000 00:07:22 GMT
In article <90rd21$61i$[EMAIL PROTECTED]>,
"TacTic" <[EMAIL PROTECTED]> wrote:
> I need source of information on DES_BCE64 please!
>
Where did you hear of BCE? Do you mean ECB? That's the native usage
mode of any block cipher.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: document signing, XML canonicalization and why EDDF is a better choice
Date: Sat, 09 Dec 2000 00:06:41 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (denis bider) wrote:
> On Fri, 08 Dec 2000 19:02:02 GMT, Tom St Denis <[EMAIL PROTECTED]>
> wrote:
>
> >> EDDF has been designed very much with cryptographic applications in
> >> mind. One of the very motivations behind EDDF is to provide - or at
> >> least make an attempt to provide - a universal document format to
> >> facilitate electronic signing of documents.
> >Methods of electronic signing already exist, how will EDDF improve
upon
> >them?
>
> The problem is not that there is no method of electronic signing - the
> problem is that there is not yet a consensus as to what format a
> document that is to be signed, or verified, should generally be in.
> I.e. - there is no universal data format that everyone understands and
> that can be used effectively for document signing and verification
> purposes. [Let us presume for the moment that the presence of such a
> data format would be of benefit to the entire community.]
>
> There is a candidate for a universal data format, however, and its
> name is XML. But when it comes to digital signature and signature
> verification, XML has several fundamental problems that stem directly
> from the way it was designed. Specifically, the fact that the same XML
> document can appear in an endless multitude of forms, which are all,
> basically, the same document.
I would argue PGP is rather standard for txt msgs.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Sat, 09 Dec 2000 01:54:51 +0100
From: Olaf Biemond <[EMAIL PROTECTED]>
Crossposted-To:
alt.cracks.nl,alt.nl.telebankieren,nl.comp.crypt,nl.financieel.bankieren,nl.juridisch
Subject: Re: weten we die PIN?
John wrote:
>
> Olaf Biemond wrote:
> <knip>
> > > Veilig zou ik dat ook niet willen noemen. Mits je de lijn kunt vinden
> > > tussen de automaat en de PTT kast kun je de lijn met een simpel thuis
> > > te bouwen apparaatje aftappen.
> >
> > En dan kun je er vervolgens: helemaals niets mee. De data is zwaar
> > ge-encrypt met regelmatig wisselende sleutels. Ik zou het echt wel
> > veilig willen noemen. Misschien zelfs wel een beetje overdone.
>
> Hmm, overdone? Lijkt me niet, lees het volgende artikel maar eens.
>
> http://www.info-sec.com/crypto/99/crypto_060899c_j.shtml
>
> Gr, John
Ik heb het overigens zeer interressante artikel nog niet helemaal
gelezen, maar mijn eerste indruk bevestigt wat ik wilde zeggen: daar
waar er gefraudeerd wordt met een ATM is dit in veruit de meeste
gevallen te wijten aan menselijk falen (van bankmedewerkers: niet volgen
van procedures of van klanten: je PIN af laten kijken) dan wel is er
sprake van medewerking van mensen binnen de bank. Zoals je noemde een
lijntje aftappen en er dan iets mee doen is vrijwel ondoenlijk en zeker
niet rendabel (te veel moeite voor te weinig opbrengst).
Groeten,
Olaf.
------------------------------
From: Ray Dillinger <[EMAIL PROTECTED]>
Subject: Re: which is the most secure algo for me?
Date: Sat, 09 Dec 2000 01:28:53 GMT
[T] <[EMAIL PROTECTED]> wrote:
: hi there, im looking for an encryption algo for a server program im coding,
: a public key one, as it has to be reasonably fast.
: which one would be the most secure one? briefly reading some doc about algos
: i'd say IDEA or Blowfish, suggestions?
: thanks in advanche.
IDEA is good, generally speaking. It's simple, serviceable, and
can be implemented efficiently on small (even 16-bit) machines.
Blowfish is faster at encrypting than IDEA, but slower to start up
because it has to do a bunch of work on the key before it starts.
AES (formerly Rijndael) is almost as fast as Blowfish in
running, and requires little or no key setup time.
Blowfish and AES are 128-bit block ciphers; IDEA is a 64-bit block
cipher. All of them are strong enough to ensure that the cipher
choice is *not* the weakest link in your security.
Which one is best for your application depends on what your application
is.
If you're going to be encrypting files or ftp documents on a
standard desktop machine or better, I'd say go with Blowfish;
its speed wins out on bigger documents.
If you're going to be using the thing to protect individual packets
in a small-packet protocol like Telnet, or if you have an embedded
system or smartcard architecture (or even, god forbid, if you have a
DOS machine to work with), I'd say use IDEA; its smaller block size
and minimal CPU requirements makes it suit that purpose better and
can save you some time and bandwidth.
If you're going to be using it for medium sized traffic (web, email,
and http type stuff) on a desktop machine, I'd say use AES; its agility
in changing keys and short setup time allows you to efficiently deal
with downloading short documents from many hosts (with different keys)
at once or in quick succession.
Given that robbing your house, or kidnapping and torturing you, or
even paying you ten million dollars to share your secrets, would all
be *far* cheaper than breaking any one of the above, I'd say there
seems to be no need to be overly concerned about which one of them
is 'most secure'. (As far as I know, it's Blowfish -- but who cares?)
Pick any one of them, and then forget about the cipher; concentrate
on creating a good implementation and not making silly mistakes like
using guessable passphrases. For bonus points, remember to write-over
memory that may contain keys before exiting any routine, and figure
out how to prevent the Operating System from swapping keys or plaintext
to the disk during all operations. While you're at it, don't let
the system display your plaintext on the screen in an unshielded
room. 'Cause if you've got one of these ciphers, any of those mistakes
opens up a *FAR* easier route to your secrets than any theoretical
ciphertext attack.
Bear
------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Subject: Re: which is the most secure algo for me?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 09 Dec 2000 02:55:59 GMT
On Sat, 09 Dec 2000 01:28:53 GMT, Ray Dillinger <[EMAIL PROTECTED]> wrote:
>[T] <[EMAIL PROTECTED]> wrote:
>: hi there, im looking for an encryption algo for a server program im coding,
>: a public key one, as it has to be reasonably fast.
>: which one would be the most secure one? briefly reading some doc about algos
>: i'd say IDEA or Blowfish, suggestions?
>: thanks in advanche.
>
>
>IDEA is good, generally speaking. It's simple, serviceable, and
> can be implemented efficiently on small (even 16-bit) machines.
>Blowfish is faster at encrypting than IDEA, but slower to start up
> because it has to do a bunch of work on the key before it starts.
>AES (formerly Rijndael) is almost as fast as Blowfish in
> running, and requires little or no key setup time.
>
>Blowfish and AES are 128-bit block ciphers; IDEA is a 64-bit block
>cipher.
Blowfish is a 64-bit block cipher, though it is usually used with 128-bit
keyes. You must be thinking of Twofish, a 128-bit block cipher. An issue
with IDEA is that it is patented in many countries. Given the number of
good free ciphers (like Blowfish, Twofish, and AES), I would not suggest
using IDEA unless you need to interoperate with someone else who uses IDEA.
>All of them are strong enough to ensure that the cipher
>choice is *not* the weakest link in your security.
That statement, however, is very true. In particular, I would strongly
suggest researching the other primary causes of failure in cryptographic
systems -- poor key generators (no, sorry, the rand() function in your
"C" library will NOT work for generating keys!), poor protocols
(specifically, protocols succeptible to replay attacks, insertion
attacks, and other such things), and poor secrets management (passing
secrets over the network unencrypted being the biggy, but how to manage
secrets stored on disk is an issue too).
>Pick any one of them, and then forget about the cipher; concentrate
>on creating a good implementation and not making silly mistakes like
>using guessable passphrases. For bonus points, remember to write-over
>memory that may contain keys before exiting any routine, and figure
>out how to prevent the Operating System from swapping keys or plaintext
>to the disk during all operations. While you're at it, don't let
>the system display your plaintext on the screen in an unshielded
>room. 'Cause if you've got one of these ciphers, any of those mistakes
>opens up a *FAR* easier route to your secrets than any theoretical
>ciphertext attack.
Absolutely. There are so many minefields here that I have given up
believing that the protocols that I invented for the network
communications in BRU Professional are totally secure. At best I will
claim that they are more secure than any competing backup products'
network communications, and that the only known hole (dealing with
distribution of public keys and man-in-the-middle attacks) is easily
avoided.
--
Eric Lee Green There is No Conspiracy
[EMAIL PROTECTED] http://www.badtux.org
------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Subject: Re: How to embed a key in executable code?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 09 Dec 2000 03:17:14 GMT
On Fri, 08 Dec 2000 20:01:37 GMT, Simon Johnson <[EMAIL PROTECTED]>
wrote:
>In article <[EMAIL PROTECTED]>,
> David Schwartz <[EMAIL PROTECTED]> wrote:
>> Creating a software-only copy protection scheme is actually
>_easier_
>> than hiding a private key in your programs. Software-only copy
>> protection can be achieved by placing a public key in your code. It
>> doesn't matter if someone can read that key because it's a public key,
>> that wouldn't help thbem at all to create their own forged
>credentials.
At which point:
1) I would single-step through the program using either a debugger or an
ICE (In-Circuit Emulator),
2) I would find the public key, and
3) I would replace it with my own public key, for which I know the private key.
Voila.
I agree that hiding a private key in your programs is stupid. At least if
somebody replaces your public key, they cannot fake credentials (as stored
in license files etc.) using it.
>> So software-only copy protection doesn't require hiding anything, it
>> just requires preventing a public key from being tampered with. Tamper
>> proofing is _much_ easier than hiding.
Tamper proofing is no easier, and no harder, than hiding. I have encountered
programs that attempt to make themselves tamper-proof. It has always been
child's play to prove those programmers wrong, though sometimes it has
required using drastic means (such as a CPU emulator).
I would suggest that if a certain program's tamper proofing has not
been cracked, it's probably because it's not challenging enough to
interest the real crackers.
>A impracticle, but a secure(er) way of doing this would be to have each
>program have its own public/private key. The executable would then
>consist of two parts. The first would be a interpretor, the second
>would be a scripted version of the program, encrypted in the private
>key.
This actually would work better than simple obfuscation, and the
Internet is actually starting to make it feasible: each customer gets
a unique copy of the program, with major parts encrypted with a unique
private key. Each customer gets a unique public key that decrypts
those parts of the program (or rather, decrypts a unique symmetric key
which in turn decrypts the rest of the program). Voila. No public key,
no run program. Of course, my response, if I were a cracker, would be
to drop a breakpoint in my CPU emulator for immediately after the
unique parts were decrypted, do a binary patch to jump over the
decrypter subroutine in the disk file, replace the encrypted parts
with the decrypted parts in the disk file, and it's cracked. Hubba
hubba.
Basically: as long as we can emulate hardware, we can crack software.
The only "uncrackable" scheme lives in the minds of the clueless. The
most that we, as security engineers, can do is make it more difficult
and time-consuming for crackers to get into our software. The extent
to which that's cost-effective depends upon the software -- I suspect
that games (which have a very limited shelf life) benefit most from
the protection (because it may take crackers long enough that the game
is no longer even on the shelves by the time they crack it), while
most business software probably needs little or no protection (since
the BSA etc. run hotlines encouraging disgruntled employees to turn in
their pirate worthless scum employers -- a much scarier thing than copy
protection!).
--
Eric Lee Green There is No Conspiracy
[EMAIL PROTECTED] http://www.badtux.org
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: How to embed a key in executable code?
Date: Fri, 08 Dec 2000 19:24:21 -0800
Eric Lee Green wrote:
> At which point:
>
> 1) I would single-step through the program using either a debugger or an
> ICE (In-Circuit Emulator),
> 2) I would find the public key, and
> 3) I would replace it with my own public key, for which I know the private key.
>
> Voila.
Right, so to protect against this, I can do one of two things:
1) Prevent you from finding the key, OR
2) Prevent you from tampering with the key.
Hence, preventing this attack is _easier_ than simply preventing you
from finding the key. In general, 2 is easier than 1.
> >> So software-only copy protection doesn't require hiding anything, it
> >> just requires preventing a public key from being tampered with. Tamper
> >> proofing is _much_ easier than hiding.
>
> Tamper proofing is no easier, and no harder, than hiding. I have encountered
> programs that attempt to make themselves tamper-proof. It has always been
> child's play to prove those programmers wrong, though sometimes it has
> required using drastic means (such as a CPU emulator).
I disagree. Tamper proofing is significantly easier than hiding.
> I would suggest that if a certain program's tamper proofing has not
> been cracked, it's probably because it's not challenging enough to
> interest the real crackers.
Well, obviously tamper proofing isn't impossible. So if it hasn't been
done, it's tautological that it hasn't gotten sufficient interest from
sufficiently competent people. Nevertheless, the higher you raise the
bar, the less likely that someone will go over it.
> Basically: as long as we can emulate hardware, we can crack software.
> The only "uncrackable" scheme lives in the minds of the clueless. The
> most that we, as security engineers, can do is make it more difficult
> and time-consuming for crackers to get into our software. The extent
> to which that's cost-effective depends upon the software -- I suspect
> that games (which have a very limited shelf life) benefit most from
> the protection (because it may take crackers long enough that the game
> is no longer even on the shelves by the time they crack it), while
> most business software probably needs little or no protection (since
> the BSA etc. run hotlines encouraging disgruntled employees to turn in
> their pirate worthless scum employers -- a much scarier thing than copy
> protection!).
Actually, the software that's at precisely the highest risk is software
that is:
1) Easily available, for example, publically downloadable.
2) Of general interest, and of special interest to people with the
highest ability to defeat its protection, and
3) reliant on licensing files or keys to control features, as opposed
to not releasing the software for those features.
That's why ConferenceRoom is such an interesting case. It meets all
three requirements in spades, and is a very popular request among
pirates. It's available for free from our web page, but relies on
'license keys' to control access to advanced features. I believe it's
software protection scheme is one of the best in existence.
Nevertheless, it has seen three minor breaks in as many years (since the
new scheme was put in place). However, nobody has managed to bypass the
license check without severely compromising normal operation.
DS
------------------------------
From: Jeremy Buhler <[EMAIL PROTECTED]>
Subject: Re: Hamming Distance
Date: Sat, 9 Dec 2000 03:19:52 GMT
Quoth [EMAIL PROTECTED]:
> Given a list of binary strings (256 bits each) is there an
> time-effecient way to find the set of strings within a certain hamming
> distance from each member? Currently, I'm doing a simple iteration:
If you can tolerate missing a few pairs of close strings at random,
there are some nice randomized algorithms recently developed for this
problem. The methods scale to extremely large numbers of strings --
I'm using them to find matches of length ~70 at a distance of up to 23
mismatches for inputs containing one to twenty MILLION strings.
Here's a pointer to a recent article:
@InProceedings(Gio99,
AUTHOR = "Aristides Gionis and Piotr Indyk and Ravjeev Motwani",
TITLE = "Similarity search in high dimensions via hashing",
BOOKTITLE = "Proceedings of the 25th Conference on Very Large Databases
(VLDB 99)"
ADDRESS = "Edinburgh, Scotland",
YEAR = 1999
)
For the all-pairs variant of the problem which you describe, it's probably
more efficient to sort the bitstrings by hash value rather than actually
building a hash table.
There are also exact algorithms adaptable to your problem which can be
several orders of magnitude more efficient than exhaustive search
(though still slower than the randomized ones when the desired
threshold for mismatches is high). As a simple example, if you only
want pairs of 256-bit strings with at most 10 mismatches, any such
pair must contain an exact match of length at least
floor[ 256/(10 + 1) ] = 23
So, hash every length-23 substring of every string in your input, then
compare only those pairs of strings which share a 23-substring. More
sophisticated variants of this idea are possible; see, e.g.,
@Article(Pev95,
AUTHOR = "Pavel Pevzner and M.~S. Waterman",
TITLE = "Multiple filtration and approximate pattern matching",
JOURNAL = "Algorithmica",
VOLUME = 13,
PAGES = "135--54",
YEAR = 1995
)
In general, this family of techniques goes by the name "exclusion methods."
Check out the last decade or so of proceedings from CPM, the Combinatorial
Pattern Matching conference, to find other examples.
--
## Jeremy Buhler * peace through superior algorithms * U. Washington ##
------------------------------
** 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
******************************
