Cryptography-Digest Digest #374, Volume #9 Sun, 11 Apr 99 13:13:03 EDT
Contents:
My post (on GI) ([EMAIL PROTECTED])
Re: Encrypting Fields in Microsoft Access Database (Dworkin of Amber)
Re: Not a PGP Expert ("Klaus H. Wolf")
Re: Not a PGP Expert (Anthony Stephen Szopa)
Can someone think this through, please. (PGP) (Anthony Stephen Szopa)
Re: Encrypting Fields in Microsoft Access Database (Boris Kazak)
Re: Not a PGP Expert (Tom McCune)
Re: Can someone think this through, please. (PGP) (Albert P. Belle Isle)
Re: Not a PGP Expert (Geoff Thorpe)
Re: Can someone think this through, please. (PGP) (Geoff Thorpe)
Are LFSR's codebook rngs? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: My post (on GI)
Date: Sun, 11 Apr 1999 12:40:14 GMT
Sorry about my post (about GI with the exponents), it was only about 10
seconds after I posted that I realized I was seriously wrong.
However... IF you did post a reply, I didn't get it. Dejanews is backed up
and doesn't work. (I know the posts get out...)
If you want to reply, please do so to my private email:
[EMAIL PROTECTED]
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Dworkin of Amber)
Subject: Re: Encrypting Fields in Microsoft Access Database
Date: Sat, 10 Apr 1999 17:51:11 -0400
In article <7eba8k$c8$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> >wtshaw wrote in message ...
> >>In article <7e3kms$svl$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> >>
> >>> If you want to do encryption, you will need to use C. VB lacks powerful
> >>> bit-bashing operators (AFAIK it doesn't have bit shifting) and forces
> >>> you to use signed operators.
> >>>
> >>BASIC has very powerful string functions. Rotations are no problem either,
> >>merely concatenate a string with itself and use MID$ to select the
> >>starting point and original length in the doubled string. This works
> >>well, use it all the time.
> >
> >Am I missing something?
> >Bit ops and string ops are not the same thing at all.
> >
>
> Unless you feel like wasting 8 bits (or more? does VB force unicode?) to
> express 1 bit ... '111011' ... excuse me while I go puke ...
>
>
If you are interested, I have a crypto DLL usuable from VB that was
created by a third party and posted as freeware. I've tested it against
the stardard test vectors and it checks out.
I've got a similiar problem: I use Access Databases also, and currently
encrypt sensitive fields also, with RC5. Unfortunately, RC5 gives its
output (encrypted text) in 8-bit blocks. This leads to wasted space in
the database as a encrypted 17byte field will need 24 bytes in the
database to hold the encryption (or I will lose the last byte). After
serveral thousand records this adds up quickly.
Is their a secure (comperable to RC5) algorithm that can encrypt strings
smaller that 8 bytes? (I could be happy with 4. If it can encrypt 2 I
will be estactic.)
Thanks.
James Thye
------------------------------
Date: Sun, 11 Apr 1999 17:20:08 +0200
From: "Klaus H. Wolf" <[EMAIL PROTECTED]>
Subject: Re: Not a PGP Expert
Scott Fluhrer wrote:
>
> In article <[EMAIL PROTECTED]>,
> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>
> >Not a PGP Expert
> >
> >Say someone publishes his/her PGP public key and 1,000 people use it and
> >send him/her messages over the Internet using PGP and this public key.
> >
> >Now suppose the NSA has this person's Internet line bugged. The NSA
> >also has the public key. Can the encrypted messages from these 1,000
> >users of this public key have their messages decrypted by the NSA (or
> >anyone else, for that matter) since they have the public key and the PGP
> >software, too?
> If those 1,000 messages make PGP insecure, then PGP is already insecure.
> After all, if the NSA finds it useful, it could generate 1,000 (or a
> trillion) messages to that same public key, without bothering to bug any
> lines.
>
> In general, any public key encryption algorithm must be proof against
> a chosen plaintext attack. After all, the attacker can encrypt vast
> mounds of plaintext of his own choosing.
>
> For that matter, if even a secret key encryption algorithm could be
> broken if the attacker had access to 1,000 messages, then by modern
> standards, that algorithm is considered hopelessly flawed.
In other words: NO, the messages can only be decoded with the secret key.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: Not a PGP Expert
Date: Sun, 11 Apr 1999 08:19:36 -0700
Reply-To: [EMAIL PROTECTED]
Scott Fluhrer wrote:
> In article <[EMAIL PROTECTED]>,
> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>
> >Not a PGP Expert
> >
> >Say someone publishes his/her PGP public key and 1,000 people use it and
> >send him/her messages over the Internet using PGP and this public key.
> >
> >Now suppose the NSA has this person's Internet line bugged. The NSA
> >also has the public key. Can the encrypted messages from these 1,000
> >users of this public key have their messages decrypted by the NSA (or
> >anyone else, for that matter) since they have the public key and the PGP
> >software, too?
> If those 1,000 messages make PGP insecure, then PGP is already insecure.
> After all, if the NSA finds it useful, it could generate 1,000 (or a
> trillion) messages to that same public key, without bothering to bug any
> lines.
>
> In general, any public key encryption algorithm must be proof against
> a chosen plaintext attack. After all, the attacker can encrypt vast
> mounds of plaintext of his own choosing.
>
> For that matter, if even a secret key encryption algorithm could be
> broken if the attacker had access to 1,000 messages, then by modern
> standards, that algorithm is considered hopelessly flawed.
>
> --
> poncho
>
Can someone think this through, please.
1001 people have the same PGP software. One person publishes his public
key. Everyone communicates with the person who publishes the public key.
The NSA or someone else also has the same PGP software and the published
public key. And they also have the 1000 messages sent by the people
communicating with the publisher of the public key because they have the
Internet connection bugged.
Can the NSA or anyone else just take one of these encrypted messages and read
the first byte from the encrypted message then using the same PGP software
and the same public key simply enter one at a time all possible one byte
input until they get the same output for the first byte and conclude that
this must be the same input entered by this one message sender.
After all, the PGP software is the same and the public key is the same. Is
it not true that if the same original message is used that you get the same
encrypted message? Then does it follow that if you use the same first byte
from the original message that you get the same output from this first byte?
And if so, then once you have determined the first original byte that you can
follow the same procedure and determine the second original byte and so on
until the full original message is determined? If not why not?
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Can someone think this through, please. (PGP)
Date: Sun, 11 Apr 1999 08:21:43 -0700
Reply-To: [EMAIL PROTECTED]
Can someone think this through, please.
1001 people have the same PGP software. One person publishes his public
key. Everyone communicates with the person who publishes the public
key.
The NSA or someone else also has the same PGP software and the published
public key. And they also have the 1000 messages sent by the people
communicating with the publisher of the public key because they have the
Internet connection bugged.
Can the NSA or anyone else just take one of these encrypted messages and
read the first byte from the encrypted message then using the same PGP
software and the same public key simply enter one at a time all possible
one byte input until they get the same output for the first byte and
conclude that this must be the same input entered by this one message
sender.
After all, the PGP software is the same and the public key is the same.
Is it not true that if the same original message is used that you get
the same encrypted message? Then does it follow that if you use the
same first byte from the original message that you get the same output
from this first byte? And if so, then once you have determined the
first original byte that you can follow the same procedure and determine
the second original byte and so on until the full original message is
determined? If not why not?
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Subject: Re: Encrypting Fields in Microsoft Access Database
Date: Sun, 11 Apr 1999 08:36:54 -0400
Reply-To: [EMAIL PROTECTED]
Dworkin of Amber wrote:
> ************************
> I've got a similiar problem: I use Access Databases also, and currently
> encrypt sensitive fields also, with RC5. Unfortunately, RC5 gives its
> output (encrypted text) in 8-bit blocks. This leads to wasted space in
> the database as a encrypted 17byte field will need 24 bytes in the
> database to hold the encryption (or I will lose the last byte). After
> serveral thousand records this adds up quickly.
>
> Is their a secure (comperable to RC5) algorithm that can encrypt strings
> smaller that 8 bytes? (I could be happy with 4. If it can encrypt 2 I
> will be estactic.)
>
> Thanks.
>
> James Thye
=========================
A practical suggestion - why not use your favorite block cipher in
stream mode like this:
You access a database (e.g. ACCESS),
This means that you have the "coordinates" of the record,
whatever they are - sheet#, row#, column#, etc.
Concatenate these "coordinates" and make a unique number
which will unambigously "point" to your record.
Now encrypt this number (IV) with your favorite cipher, take as
many bytes from the output ciphertext as needed, and XOR these with
your field, if not enough bytes, increment the IV and encrypt again.
This way you need only 1 secret key, the IV value is readily
available, all fields will be encrypted differently.
Encrypt 1 byte if you wish (keep record length somewhere)
Best wishes BNK
------------------------------
From: [EMAIL PROTECTED] (Tom McCune)
Subject: Re: Not a PGP Expert
Date: Sun, 11 Apr 1999 15:53:01 GMT
=====BEGIN PGP SIGNED MESSAGE=====
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>After all, the PGP software is the same and the public key is the same. Is
>it not true that if the same original message is used that you get the same
>encrypted message? Then does it follow that if you use the same first byte
>from the original message that you get the same output from this first
byte?
>And if so, then once you have determined the first original byte that you
can
>follow the same procedure and determine the second original byte and so on
>until the full original message is determined? If not why not?
Encrypting the same message to the same PGP public key, will always produce
a different ciphertext. This is because the message is actually encypted to
a randomly generated session key - it is the randomly generated session key
that is encrypted to the public key.
=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Privacy 6.0.2
Comment: http://www.Tom.McCune.net - Default: RSA 2047 0x90321F49
iQEVAwUBNxDFRGR4bNCQMh9JAQGh4Qf8CQ3hcK72DZvFBlBKyMXbr+UQHhcSRlEc
rQdGcyZcI+B0RiJuBySR0n9d1QdKhGF1aBAAIjhIVvsFOnDYNvb/H3UN3QklHWaB
39dzca3UfLc2C7H5XFHMJYUzIsCU3PiQDdg5EUU04Ww/SvM+TvbJlbj4CMHwEn/2
2haRpGC3YLioTzwMKEAx4/Hy4AuAybPlKsJVY4SCMkh8BbLnNnURo/srQVM+YToF
tsGmZJrIxiLKmXPo+h9H00/pafNcHaNU1fifrIY4JEVpakCQRDga3YE8WpfxTAIC
sHa/nsK4JAH2CHsX/1dQ3zWLVtohQ850xTr7qfIYGl6JhOIWAHRgIQ==
=e3K1
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Albert P. Belle Isle)
Subject: Re: Can someone think this through, please. (PGP)
Date: Sun, 11 Apr 1999 15:46:57 GMT
Reply-To: [EMAIL PROTECTED]
On Sun, 11 Apr 1999 08:21:43 -0700, Anthony Stephen Szopa
<[EMAIL PROTECTED]> wrote:
>Can someone think this through, please.
>
>1001 people have the same PGP software. One person publishes his public
>key. Everyone communicates with the person who publishes the public
>key.
>
>The NSA or someone else also has the same PGP software and the published
>public key. And they also have the 1000 messages sent by the people
>communicating with the publisher of the public key because they have the
>Internet connection bugged.
>
>Can the NSA or anyone else just take one of these encrypted messages and
>read the first byte from the encrypted message then using the same PGP
>software and the same public key simply enter one at a time all possible
>one byte input until they get the same output for the first byte and
>conclude that this must be the same input entered by this one message
>sender.
>
>After all, the PGP software is the same and the public key is the same.
>Is it not true that if the same original message is used that you get
>the same encrypted message? Then does it follow that if you use the
>same first byte from the original message that you get the same output
>from this first byte? And if so, then once you have determined the
>first original byte that you can follow the same procedure and determine
>the second original byte and so on until the full original message is
>determined? If not why not?
Mr. Szopa:
Unless I've misunderstood your scenario, I believe that the answer is
no, because the first byte of ciphertext from a 64-bit block cipher
(like IDEA) is a function not only of the first byte of plaintext, but
also of the next 7 bytes of plaintext. That's what "confusion and
diffusion" in a well-designed 8-byte (64-bit) block cipher do.
Unless, of course you've found a version of PGP compiled with an 8-bit
block cipher (i.e. a stream cipher).
Albert P. BELLE ISLE
Cerberus Systems, Inc.
================================================
ENCRYPTION SOFTWARE
with Forensic Software Countermeasures
http://www.cerberus-sys.com/~infosec/
================================================
------------------------------
From: Geoff Thorpe <[EMAIL PROTECTED]>
Subject: Re: Not a PGP Expert
Date: Sun, 11 Apr 1999 13:31:04 -0400
Hi,
Anthony Stephen Szopa wrote:
> Can someone think this through, please.
Sure.
>
> 1001 people have the same PGP software. One person publishes his public
> key. Everyone communicates with the person who publishes the public key.
With you so far.
>
> The NSA or someone else also has the same PGP software and the published
> public key. And they also have the 1000 messages sent by the people
> communicating with the publisher of the public key because they have the
> Internet connection bugged.
righty-o.
>
> Can the NSA or anyone else just take one of these encrypted messages and read
> the first byte from the encrypted message then using the same PGP software
> and the same public key simply enter one at a time all possible one byte
> input until they get the same output for the first byte and conclude that
> this must be the same input entered by this one message sender.
hmmm ... now I find you coming a little unstuck ...
>
> After all, the PGP software is the same and the public key is the same. Is
> it not true that if the same original message is used that you get the same
> encrypted message? Then does it follow that if you use the same first byte
> from the original message that you get the same output from this first byte?
> And if so, then once you have determined the first original byte that you can
> follow the same procedure and determine the second original byte and so on
> until the full original message is determined? If not why not?
Not, and I shall attempt to explain why ...
For starters - PGP, as with most public-key systems, utilise symmetric (not
public-key) ciphers to encrypt the actual message (which can be arbitrarily
large) and use the public-key to encrypt the secret key used in the symmetric
cipher (the secret key is randomly chosen and should be different each time PGP
encrypts a message).
So, you're not looking at the "encrypted" message to try and break the public-key
encryption - you'd look there to break the symmetric encryption (ie. try and
guess the secret key without bashing away at the public-key - not a highly
productive exploit as it's not only difficult, but only applies to this single
message - you'll have to start again from scratch next time).
So let's simplify things dramatically to illustrate the way PGP does encryption
(probably doing PGP a drastic dis-service in the process) ...
To encrypt a message with someone's PGP public key PGP does the following
(remember this is conceptual, in reality encoding and other details fleshes this
out a lot);
- it generates a randomly chosen 128-bit (or close-to) key for use in a symmetric
cipher (eg. the IDEA algorithm)
- encrypts the 128-bit key with the PGP public key to get a highly mangled blob
of muck
- sticks that encrypted secret key (blob of muck) at the beginning of the output.
- proceeds to symmetric-encrypt (eg. IDEA) the message using the randomly chosen
secret key and places the output of that after that encrypted secret key (blob of
muck) we put at the beginning.
So there are 2 things you can try and break, and your misconception applies to
both targets ...
- Breaking the public-key encryption of the secret-key,
or
- Breaking the secret-key encryption of the actual message.
Either way - trying input bytes until the first byte of encrypted output matches
the first byte of the encrypted data you're trying to break is all very well -
but it does not mean at all that you've correctly guessed the first byte of the
input ... there may be many choices for the first input byte that generate the
desired output byte, and there may be NO such first byte (without appropriate
choices for the other input bytes) - why? As a detail, I will assume for the
moment that if you're going "byte by byte" then you've made some canonical choice
for all the outstanding input bytes while you're working on the first one and
then the second etc... Well, assume you find a good first byte for a moment, move
to the next byte - if the encryption algorithm is ANY good then with all
likelihood whatever you choose as your second byte will not only affect the
second byte of the output, but the first byte of the output too! Hence, after
finding a good "candidate" for the first byte, choosing a second byte completely
mucks up the choice of the first one to the point that really you have to just
try and find a good 2-byte combination with the desired 2-byte output. Move on to
the 3rd byte and the problem starts over, the choice of the 3rd byte of input
stuffs the output of all the first 3 bytes of output so you end up looking for a
good 3-byte combination with the desired 3-byte output. Continue this conundrum
up to the key-size of the encryption algorithm - eg for cracking IDEA you end up
trying to find a good 128-bit (16 byte) combination that encrypts to the desired
16 byte output - in other words you're doing a brute-force key-search in an
extremely large key-space.
This basic (and overly simplistic) argument applies to both "links" in the chain
- attacking the public-key encryption of the secret key and attacking the secret
key encryption of the message. In fact you'd never attack the public-key like
this because the "input" in that case is probably a 1024-bit public key and
you're trying to build up a private key (effectively find one of the 510-520 bit
factors so that "decrypting" gives you the same data you used the public key to
encrypt). There are MUCH better ways to attack such an immense key-space, namely
trying to factorise the public modulus which is still no mean-feat but less
galatically impossible than brute-force. And before an expert decides to flame me
here, I know that statement assumes that cracking "RSA" is as difficult as
"factoring". If you don't get what THAT means, don't worry.
BTW: In case you're wondering - this "two-stage" process for encrypting (rather
than just using public-key encryption on the message itself) is chosen for 2 main
design reasons;
(1) apart from the "session" bit at the beginning, ie encrypting a temporary
(one-off) secret key using the PGP public key, the rest of the process reduces to
an already familiar process of symmetric encryption.
(2) symmetric encryption is almost always considerably faster than public-key
encryption, and you can optimize symmetric encryption (even stick it into
hardware devices) and then benefit from that in both normal secret-key encryption
and "Public-Key" encryption (eg PGP, S/MIME, SSL, etc). There's also the issue
that it seems to be easier to design a symmetric algorithm with both security and
speed in mind than for public-key algorithms (which tend to be more "algebraic"
than the "bit-twiddling" of the symmetric algorithms).
Hope that helps?
Cheers,
ME
------------------------------
From: Geoff Thorpe <[EMAIL PROTECTED]>
Subject: Re: Can someone think this through, please. (PGP)
Date: Sun, 11 Apr 1999 13:34:58 -0400
I replied to this in the other thread - the "Re: Not a PGP Expert" one ...
Anthony Stephen Szopa wrote:
> Can someone think this through, please.
>
> 1001 people have the same PGP software. One person publishes his public
> key. Everyone communicates with the person who publishes the public
> key.
... [snip]
------------------------------
From: [EMAIL PROTECTED]
Subject: Are LFSR's codebook rngs?
Date: Sun, 11 Apr 1999 16:14:30 GMT
I was reading AC (which is cool...) just ten minutes ago, and was reading
about LFSR's. LFSR's are pretty neat, I even tried a simple 4-bit
implementation in C.
One question though... How do you seed or start a LFSR properly? To me it
seems like a codebook RNG, and the seed picks where you start...
i.e for a 2-bit LFSR an output might be
3, 2, 0, 1 (Seed with 0)
2, 0, 1, 3 (Seed with 3)
Is that right?
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
** 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
******************************
