[Discuss] Has anyone had experience with Social Solutions and/or ETO software?

[Bill Horne]

Thanks for reading this.

I work for a non-profit, which provides services to recently-arrived 
immigrants, such as instruction in English, help with finding jobs, etc.


The organization is considering buying a software package called "ETO", 
owned by Social Solutions Co. (http://www.socialsolutions.com/).


Please feedback any information you have about the company or the ETO 
product. You may contact me privately if you prefer.


Thanks in advance.

Bill

--
Bill Horne
339-364-8487

___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] NSA capabilities

[Richard Pieri]

Tom Metro wrote:

I haven't looked at reference material to refresh my understanding on
this, so it may be wrong, but my recollection is that a CA compromise
would only facilitate man-in-the-middle attacks.


Certificate escrow is the easiest way for a three-letter agency to 
obtain site certificates.




This strikes me as a wild assertion and I don't follow the logic.
References?


CRIME and BREACH are examples of SSL side-channel attacks using known 
text to recover session keys. The more text you have, the more text you 
have available for making such attacks.



Superficially, it sounds like it could be right, as we've all heard of
attack vectors that make use of known plain text. But the NSA doesn't
*know* what is in a given document.


But they do. For example, there are static data in every Google account 
sign-in process. If you capture many sessions of SSL-wrapped data and 
compare them to the clear-text data then you can draw correlations 
between known plain-text and the cipher-text. You can then apply those 
correlations to any arbitrary user's sign-in sessions.





Yeah, but why is that useful? If a repeat[1] occurs every 2^64, and you
send a high volume of messages, that means the NSA will be able to
decrypt 2 messages out of 18,446,744,073,709,551,615 messages. That's
assuming they've brute forced one to begin with.


This assumes a truly random spread. Computers don't do truly random numbers.

--
Rich P.
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] NSA capabilities

[Tom Metro]

[please update the subject; it has nothing to do with KeePassX]

Richard Pieri wrote:
> I assert that the NSA have compromised the public CAs just as they have
> compromised the service providers.

Plausible.


> Certificate + handshake = session key => decrypted session in real time.
> Any user, any session, any time, any reason. No cryptanalysis needed. No
> brute force needed.

I haven't looked at reference material to refresh my understanding on
this, so it may be wrong, but my recollection is that a CA compromise
would only facilitate man-in-the-middle attacks.

The CA is there to sign the customer's public key. I don't think this
necessitates that the CA generate the key-pair or have possession of the
private key. A quick Google confirms this:

http://www.sslshopper.com/what-is-a-csr-certificate-signing-request.html

  A CSR or Certificate Signing request is a block of encrypted text that
  is generated on the server that the certificate will be used on. ... A
  private key is usually created at the same time that you create the
  CSR. ... A certificate authority will use a CSR to create your SSL
  certificate, but it does not need your private key. You need to keep
  your private key secret.

So an NSA agent possessing the CA root could generate a new key pair,
sign it with the CA key, and impersonate any server using that
authority. This could then be used as part of a man-in-the-middle
attack, where you think you are connecting to https://gmail.com/, but
actually you're conversing with an NSA proxy.

Given that most users are unaware of CA changes at sites they visit, the
NSA really only needs one CA root from a common CA and they could
generate impersonation certs at will. (Some "unified threat management"
appliances (a.k.a. corporate proxy servers) do this.)

But these impersonation certs don't help them recover the session key
for a captured SSL session. The NSA could still issue a security letter
to the server owner, and get the private key that way, but that
constrains them much more that what you alluded to.

(Undoubtedly there are CAs who, as a matter of convenience, generate the
key pair, and could be compelled by the NSA to retain the private key. I
believe when I generated a cert for S/MIME at StartSSL they generated
the key pair. Some CAs use browser side tech - ActiveX or JS - to
generate the key. Clearly your best bet is to use known and trusted open
source tool to generate the key pair on your own machine, and only
submit a CSR to the CA.)


> The more that is encrypted, the more known text the NSA has available
> for side-channel attacks. The more that is encrypted, the more
> chances of a hash collision occurring or a pseudo-random key being
> reused. Scaling up works in the NSA's favor...

