Cryptography-Digest Digest #952, Volume #12 Wed, 18 Oct 00 15:13:00 EDT
Contents:
Re: DNA encoding (James Felling)
Re: Counting one bits is used how? (James Felling)
Re: How insecure is this... (Anton Stiglic)
Re: Looking for small implementation of an asymmetric encryption (Mike Rosing)
Re: Smartcard, Mathematical Proof? (James Felling)
Re: Counterpane Funny Stuff (Tony L. Svanstrom)
Huffman stream cipher. (Benjamin Goldberg)
Re: Storing an Integer on a stream (Benjamin Goldberg)
Re: block-cipher silly question? (Benjamin Goldberg)
Re: Efficient software LFSRs (Tom St Denis)
Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom (Jim)
Re: Why trust root CAs ? (Stefek Zaba)
JOB: Software Engineer : Security ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: DNA encoding
Date: Wed, 18 Oct 2000 12:11:34 -0500
This is more of a case of stenography than cryptography. Yes I can see how
it would be difficult to find given the comparitively small amount to data
in the huge mountain of "noise". Though I can see why this would be nearly
impossible to find -- literally a needle in a haystack, i suppose you could
attempt to make an attack based upon identifying the primers. If they are
truly unknown this would be excellent stenography.
[EMAIL PROTECTED] wrote:
> In article <8sge19$l08$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > In article <KkOG5.111791$[EMAIL PROTECTED]>,
> > "binary digit" <[EMAIL PROTECTED]> wrote:
> > > Hey, if any of you heard last year the winner of the inetl science
> > research
> > > contest took a message and encoded it in DNA. When I first heard
> > this I was
> > > skeptical on how she did this task. I searched around to see if
> > theer was
> > > any explanatyion on how she did it and i found a video of her at the
> > rewards
> > > explaining how it worked. She said she took a group of acids and
> > made them
> > > reprtesent a letter of the alphabet. for ie 'ccc' = x and so on. I
> > also
> > > read that she claimed her encryption to be 'unbreakable', which i
> > giggled at
> > > cause if thats the way she actually did her project, how did she win
> > the
> > > intel contest and how could she even claim that was unbreakable.
> Can
> > anyone
> > > verify any of this, on how she actually encoded a message 'into'
> dna?
> >
> > Like always the facts are all fudged up.
> >
> > She "encoded" a message in DNA not "encrypted" and "unbreakable" is
> > not an issue considering it's not cryptography.
>
> No, it's a question of concealing the message rather than encrypting
> it. If the message is placed between a pair of specified primer
> sequences that the creator and reader keep secret (like a secret
> key) then the DNA can be mixed with other DNA and be basically
> undetectable unless you know the primer sequences. The primer
> sequences can be used to PCR amplify the encoded DNA and read the
> message.
>
> So there is an analogy to 'unbreakable', but it's more like
> 'undetectable'.
>
> Ingrid
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Counting one bits is used how?
Date: Wed, 18 Oct 2000 12:20:11 -0500
Peter van der Linden wrote:
> How does counting the number of 1 bits in a word
> relate to crypto?
>
> Just curious about why this seemingly recondite instruction
> pops up in various instruction sets. How is it useful?
Amongst other things its highly useful in sidechannel techniques such as
timing and power analisys -- the hamming weight of an opperation on many
architectures will determine how much power is used to execute the op,
and many ops ( such as exponentiation take a variable amount of time
depending upon how many bits are set vs. not set.). Additionally it may
be useful in other forms of analisys some algos may have unusual
properties in re popcount or parity, and this can allow the search space
to be reduced thereby.
I am certian that there are other potential uses for this, but cannot
think of such at the moment.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: How insecure is this...
Date: Wed, 18 Oct 2000 13:32:41 -0400
Thomas Pornin wrote:
> -- build a MAC, so you can detect tampering with your data.
>
Using CBC with some private IV will not give you a
cryptographically secure MAC as is, you have to do
something like CBC-MAC.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Looking for small implementation of an asymmetric encryption
Date: Wed, 18 Oct 2000 12:38:02 -0500
"j0n.walker" wrote:
Need to store a 10 digit password(number) in some encypted form (2.5 16 bit
> words) as an encypted value.
> All the code has to be written in assembler of an ancient vintage (the
> number system is in octal!).
>
> The user will then type his 10 digit passnumber, the number will be
> processed using the algorithm and finally compared against the stored value.
All you need is a hash function. Since there are only 40 bits, brute force
is definitly possible. As long as you can keep the password file from being
copied for an offline attack you have some security. Check out the Unix
"crypt" function or sha-1 or MD-160 for good examples.
Patience, persistence, truth,
Dr. mike
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Smartcard, Mathematical Proof?
Date: Wed, 18 Oct 2000 12:40:33 -0500
Mykhailo Lyubich wrote:
> David Schwartz wrote:
>
> >
> > Suppose hypothetically that the smart card in S2 made it physically
> > impossible to retrieve the key. You could only request that the smart
> > card encrypt or sign specific values. In this case, someone who
> > compromised the software security of general purpose computer S1 could
> > construct a duplicate of it, whereas that would not be possible for S2.
> > Perhaps they could dupe S2 into signing/encrypting/decrypting on their
> > behalf, but they couldn't construct a duplicate of it.
> >
> > DS
>
> I find such kind of reasoning useful in the case of a small specification.
> The problem arises when we deal with big spec where many keys could
> be stored inside the card. Do we need something more formal to
> atomize the proof process?
>
There are weakness and strengths to the smartcard. As it stands the question
cannot be resolved.
In some ways S1 is more secure than S2. If S2(card) is locked safely away and
only taken out when S2 is needed, then the system is more secure than S1 in a
real way as the possibility of "unauthorized" intrusion is possible on S1 at any
time, and on S2 only durring specified times( thus reducing your window of
vulnerability, and allowing you to identify attackers more easily and investigate
probes more readily).
OTOH, if the smart card is something that is not secured,then S1 is potentially
more secure than S2 as in this case you have the potential for attacks vs. the
smart card, such as duplication, hardware analisys, offline password generation,
etc. that are not possible vs. S1, as all attacks vs that system must be made
online.
The smart card is in effect a physical password -- even if it is not actually
used for validation purposes. The reason for this is that without it the system
is not usable, and with it it is. This means if the password is kept secure,
the system is more secure than it would otherwise be( as not having the card is a
barrier to access for the unauthorised), and if the card is kept in an insecure
manner then you derive no real benefit from it as it will discourage a certian
class of casual attackers, but not determined adversaries, and the possibility
exists of it being a point of compromise of your security (as an "evil twin" card
could be made that duplicated its operations, and did something to harm your
system, or validates illegal logons or whatever)
------------------------------
Subject: Re: Counterpane Funny Stuff
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Date: Wed, 18 Oct 2000 17:58:58 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> at http://www.counterpane.com/pr-funding.html
>
> They have the quote "Counterpane is the right company at the right
> time. They offer the first scalable security business model that
> broadly leverages unparalleled security expertise to all businesses. I
> can't think of a better team to solve the problem of securing e-
> business."
>
> What the hec k is a "scalable security business model that broadly
> leverages unparalelled security expertise...." sounds like the output
> of a buzzword generator...
It's the businessworlds version of unbreakable cryptostuff.
/Tony
--
/\___/\ Who would you like to read your messages today? /\___/\
\_@ @_/ Protect your privacy: <http://www.pgpi.com/> \_@ @_/
--oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
on the verge of frenzy - i think my mask of sanity is about to slip
---���---���-----------------------------------------------���---���---
\O/ \O/ �99-00 <http://www.svanstrom.com/?ref=news> \O/ \O/
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Huffman stream cipher.
Date: Wed, 18 Oct 2000 18:09:41 GMT
Because a keyed Huffman coding is a more secure primitive than a
polyalphabetic substitution, I am proposing an idea to use one as a
stream cipher. The following is my proposal for generating a psuedo
random Huffman tree (refered to as a PRHT from now on).
ranmod(x) : a psuedo random number in the range 0..(x-1)
1) Fill a vector with leaf nodes for the values 0..255
2) Set i=256
3) j = ranmod(i); k = ranmod(i-1); if(k>=i) ++k;
4) Join nodes j and k to create a branch.
4a) Label j 0 and k 1.
4b) Remove nodes j and k from the vector, and insert the new branch.
Where the branch is inserted does not matter, provided it is done
in a consistent way.
5) if( --i >= 1 ) goto 3;
Assuming ranmod is unbiased, we should have an unbiased selection from
all of the possible trees. There are, I'm sure, fewer than 256! * 255!
trees (even taking into account labelings of branches and leaves), but
how many are there?
The only cryptographic analysis of huffman codes that I know of [MM92]
depends on the actual statistics of the original plaintext matching that
of the tree, making it not applicable to this usage.
Since, with some amount of work, part of the tree can be learned if we
have known plaintext, and can discover where in the ciphertext it's
corresponding description is, one pass with a PRHT is not sufficiently
secure. However, breaking up the ciphertext into bytes and enciphering
using a second PRHT should be sufficiently secure.
Since the 2-PRHT system can still fail through a related plaintext
attack, and due to the storage requirements for the tree, it would be
better to use an IV, hash it with the key, use this as the seed of the
PRBG, and generate a new pair of PRHTs for every message.
For terminating the message, IF the ciphertext does not already end on a
byte boundary, then the longest symbol in the second PRHT is found, and
enough bits from it are outputed to fill out a byte.
****
For those who want me to be less vague, and for me to specify the system
completely: Assume the IV is 64 bits produced by a TRNG. Assume that
the key is 128 bits. Assume that the PRNG used is a 120 bit SSLFSR.
Assume that SHA1 is the hash used to combine IV and key to make the
SSLFSR seed. Assume that ranmod 32 bits at a time are taken from the
SSLFSR, and if it's not a good value to get an unbiased result in the
desired range, it's discarded and a new 32 bit value is taken.
****
Because of the nature of the system, some messages will expand, and some
will get smaller. Does anyone want to offer numbers on probabilities
and amounts of expansion or contraction?
****
I can't think of any attacks on the key, at all. I can think of a
chosen plaintext attack on the trees, but this only breaks one message.
Can anyone think of any other (preferably known, not chosen, plaintext)
attacks on this system?
****
MM92: "On the Cryptanalysis of Huffman Codes," by Mojdeh Mohtashemi, May
1992. http://theory.lcs.mit.edu/~cis/theses/mohtashemi-masters.ps
PS to John A. Malley: Perhaps it was published in June, but page 1 of
the paper itself says May. Thanks for the link, anyway.
--
"Mulder, do you remember when I was missing -- that time that you
*still* insist I was being held aboard a UFO?"
"How could I forget?"
"Well, I'm beginning to wonder if maybe I wouldn't have been
better off staying abo-- I mean, wherever it was that I was
being held." [from an untitled spamfic by [EMAIL PROTECTED]]
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: Storing an Integer on a stream
Date: Wed, 18 Oct 2000 18:09:50 GMT
SCOTT19U.ZIP_GUY wrote:
> >> Take a look if you want an example give me a set of data and I can
> >> give you the set with the pointer added.
> >
> >Ok. Here is my data: I want to encode the pointer 3287 and send it
> >over a bitstream. What is the string of 0s and 1s that gets sent.
>
> Actually the way its encoded is a function of the file. Maybe It
> would be easier explained if you don't just think of it as added in.
> But welded in.
Since you refuse to answer my request, I'll make it into a much simpler
one. Could you give an example [original] file, and an example
[modified] file?
--
"Mulder, do you remember when I was missing -- that time that you
*still* insist I was being held aboard a UFO?"
"How could I forget?"
"Well, I'm beginning to wonder if maybe I wouldn't have been
better off staying abo-- I mean, wherever it was that I was
being held." [from an untitled spamfic by [EMAIL PROTECTED]]
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: block-cipher silly question?
Date: Wed, 18 Oct 2000 18:10:01 GMT
David Wagner wrote:
>
> Douglas A. Gwyn wrote:
> >John Savard wrote:
> >> A true block cipher with an 8-bit block would be a monalphabetic
> >> substitution on a 256-character alphabet. That could not be secure.
> >
> >In ECB mode, sure, but there are reasons why ECB is not much used
> >even with large block sizes.
>
> The original poster stated that he was not interested in feedback
> modes, so I do not see how stream ciphers are relevant.
>
> In this case, I cannot see how a cipher with a 8-bit block can be
> secure. (Perhaps this is just my lack of imagination; I'd be happy to
> be corrected!)
How about you first perform an AONT on the message?
--
"Mulder, do you remember when I was missing -- that time that you
*still* insist I was being held aboard a UFO?"
"How could I forget?"
"Well, I'm beginning to wonder if maybe I wouldn't have been
better off staying abo-- I mean, wherever it was that I was
being held." [from an untitled spamfic by [EMAIL PROTECTED]]
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Efficient software LFSRs
Date: Wed, 18 Oct 2000 18:03:23 GMT
In article <[EMAIL PROTECTED]>,
"Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote:
> This is a brief summary of a technique for implementing efficient
LFSRs
> in software. The mechanism involves generating successor states a
word
> at a time rather than a bit at a time. In order to accomplish this
> parallelism inter-tap dependencies must be eliminated.
<snip>
Have any source code to show off your implementation?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Jim)
Crossposted-To: talk.politics.crypto
Subject: Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom
Date: Wed, 18 Oct 2000 18:21:29 GMT
Reply-To: Jim
On Wed, 18 Oct 2000 01:25:23 +0100, Mathew Hendry
<[EMAIL PROTECTED]> wrote:
>On Tue, 17 Oct 2000 15:19:03 -0700, Anthony Stephen Szopa <[EMAIL PROTECTED]>
>wrote:
>
>>Stolen German Code Machine Turns Up in BBC Mailroom
>>
>>http://ap.tbo.com/ap/breaking/MGA5JU6YFEC.html
>
>Or from the horse's mouth
>
> http://news.bbc.co.uk/hi/english/uk/newsid_977000/977127.stm
>
>Three of the four rotors are missing. (Why steal only those?)
Further ransom?
--
______________________________
Posted by Jim Dunnett
dynastic at cwcom.net
nordland at lineone.net
------------------------------
From: [EMAIL PROTECTED] (Stefek Zaba)
Subject: Re: Why trust root CAs ?
Date: 18 Oct 2000 14:34:04 GMT
In sci.crypt, Pawel Krawczyk ([EMAIL PROTECTED]) wrote:
> BTW there is a requirement in most world e-commerce laws, that the CAs
> escrow their keys to the goverment. This applies to France, Germany
> for sure, and probably most other countries where digital signature
> law exists (Poland soon, so this is why I'm interested in it).
Fortunately, this is false. There *was* a proposal which ran along lines
vaguely like this in the UK: even that proposal did not escrow the CA's
private cert-signing key, but "merely" required that all licensed CA's (and
the proposals went through various flavours over whether licensing was to
be compulsory or merely, um, encouraged) when certifying end-user keys
which were intended to be used for encryption would require that those
end-users escrow the associated private key with the CA - which would then
produce said key on demand to the Authorities, and keep the end-user unaware
that such a disclosure had been made.
Fortunately that proposal has died a death, because of its technical,
commercial, and political unworkability.
As far as I know - and I try to follow these things pretty closely! - *no*
current EU member state is requiring any form of escrow as a condition of
CA operation; indeed, the relevant EU Directive on digital signature
recognition explicitly rules out any such linkage. (The precise nature
of the do-not-link-digital-signature-recognition-with-key-escrow is not
as black and white as the above suggests, but the practical effect is
- not at all accidentally - as stated).
I'd be concerned to hear that a "fast-track EU accession candidate" was
proposing to create national legislation on digital signatures which was
not compatible either with its own economic interests or with existing EU
directives...
Stefek
------------------------------
From: [EMAIL PROTECTED]
Subject: JOB: Software Engineer : Security
Date: Wed, 18 Oct 2000 18:31:44 GMT
We are on retainer with a premier Fortune high technology manufacturing
company in the midwest that manufacturers self-service terminals for
financial applications. Our client is growing and as a result has a
need for a talented, Software Engineer who has some expertise in
Software Security and Cryptography. This is a key position to enable
our client to set them selves apart from their competitors in the area
of security for open systems architectures. They are looking for
someone who is interested in applied software security and cryptography
as well as researching new methods.
This is a senior level software and systems engineering position. The
individual will be responsible for the investigation and implementation
of such software and hardware components that ensure the secure
transfer and storage of sensitive financial institution and individual
customer data. This will include, but not be limited to, transfer and
holding of customer PIN's cryptography keys and algorithms. The
individual will provide input, such as software algorithms, information
on current industry trends, to various internal software groups. Will
ensure that algorithms and techniques used for data security meet
government and industry standards specifications.
Qualifications
* A BSEE or BSCS or equivalent degree with 5 to 7 years of
programming experience
* Experience in cryptography and other PC security projects
* Experience with data communications standards and trends
* Experience with C, C++ and general software and system
development practices
* Experience in Windows NT, Windows 98, OS/2 required, Linux and
Unix helpful
Compensation/Benefits:
Salaries based on candidates experience level. Full
relocation and interview expenses provided.
How to Apply:
For immediate consideration, please e-mail or fax your
resume TOLL-FREE to: Heidi Kay, President/Certified Personnel Consultant
Kay Concepts, Inc.
Toll-free fax: 800-879-5828
E-Mail: [EMAIL PROTECTED]
Kay Concepts is delighted to receive your resume
via text e-mail, however your unique personality is
better reflected to our clients by your word processor
created resume by fax or e-mailed as an attachment
in Word or WordPerfect.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
