Cryptography-Digest Digest #755, Volume #13 Mon, 26 Feb 01 23:13:01 EST
Contents:
Re: Viewable Picture Encryption ("Chase")
Re: CipherText patent still pending ("Prichard, Chuck")
Re: Viewable Picture Encryption (HiEv)
Re: How to find a huge prime(1024 bit?) (Benjamin Goldberg)
Re: Help Please !!!!!!!!!!!! (JPeschel)
Re: Arcfour in Ada (Benjamin Goldberg)
Safe to use DSS key for DH? (lcs Mixmaster Remailer)
Re: Am I doing something silly by including my gnupghome with my archive? (Paul
Rubin)
Re: CipherText patent still pending (Benjamin Goldberg)
----------------------------------------------------------------------------
Reply-To: "Chase" <[EMAIL PROTECTED]>
From: "Chase" <[EMAIL PROTECTED]>
Subject: Re: Viewable Picture Encryption
Date: Tue, 27 Feb 2001 03:10:37 GMT
Ok gotcha, your help is very much appreciated.. I have Applied
Cryptography, and have been reading it quite a bit... I have lots to learn
before I implement what I am trying to do here, but I just want to have a
solid idea of what I'm up against.. Thanks again!
- Chase
"Ben Cantrick" <[EMAIL PROTECTED]> wrote in message
news:97etrf$[EMAIL PROTECTED]...
> In article <_aCm6.478048$[EMAIL PROTECTED]>,
> Chase <[EMAIL PROTECTED]> wrote:
> >I have come up with an interesting concept that I would like to attempt
to
> >code, using Visual C++ 6....Here it goes:
> >
> >When encrypting most types of data, all the bits are
shifted/reorganized..
> >For example, when you encrypt a text file, you can view the encrypted
> >contents on like Notepad or whatever, but say, if you are trying to
encrypt
> >a JPG or BMP file, you can't open it, because the header that delinates
the
> >file as a .JPG or .BMP file is also scrambled. I would like to try and
have
> >it so that If I encrypt a JPG or BMP file, that it is still viewable in a
> >JPG or BMP viewer, but the actual picture contents are scrambled...so
> >essentialy, you'd be opening a picture file with all the picture
information
> >viewable, but scrambled. Does anyone have any idea how I can go about
doing
> >this? Any ideas would be very much appreciated.
>
> Decode the image into raw pixels, encrypt the pixels with a stream
cypher
> (RC4 would be a fine choice), then take the encrypted pixels and run them
> back through the JPG/BMP/whatever encoding scheme to make a new image.
>
> This sounds fairly simple, but rest assured that decoding and encoding
> popular image formats is much more complicated than you'd like. There's
> a lot of nuts and bolts stuff to be done here that is non-trivial. You've
> just asked "I want to build a car." And I've just said, "Well hey, just
> buy a frame, an engine, some wheels, and off you go!" In practice it
> just ain't that easy. And then there's the crypto part, too. But hopefully
> you'll be able to find free libraries on the net that will do both the
> image and crypto stuff for you, so you'll mainly just have to glue it
> all together. I know for a fact that the JPEG library exists, cause
> I've played with it myself. I imagine you can buy RC4 libraries from
> RSA data security. (Or just get a copy of _Applied Cryptography_ and
> roll your own implementation.)
>
>
> Word of warning, though - if you do this and you use JPGs, make
> sure to set the JPG quality to 100% before encoding. JPG is a "lossy"
> format - it loses detail in order to compress the image better. If the
> encrypted pixels get altered this way, they will not decrypt correctly.
> BMP and GIF (and TIFF and a lot of other "non-lossy" formats) don't have
> this problem.
>
> Another issue, more in the practical domain, is the problem of
> decrypting the image. If you want someone to be able to view the image,
> you're going to have to give them the crypto key used to encode it.
> (Unless you store it in the image somewhere - in which case why did you
> bother encrypting it?) This in turn implies that you have to keep a record
> of what key goes with what image. On a small scale this is easy. On a
large
> scale it is a logistical nightmare. Also, once you let a key out, what's
> to stop someone from copying it and giving away copies of it and the
> image at the same time? Etc... But if you're just doing this for fun,
> these kinds of problems probably aren't ones that you need to worry about.
>
>
> -Ben
> --
> Ben Cantrick ([EMAIL PROTECTED]) | Yes, the BGC dubs still suck.
> BGC Nukem: http://www.dim.com/~mackys/bgcnukem.html
> The Spamdogs: http://www.dim.com/~mackys/spamdogs
> "I'd rather know Lara Croft than Betty Crocker." -Douglas Copeland
------------------------------
From: "Prichard, Chuck" <[EMAIL PROTECTED]>
Subject: Re: CipherText patent still pending
Date: Tue, 27 Feb 2001 03:15:28 GMT
The idea to use a key attibute to articulate rotation of a somehow
modified key has been implemented and demonstrated with no response from
this newgroup by someone who has claimed to have previously used it. I
take some comfort in knowing that the idea has been intellectually
reviewed.
The resulting bit pattern that is applied to a message when a
sophisticated root key is used has a fair amount of integrity, and the
algorithm itself though simple, cannot be reverse engineered.
The integrity of the message depends entirely on the key, as with many
sophisticated algorithms.
Security is a process, profitability is implementation. I believe that
somewhere in the middle between sophisticated and simple is a practical
encryption solution that I can implement in several languages.
The Active X (OCX) implementation of CipherText can be downloaded from
the link below.
If I didn't think that my idea to use the key attribute in this algorithm
was innovative, and possibly worth developing, I would not be posting
news of my progress to this newsgroup. Recent posts have been more
plaintive as I have gained a better perspective. But that is not to say
that I don't approach my work with decency.
--
C. Prichard
http://greentv.crosswalkcentral.com
------------------------------
From: HiEv <[EMAIL PROTECTED]>
Subject: Re: Viewable Picture Encryption
Date: Tue, 27 Feb 2001 03:17:10 GMT
Chase wrote:
>
> I have come up with an interesting concept that I would like to attempt to
> code, using Visual C++ 6....Here it goes:
>
> When encrypting most types of data, all the bits are shifted/reorganized..
> For example, when you encrypt a text file, you can view the encrypted
> contents on like Notepad or whatever, but say, if you are trying to encrypt
> a JPG or BMP file, you can't open it, because the header that delinates the
> file as a .JPG or .BMP file is also scrambled.
Well, for a BMP file the header information is easily guessable. The
images can only be 1, 4, 8, 16, 24, and 32-bit images. Then it is just
a matter of testing out various widths for the image until you get one
that looks like a picture. I have code that does this and it usually
doesn't take more than a minute to find the right combination of bit
depth and image width to be able to view the image.
However, it is a little trickier for bitmaps at 4 and 8-bit color,
unless the image is grayscale, because then you need the palette to
properly view the image. Encrypting the palette for an 8-bit image but
not the image itself would make it so that you could tell what the image
is to some degree, but you probably wouldn't be able to tell what colors
some things really are. This would work better for photograph type
images than for cartoon type images.
For JPEG this is much easier because the quantization table(s) and
huffman table(s) are necessary to decode the image. It is not unheard
of to create JPEG images with a certain quantization table and not
include it in the image because the decoder has it built in. Of course
this means that if someone decompiles your decoder that they will then
have your quantization table, but even then they need to know how to use
it.
> I would like to try and have
> it so that If I encrypt a JPG or BMP file, that it is still viewable in a
> JPG or BMP viewer, but the actual picture contents are scrambled...so
> essentialy, you'd be opening a picture file with all the picture information
> viewable, but scrambled. Does anyone have any idea how I can go about doing
> this? Any ideas would be very much appreciated.
In this case it is much easier to do this for bitmaps than for JPEGs.
For bitmaps you only need to encrypt the image data in the file and it's
done.
For JPEG this is much harder unless you understand Discreet Cosine
Transforms (DCT) because you would need to encrypt this data, and then
create the data with the encrypted DCTs.
And in any case, the most important thing is to make sure that people
can't copy your image off the screen when your code is displaying it by
hitting the Print Screen key and then pasting that image from the
clipboard into some paint program so that they can save it. Even beyond
that, there are plenty of screen capture programs out there.
Well, good luck!
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: How to find a huge prime(1024 bit?)
Date: Tue, 27 Feb 2001 03:25:54 GMT
Thomas Boschloo wrote:
>
> [CC-ed: to sci.crypt for a professional opinion]
>
> An Metet wrote:
>
> > >How to find a huge prime(1024 bit?)
> >
> > Select a big random number, try to divide it by small numbers
> > first, then search for `Rabin-Miller� primality test at google. If
> > that fails, increase the number and repeat the above.
>
> I would disagree, although I am no scientist.
>
> Primes get very sparse at high numbers, but you just never know how
> far appart they will be. There might be vast spaces without any primes
> followed a few primes that are very near together.
>
> If you use your proposed algorithm (and I sure as hell hope that PGP
> 2.6.3i doesn't use this methode), you will be more likely to hit the
> first prime after a large space without primes, than you will be to
> hit the prime just after that. Thus you (radically?!) reduce the
> maximum ammount of primes you are likely to find.
As some other people have said, 1) PGP does indeed use this [biased]
method of finding primes, but 2) Brandt and Damg�rd have shown that this
bias does not affect security.
> The correct implementation would be to just generate a *new* prime
> from scratch, preferably with (some) new entropy added to your pool
> (maybe task-switching/runtime info?). It will be a lot slower I guess,
> gathering all that entropy and calculating all those MPI random
> numbers.
> But the resulting key will be a lot better IMHO!
You mean generate a new random number from scratch, and test if it's
prime. Actually, I can think of a more efficient method, assuming you
have an efficient one-bit-at-a-time RNG, which, although still biased,
is biased in a more complicated, practically undetectable way.
Here is the standard test-and-increment method as:
x := setbit( random_number(n), 0 )
until( prime(x) ) { x += 2 }
result := x
Here is the method you're suggesting:
do {
x := setbit( random_number(n), 0 )
} until( prime(x) )
result := x
Here's my method:
x := setbit( random_number(n), 0 )
until( prime(x) ) {
x := clearbit(x,n)
do {
if( random_bit() ) x := togglebit(x,0)
x := x << 1
} until( testbit(x,n) )
x := setbit(x,0)
}
result := x
If random bits are expensive, then my method is better than yours.
Also, it should be possible for you to use threads so entropy gathering
can be done as a background task. If you use the Yarrow PRNG, this
should be quite easy to set up.
--
A solution in hand is worth two in the book.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Date: 27 Feb 2001 03:49:25 GMT
Subject: Re: Help Please !!!!!!!!!!!!
PADDOCK [EMAIL PROTECTED] writes:
>the following is a list of unix crypt passwords
>
>have broken 15 of them using John the ripper and crack etc
>but can't get the rest - any ideas u clever bods?
You're kidding, right?
Try a bigger wordlist.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.ada
Subject: Re: Arcfour in Ada
Date: Tue, 27 Feb 2001 03:54:23 GMT
Thomas Boschloo wrote:
>
> Julian Morrison wrote:
> >
> > http://download.sourceforge.net/fling/arcfour-ada-1.0.0.tar.gz
> >
> > This code has been created for use with the Fling project
> > (http://fling.sourceforge.net/).
> >
> > This is ArcFour (Alleged RC4), CipherSaber variant, capable of
> > CipherSaber-1 and CipherSaber-2. It is coded in Ada, and is
> > dependent on AUnit and Formatted_Output (available via the AdaPower
> > site). It's probably pretty GNAT-dependent too, since I've had no
> > need to compile it anywhere else. If you want fixes, send patches
> > and/or bug reports via Fling's SourceForge patch tracker.
> >
> > This code has been placed in the public domain by its author.
> >
> > Release notes: first full release, all unit tests pass, but it may
> > be implementation dependant.
>
> http://fling.sourceforge.net/wiki/index.php?full=arcfour
>
> Why did you decide to go for arcfour and not the AES
> http://www.nist.gov/aes ? AFAIK Arcfour or RC4 was originally a
> 'security by obscurity' cypher (Arcfour was (now illegal) reverse
> engineered from RC4 by www.rsa.com).
Arcfour is not illegal, but the name "RC4" is trademarked. To use a
cipher called "RC4" without liscencing that trademark is illegal. To
use the algorithm is perfectly legal.
The algorithm of RC4 was a trade secret, meaning that some "security by
obscurity" was involved, but in spite of that, the algorithm is still
fairly secure.
> I understand that you might like the idea of a stream-cypher for data
> transmission, but aren't stream and block cyphers thought to be
> somewhat identical in functionality by cryptographers?
Whoa! No way, man! Where did you get that wierd idea? Stream and
block ciphers are *very* different. I'm not going to explain how they
work, but here's the pros and cons of each:
Stream cipher, pros:
You can encipher one byte [one word] at a time, fairly quickly.
Stream cipher, cons:
You can't use the same key to encipher more than one message.
Block cipher, pros:
You can use one key to encipher more than one message.
Block cipher, cons:
You must encipher multiples of the block size.
Fairly CPU intensive; slow.
ARC4 pros:
Well known, easily memorized, hard to incorrectly implement.
5 clocks per byte of keystream.
ARC4 cons:
Minor bias in first bytes, (avoidable, discard first N bytes).
Tiny correlation over large amounts of data (hard for enemy to detect).
AES pros:
Fairly secure, well cryptanalysed. No known weaknesses.
AES cons:
Complicated, easy to screw up... you almost have to copy someone elses
implementation if you want it to be correct.
> Couldn't you just use the 128 bit block size of Rijndael as a
> (somewhat small) buffer for your traffic? Be honest, what would be the
> overhead from the 128 bit boundaries?
How much overhead? I'd say up to 128 bits. Plus having a 128 bit IV.
Whereas, with ARC4/Ciphersaber, there's only a 80 bit overhead for an
IV, and no need for this kind of blocking.
> AES seems so much more secure in the long run than RC4!
But AES is slower, more awkward, and has more overhead. Also, even if
ARC4 might not be not quite as secure as AES, it is surely *secure
enough* for this application.
--
A solution in hand is worth two in the book.
------------------------------
Date: 27 Feb 2001 04:00:26 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Safe to use DSS key for DH?
Suppose you have a DSS key, of typical size: prime modulus p of 1024 bits,
generator g generating a subgroup of size q, where q is 160 bits.
Would it be safe to use this key for DH and/or ElGamal encryption?
Would you still get ~80 bits of security (based on the modulus size)?
Thanks very much!
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Am I doing something silly by including my gnupghome with my archive?
Date: 26 Feb 2001 20:04:29 -0800
jtnews <[EMAIL PROTECTED]> writes:
> The web site is nice. But how do I know the site isn't recording
> every passphrase it's generating, and then logging my IP address so
> that someone can try to monitor what I'm doing and try to break into
> my accounts?
The passphrases are generated by your browser, not by the web site.
Benjamin Goldberg explained in more detail. The web site never sees
the generated passphrase and it never sees the initial random data
that you enter. So it can't record it.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: CipherText patent still pending
Date: Tue, 27 Feb 2001 04:06:23 GMT
Prichard, Chuck wrote:
>
> The idea to use a key attibute to articulate rotation of a somehow
> modified key has been implemented and demonstrated with no response
> from this newgroup by someone who has claimed to have previously used
> it. I take some comfort in knowing that the idea has been
> intellectually reviewed.
Sorry, but a lack of response does not mean that it has been reviewed,
nor that the idea is good.
The problem is, if you post a cipher, and a revision and a revision and
a revision, etc, people stop looking at your stuff.
> The resulting bit pattern that is applied to a message when a
> sophisticated root key is used has a fair amount of integrity, and the
> algorithm itself though simple, cannot be reverse engineered.
Prove it.
> The integrity of the message depends entirely on the key, as with many
> sophisticated algorithms.
>
> Security is a process, profitability is implementation. I believe that
> somewhere in the middle between sophisticated and simple is a
> practical encryption solution that I can implement in several
> languages.
What advantage does it have over, say ARC4?
> The Active X (OCX) implementation of CipherText can be downloaded from
> the link below.
>
> If I didn't think that my idea to use the key attribute in this
> algorithm was innovative, and possibly worth developing, I would not
> be posting news of my progress to this newsgroup. Recent posts have
> been more plaintive as I have gained a better perspective. But that is
> not to say that I don't approach my work with decency.
How you approach your work doesn't matter. You could be sitting in
front of the computer nude for all we care. It's how much effort you
have made towards cryptanalysis of your cipher which matters. If you
say it's secure, without real proof that you've tried to break it,
noone's going to listen.
What is the best non-brute-force attack you have discovered on your
cipher? If you answer none, then that means that you haven't been
trying to break it, and that there is no reason for us to take you
seriously. If you do have a non-brute-force attack, perhaps one which
works better than brute force with a lower x (where x is rounds, or
something) parameter than you use, but doesn't work with the actual x
parameter, then you have something which we might want to pay attention
to.
Consider: reduced round DES is broken with differential and linear
analysis, with a few chosen/known plaintexts, but full DES is about as
hard to break as brute force, even with lots of chosen plaintexts.
If you haven't found any attacks at all then you haven't been looking at
your cipher hard enough.
--
A solution in hand is worth two in the book.
------------------------------
** 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
******************************