This strikes me as a wild assertion and I don't follow the logic.
References?

Superficially, it sounds like it could be right, as we've all heard of
attack vectors that make use of known plain text. But the NSA doesn't
*know* what is in a given document.

I could see this applying in subsets if cases. For example, say two
businesses start encrypting their email exchanges. The NSA knows from
past history of captured communications between two parties that their
plaintext includes a bunch of fixed form fields. The unencrypted
metadata clues in the NSA as to who is communicating, and they can then
use the historical known plaintext to mount an attack.

This is only going to help break a session key. I'm not sure this
approach is of any help in breaking asymmetric keys.

If amassing plaintext and corresponding encrypted text was really all
that useful, the NSA could generate warehouses full of it themselves.
The algorithms in use are almost always well known. The only thing
real-life examples buy them is if someone was generating gobs of
encrypted data for a known plaintext using the same session key.


> ...more chances...a pseudo-random key being reused

Yeah, but why is that useful? If a repeat[1] occurs every 2^64, and you
send a high volume of messages, that means the NSA will be able to
decrypt 2 messages out of 18,446,744,073,709,551,615 messages. That's
assuming they've brute forced one to begin with.

1. http://en.wikipedia.org/wiki/Pseudorandom_number_generator#Periodicity


> ...of a hash collision occurring...

That depends on the algorithm, of course. SHA-1 is popular and used in
S/MIME. It has an estimated theoretical collision[2,3] probability of
about 2^60 or 1.15e+18. Is that going to be impacted by a few billion
people sending a few trillion encrypted documents per year? At that rate
you'd see a collision once every ~1 million years (1.15e18/1e12).

If you don't feel comfortable with this, use SHA-2.

2. http://en.wikipedia.org/wiki/SHA-1#Attacks
3.
http://en.wikipedia.org/wiki/Comparison_of_cryptographic_hash_functions#Cryptanalysis


I think Kent Borg is following solid reasoning when he says that
encrypting everything will increase costs for the NSA to the point that
the chance

Re: [Discuss] KeePassX

[Richard Pieri]

Jerry Feldman wrote:

It may not be easier, but it would be more effective when monitoring
specific people.


Yes, well, we all know how well the USA PATRIOT Act and Protect America 
Act have curtailed warrantless surveillance of the general population.


The most effective use of large-scale computing facilities is running 
them full bore all the time. Anything less than that is a waste of 
power, cooling, operators' salaries and the cost of the hardware itself. 
If the NSA has an RSA factoring supercomputer capable of factoring RSA 
keys in useful time then then the most effective use of that facility is 
factoring every RSA key the NSA scoops up.


--
Rich P.
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] KeePassX

[Jerry Feldman]

It may not be easier, but it would be more effective when monitoring 
specific people.


On 08/14/2013 10:03 AM, Richard Pieri wrote:

Jerry Feldman wrote:

recipient's public key), so to make this bidierctional they need to
break 2 keys, so the job gets more difficult. Breaking the session key


The public key is more easily recovered from, say, a public key 
server. This requires no effort at all.


It may be easier -- and it will become easier as time passes -- to 
factor the prime numbers that comprise the public key and use them to 
recreate the private key. The strength of RSA is that it is very, very 
computationally expensive to factor large prime numbers.



Kent Borg wrote:
> if you are doing SSL with that public key, the key exchange cannot be
> understood by a passive observer, so passively recording the packets
> will not let someone later decrypt the exchange.

If you have the certificate and you can snoop the session handshake 
then you can recover the session key and decrypt the session. The 
security of the secret key is paramount to every PK system.


I assert that the NSA have compromised the public CAs just as they 
have compromised the service providers. This is computationally very 
inexpensive. It simply requires the FISC to fire up Word and print out 
a few national security letters. The NSA either have copies of all of 
the certificates issued by public CAs or can obtain them upon request.


As you repeatedly point out, the NSA wants to store everything. 
"Everything" includes SSL handshakes.


Certificate + handshake = session key => decrypted session in real 
time. Any user, any session, any time, any reason. No cryptanalysis 
needed. No brute force needed.





--
Jerry Feldman 
Boston Linux and Unix
PGP key id:3BC1EB90
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90

___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] KeePassX

[Richard Pieri]

Kent Borg wrote:

"Everything" is just too big to afford if not at really low bulk rates.
Even for the NSA.


It's the other way around. The more that is encrypted, the more known 
text the NSA has available for side-channel attacks. The more that is 
encrypted, the more chances of a hash collision occurring or a 
pseudo-random key being reused. Scaling up works in the NSA's favor 
rather than to its detriment in cases where they don't already have near 
real time decryption. Scaling up changes the nature of the problem from 
traditional cryptanalysis to big data storage and retrieval. This is a 
MUCH simpler problem, one solved by -- you got it -- the same big data 
companies that have been handing our information over to the NSA all along.


--
Rich P.
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] KeePassX

[Kent Borg]

On 08/14/2013 12:45 PM, Richard Pieri wrote:

Do you finally get what I've been on about?


You have good points.

But I still return to my harping that anything that bends the cost curve 
up for the NSA ruins their idea of snooping on everything. For example, 
the third of SSL traffic with good key exchange is a problem for them.


"Everything" is just too big to afford if not at really low bulk rates.  
Even for the NSA.



-kb

___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] KeePassX

[Richard Pieri]

Kent Borg wrote:

I didn't realize that SSL was so stupid.  Rather important technology
was left out of SSL, even though it was already two years old at that
point.  Grrr.


It wasn't left out. It was intentionally excluded. Back in the day, 
Netscape was under ITAR munitions restrictions. They couldn't export a 
browser with strong authentication and encryption like Kerberos or PGP. 
So they cobbled together a weak, ad-hoc system based on the NSA-backed 
X.509 spec that passed export restrictions. That system is SSL.


Do you finally get what I've been on about?

--
Rich P.
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] KeePassX

[Kent Borg]

On 08/14/2013 10:03 AM, Richard Pieri wrote:
Certificate + handshake = session key => decrypted session in real 
time. Any user, any session, any time, any reason. No cryptanalysis 
needed. No brute force needed.


Yes, if the communications uses a broken (lack of) key exchange. 
Stupidly, SSL only recently got improved to support 
perfect-forward-security, Safari and Internet Explorer don't really 
support it, and the PRISM companies, coincidentally, don't support it.


The good news is that a third of Firefox, Crome, and Opera SSL traffic 
uses good key exchange and not susceptible to passive snooping or 
after-the-fact decryption.


I didn't realize that SSL was so stupid.  Rather important technology 
was left out of SSL, even though it was already two years old at that 
point.  Grrr.


An interesting article on this: 
http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html 



The fact that the traffic with the PRISM companies allows this easy 
decryption underlines that efficiencies matter for the NSA.  Every 
monkey wrench helps...



-kb
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] KeePassX

[Jerry Feldman]

On 08/14/2013 07:36 AM, Kent Borg wrote:

On 08/14/2013 06:34 AM, Jerry Feldman wrote:
Agreed. But, breaking the session key only works for a single message 
or a single session. If they want to target a specific individual, 
breaking the RSA/DSA keys will give them access to all encrypted 
messages. (within the context is that a sent message is encrypted by 
the recipient's public key), 


Yes, breaking the RSA/DSA key will let them read files or e-mails 
(effectively a file) encrypted with that public key.  But I think that 
if you are doing SSL with that public key, the key exchange cannot be 
understood by a passive observer, so passively recording the packets 
will not let someone later decrypt the exchange.

Basically, there are 3 groups of those who want to hack encryption
1. Governments - they have resources and if they want to get your 
information they have tools to do it.
2. criminals who want your information. Unless you are very wealthy, 
there is very small chance they will try to break your encryption. 
Simple cost benefit.
3. random hackers. There are people out there with skills and some 
resources. It is hard to protect against these people because of their 
skills. While they don't have acres of supercomputers they have the 
skills to build or use low cost clusters.


So, I'm not really worried. If the NSA or FBI wanted to get my 
information and read my emails they can do it, and there is very little 
that I can do other than remain under the radar.


--
Jerry Feldman 
Boston Linux and Unix
PGP key id:3BC1EB90
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90

___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] KeePassX

[Kent Borg]

On 08/14/2013 09:38 AM, Edward Ned Harvey (blu) wrote:

From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss-
bounces+blu=nedharvey@blu.org] On Behalf Of Kent Borg

Bruteforcing
128-bits is impossible.  Bruteforcing 256-bits is 128-bits times as
impossible.

Careful here.  Someday, there might exist a perfect block cipher, but at 
present, all known block ciphers (including AES) suffer from the even-vs-odd 
permutation problem, which means, that a cipher with 128 bit key is only as 
strong as an ideal cipher with 64 bits.  If you want 128 bit strength (BigO 
2^128 operations to brute force attack), you have to use the 256 bit key.


But you don't mean AES-128 can be broken today with 2^64 operations, do 
you?  That sounds wrong--or theoretical.


According to the current Wikipedia: "The first key-recovery attacks on 
full AES [...] requires 2^126.1 operations to recover an AES-128 key."  
(It seems like this is the kind of Wikipedia article that tends to be 
accurate.)  Then they move on to side-channel attacks...


Likely the NSA has a better attack.  Maybe they have a *way* better 
attack and they can shave off another couple dozen bits.  Still, a 
100-bits plus of brute force is not something they can do on the cheap.  
They have to want it.  It has to be a priority.  And they can't get it 
tomorrow.  Or next week.  And I bet not a long time after that.


-kb

___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] KeePassX

[Richard Pieri]

Jerry Feldman wrote:

recipient's public key), so to make this bidierctional they need to
break 2 keys, so the job gets more difficult. Breaking the session key


The public key is more easily recovered from, say, a public key server. 
This requires no effort at all.


It may be easier -- and it will become easier as time passes -- to 
factor the prime numbers that comprise the public key and use them to 
recreate the private key. The strength of RSA is that it is very, very 
computationally expensive to factor large prime numbers.



Kent Borg wrote:
> if you are doing SSL with that public key, the key exchange cannot be
> understood by a passive observer, so passively recording the packets
> will not let someone later decrypt the exchange.

If you have the certificate and you can snoop the session handshake then 
you can recover the session key and decrypt the session. The security of 
the secret key is paramount to every PK system.


I assert that the NSA have compromised the public CAs just as they have 
compromised the service providers. This is computationally very 
inexpensive. It simply requires the FISC to fire up Word and print out a 
few national security letters. The NSA either have copies of all of the 
certificates issued by public CAs or can obtain them upon request.


As you repeatedly point out, the NSA wants to store everything. 
"Everything" includes SSL handshakes.


Certificate + handshake = session key => decrypted session in real time. 
Any user, any session, any time, any reason. No cryptanalysis needed. No 
brute force needed.


--
Rich P.
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] KeePassX

[Edward Ned Harvey (blu)]

> From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss-
> bounces+blu=nedharvey@blu.org] On Behalf Of Kent Borg
> 
> Bruteforcing
> 128-bits is impossible.  Bruteforcing 256-bits is 128-bits times as
> impossible.

Careful here.  Someday, there might exist a perfect block cipher, but at 
present, all known block ciphers (including AES) suffer from the even-vs-odd 
permutation problem, which means, that a cipher with 128 bit key is only as 
strong as an ideal cipher with 64 bits.  If you want 128 bit strength (BigO 
2^128 operations to brute force attack), you have to use the 256 bit key.

I don't have a reference I can point you to on the internet.  I read this in 
Cryptography Engineering (Schneier, Ferguson, Kohno).
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] KeePassX

[Kent Borg]

On 08/13/2013 04:30 PM, Daniel Barrett wrote:

In the absence of the 4096-bit private half of my key, how hard is it
to decrypt the session key by brute force and thereby decrypt file
Foo? Do the time arguments from this KeePass discussion apply?


There are three approaches they can take, sorted from fuzzy to known:

1) They can try to break your public key into a private key and then get 
the session key directly.


2) They can try to break the symmetric encryption directly by exploiting 
some weakness in the encryption algorithm that somehow offers an efficiency.


3) They can try to bruteforce the key for the symmetric encryption.

#1.  I think yesterday someone posted a pointer to a PDF that said that 
a 4096 public key is equivalent to a 118-bit symmetrical key. This is an 
estimate, and expect the estimate to fall over time. Public key 
cryptography depends on mathematical problems that are easy to run one 
direction and very much harder to run the other way (multiplication vs. 
prime factoring, in the case of RSA).  There are major risks here.  
Obviously, a breakthrough in factoring is feared.  A breakthrough in 
quantum computing is also touted as being a risk, but as with most 
things quantum, I don't pretend to really understand that.


#2.  DES is known to have weaknesses beyond its short keysize. During 
its development the NSA quietly made changes that made it more robust, 
in a way that was not publicly understood until years later.  AES or 
CAST or whatever, might also have a weakness.  A symmetric cypher is 
really just mixing and mashing your data in a predictable but 
complicated way.  If someone can better understand the "complicated" 
part, there could be a hole that makes it easier to decypt a message.


#3.  This is the most concrete one to understand, and the hardest for 
the NSA to accomplish.  If this is the best the NSA can do, you can do 
the math on the number of possibilities.  You can imagine a parallel 
computer to speed it up.  You can compare large key sizes with the size 
and age of the universe and conclude they are safe. Bruteforcing 
128-bits is impossible.  Bruteforcing 256-bits is 128-bits times as 
impossible.



A related #4 is when there is a passphrase used to generate a 
symmetrical key.  If your passphrase has predictable aspects the search 
space can start common passwords, common phrases in our language, 
initial letters for those phrases, dictionary words, common 
misspellings, and then start doing permutations on on those. The search 
quickly becomes truly enormous, but still far smaller than just 
searching every combination, and even if you are forced to try every 
key, might as well start with common ones and hope to get lucky.  In the 
case of encrypting a file with a public key (and actually a randomly 
chosen symmetric key) there is no passphrase. But, your copy of your 
private key needs to be protected.  It will be likely be encrypted with 
a symmetric key, derived from a passphrase that you chose.  Make that 
passphrase good.  And don't let the other guy get a copy of your private 
key at all.


Finally, #5, is finding the weakest link.  From one end of the 
communication to the other, the encryption might be great, but something 
else goes wrong.  Maybe the "randomly" chosen key wasn't very random.  
Maybe the encryption was just done wrong by someone who didn't 
understand.  Maybe there is a simple bug in the implementation.  Maybe 
there is spyware in your computer.  Maybe there is a hidden camera 
mounted over your keyboard.  Maybe a sysadmin got a National Security 
Letter.  The whole system needs to be secure, it can be attacked at any 
point.


But all that is classic spy-vs-spy.

The new world is the NSA wants everything, and they need to be efficient 
about it to get everything, so anything the interferes with the 
efficiency hurts their efforts.  Maybe there is a weakness in AES.  
Okay, make them spend a lot of computrons exploiting that and your 
message becomes exempt from their "everything" approach.


They can handle an limited number of exemptions.


-kb

___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] KeePassX

[Kent Borg]

On 08/13/2013 04:47 PM, Jerry Feldman wrote:

Let's take the situation: NSA is watching you.
They can intercept your email, crack your RSA or DSA key, and then 
they can discover the session keys. They are not interested in 
everybody's random encrypted emails, so if they focus on individuals 
who  interest them, the problem becomes smaller.


Yes, they certainly have real humans and real computer power look at 
specific things they decide to look at, but the recent news is their 
model and goal is to look at everything.  Everything.  And when that is 
their goal, economics and efficiencies matter.  And any monkey wrench 
that bends their cost curve matters.



-kb

___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] KeePassX

[Kent Borg]

On 08/13/2013 05:04 PM, Jerry Feldman wrote:

The real issue is determining who and what to monitor.


That is the key.  For years the idea is that the NSA is selective and 
decides what traffic to analyze, what messages to try to decrypt, what 
targets to actively attack (with such things as a man-in-the-middle 
attack).  They can't attack everything, they have to choose.  Much of 
this discussion is based in this traditional world.


Except the recent news blows that out of the water.

They want *everything*.

That means that they don't have time to attack any real encryption, they 
are going after plaintext--and trivial encodings of plaintext. Yes, they 
still will do more traditional work, but all of that is removed from the 
"everything" efforts.  The costs are completely different, their 
capacity to do real crypto work is quite finite. Their "everything" 
efforts are infinite, but only as long as they are efficient.


I am arguing that every measure that makes their "everything" efforts 
inefficient is a blow against this blanket surveillance.


-kb
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] KeePassX

[Gregory Boyce]

That depends on the cipher in use and if it supports perfect forward
secrecy or not.

http://en.wikipedia.org/wiki/Perfect_forward_secrecy
On 08/14/2013 06:34 AM, Jerry Feldman wrote:

> Agreed. But, breaking the session key only works for a single message or a
> single session. If they want to target a specific individual, breaking the
> RSA/DSA keys will give them access to all encrypted messages. (within the
> context is that a sent message is encrypted by the recipient's public key),
>

Yes, breaking the RSA/DSA key will let them read files or e-mails
(effectively a file) encrypted with that public key.  But I think that if
you are doing SSL with that public key, the key exchange cannot be
understood by a passive observer, so passively recording the packets will
not let someone later decrypt the exchange.


-kb

__**_
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/**listinfo/discuss
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] KeePassX

[Edward Ned Harvey (blu)]

> From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss-
> bounces+blu=nedharvey@blu.org] On Behalf Of Daniel Barrett
> 
> In the absence of the 4096-bit private half of my key, how hard is it
> to decrypt the session key by brute force and thereby decrypt file
> Foo? Do the time arguments from this KeePass discussion apply?

The effective strength of RSA or DSA 4096 is 128 bits or 256 bits, depending on 
some stuff I'll just allude to and brush over.  This means 2^128 or 2^256 
"operations" to be guaranteed a breach, where "operations" is a potentially 
complex and time consuming constant.  

Essentially, 2048 bit or 4096 bit RSA or DSA keys are incredibly strong.  Until 
somebody figures out how to do fast prime factorization.
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] KeePassX

[Kent Borg]

On 08/14/2013 06:34 AM, Jerry Feldman wrote:
Agreed. But, breaking the session key only works for a single message 
or a single session. If they want to target a specific individual, 
breaking the RSA/DSA keys will give them access to all encrypted 
messages. (within the context is that a sent message is encrypted by 
the recipient's public key), 


Yes, breaking the RSA/DSA key will let them read files or e-mails 
(effectively a file) encrypted with that public key.  But I think that 
if you are doing SSL with that public key, the key exchange cannot be 
understood by a passive observer, so passively recording the packets 
will not let someone later decrypt the exchange.



-kb

___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Re: [Discuss] KeePassX

[Jerry Feldman]

Agreed. But, breaking the session key only works for a single message or 
a single session. If they want to target a specific individual, breaking 
the RSA/DSA keys will give them access to all encrypted messages. 
(within the context is that a sent message is encrypted by the 
recipient's public key), so to make this bidierctional they need to 
break 2 keys, so the job gets more difficult. Breaking the session key 
works if they want to look at random messages, but breaking the RSA/DSA 
keys woprks better when they have a specific target in mind.


On 08/13/2013 05:40 PM, Richard Pieri wrote:

John Abreau wrote:

Nope, sorry, each individual message has its own unique session key.
Cracking the session key on one particular message tells you nothing
about the session key on subsequent messages.


If I decrypt the message by breaking the session key then yes, I can 
only decrypt that one message.


But, if I can do this then I know what the session key is. This means 
that I have a 100% known plain-text correspondence with the encrypted 
session key. This may make it easier to attack a given RSA or DSA key 
pair.


Attacking the RSA or DSA asymmetric keys directly is believed to be 
more difficult than attacking the session key. Given that the NSA has 
approved both for commercial use, just as they have approved AES for 
commercial use, I assume that they are aware of exploitable weaknesses 
in both.





--
Jerry Feldman 
Boston Linux and Unix
PGP key id:3BC1EB90
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90

___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss