Subject: Re: [saag] fyi: tcpcrypt draft

From: Sean Turner <[email-masked]>
Date: Sun, 24 Jul 2011 13:17:51 -0400

This draft is being presented at the TSVAREA meeting Thursday morning 
(room:205ABC).  Both Stephen and I have other engagements, but if you're 
not headed to another session at that time then it would be great if 
some of you would head there to interact with the presenter(s).

spt

On 5/8/11 12:31 PM, Sean Turner wrote:
> The authors of the following draft have asked that I forward this to
> saag for comment:
>
> https://datatracker.ietf.org/doc/draft-bittau-tcp-crypt/
>
> They also noted that there's a Usenix Security paper and video:
> http://tcpcrypt.org/docs.php
>
> Please direct discussion to [email-masked].
>
> Cheers,
>
> spt
>
>
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Mark Handley <[email-masked]>
Date: Sun, 24 Jul 2011 18:56:15 +0100

Just a brief update:

 - We conducted a pretty extensive study into whether extending TCP in
this way would be deployable, or whether we've missed something, and
we've done more testing.  The draft paper is here:

http://nrg.cs.ucl.ac.uk/mjh/tmp/mboxes.pdf

  The one thing that came out of this is that you cannot reliably MAC
TCP sequence numbers in today's Internet.  Far too many paths rewrite
them, even if they don't do anything else odd to TCP flows.  There'll
be a new draft right after the IETF that reflects this - we now MAC
the offset from the initial sequence number instead.

- We're looking at a library that provides a shim authentication layer
over tcpcrypt at the moment.  In part, this is to let tcpcrypt play
nicely with DANE - this seems a good match.  Early days on this at the
moment though.

Cheers,
Mark

On 24 July 2011 18:17, Sean Turner <[email-masked]> wrote:
> (room:205ABC).  Both Stephen and I have other engagements, but if you're not
> headed to another session at that time then it would be great if some of you
> would head there to interact with the presenter(s).
>
> spt
>

---

From: David McGrew <[email-masked]>
Date: Mon, 25 Jul 2011 13:48:48 -0700

Hi Mark,

I asked a bunch of questions on tcpcrypt back in May, on this mail  
thread.  Would it be possible for you or the other authors to respond  
before the presentation on Thurs?

David

---

From: Mark Handley <[email-masked]>
Date: Wed, 27 Jul 2011 16:33:40 -0400

Forwarding, because I don't think Andrea's on the saag list...

---------- Forwarded message ----------
From: Andrea Bittau <[email-masked]>
Date: 27 July 2011 14:42
Subject: Re: [saag] fyi: tcpcrypt draft
To: David McGrew <[email-masked]>
Cc: [email-masked], Sean Turner <[email-masked]>, [email-masked],
[email-masked]

Sorry for the late reply!  Comments inline.

On Tue, May 10, 2011 at 04:03:58PM -0700, David McGrew wrote:
> Hello Tcpcrypt authors,
>
> I have skimmed the internet draft and the USENIX Security paper on
> tcpcrypt, and while it is interesting and thought-provoking work, I
> have a hard time understanding what the goals of the I-D are
> relative to the TCP standard.  The draft says "Standards Track";
> would Experimental be more appropriate?  It mentions the following
> objectives:

We don't have a strong opinion about a standard's track vs.
experimental categorization, so experimental is fine.  We'll be happy to
reevaluate in the future.

> "Tcpcrypt maintains the confidentiality of data transmitted in TCP
> segments against a passive eavesdropper.  It can be used to protect
> already established TCP connections against denial-of-service
> attacks involving injection of forged RST segments or
> desynchronizing of sequence numbers."  Yes, but TLS and IPsec
> perform the former function, and IPsec and TCP-AO perform the
> latter.  In addition, running TCP over DTLS would also accomplishes
> the latter function; this practice is done in some (so-called)
> SSLVPNs.

Yes, tcpcrypt immediately offers confidentiality of data against a
passive eavesdropper, which is better than the status quo, but this is
not our ideal situation.  Our ideal situation is to provide strong
secrecy and integrity protected by mutual authentication of the two
endpoints.  The benefit of tcpcrypt is that it immediately provides this
protection against passive eavesdroppers, while also making it as easy
and efficient as possible to achieve the stronger security when
applications can make use of appropriate authentication credentials.

While IPSec is capable of providing opportunistic encryption, it does
not do so "immediately".  In particular, plenty of machines run
operating systems that support IPSec, yet do not use IPSec for security.
Tcpcrypt, by contrast, is designed to be "on by default." It therefore
has to require less configuration and provide better interoperability
than IPSec with middleboxes such as NATs.  IPSec, because it is at the
network layer, is also harder to integrate with application-level
notions of authentication, which are typically tied to a particular TCP
connection rather than a pair of machines.  (E.g., it is reasonable to
run two different browsers on the same client, and use those two
browsers to log into the same web site with two different accounts.)

TLS is closer to tcpcrypt.  It could also be used for opportunistic
encryption.  However, compared to tcpcrypt, TLS still requires more
configuration, is not compatible with all TCP applications, and has a
heavier impact on server performance.  All of these factors make it
harder to enable TLS by default.  The combination of TLS and TCP-AO (the
latter requiring setting up a pre-shared key between endpoints) would be
harder still to make on by default.  Finally, the fact that TLS does not
always provide forward secrecy is a disadvantage compared to tcpcrypt.

Being a single, integrated, zero-configuration (once kernels support it)
solution that can be incrementally deployed puts tcpcrypt at an
advantage compared to other solutions that need to be used in tandem for
more complete security, each coming with their own configuration
requirements.

> "Finally, applications that perform authentication can obtain
> end-to-end confidentiality and integrity guarantees by tying
> authentication to tcpcrypt Session ID values."  This seems like a
> potentially useful feature, though it seems similar to channel
> binding (RFCs 5056 and 5929).

Yes it's the same concept and we implemented in tcpcrypt's core to allow
briding to app-level authentication.  We also use the same mechanism to
name sessions for session caching.

> "Tcpcrypt is designed to require relatively low overhead,
> particularly at servers, so as to be useful even in the case of
> servers accepting many TCP connections per second."  The idea of
> batching signatures seems like a useful contribution that could be
> put to good use by servers that are under heavy loads.  But why not
> implement this idea in a way that could be used by multiple
> applications and protocols?   It should not be hard to define a
> format for digital signatures that carries a few extra hash values,
> and allows a verifying party to check the signature on the message
> that they care about, while ignoring the rest.  The idea of
> reversing the client/server association between RSA
> encryption/decryption is a pragmatic way to help out servers, though
> it is tied to a specific algorithm (the results would be quite
> different for ECDH or ECDSA, say).  Both of those performance
> optimizations are definitely interesting, but I don't understand why
> the best way utilize those ideas would be through a new
> cryptographic protocol within the TCP layer.

The optimization is independent of tcpcrypt.  In fact, tcpcrypt's
standard doesn't mandate nor specify any authentication mechanisms -
it's left to the application.  Batch signing is just an example of
how one might authentication tcpcrypt sessions.  It can be done with
other protocols if they permit it.

Note that this optimization cannot be used in stock SSL because of SSL's
design.  SSL requires the server to perform an (expensive) private key
operation per client because each client sends over a unique encrypted
pre-master secret which the server decrypts to prove its identity (i.e.,
that it knows the private key for the certificate it advertised to the
client).  So to leverage batch signing we need to design protocols that
allow for it, hence why we created tcpcrypt clean-slate.

We do have a drop-in replacement for OpenSSL that attempts to use
tcpcrypt+batch signing if able otherwise reverting to SSL.  This can be
used by many existing SSL applications without modifying them but just
replacing the system's SSL library.

> I also have some comments on some other points.  The USENIX Security
> paper mentions the goal of ubiquitous encryption (though the draft
> does not).  Requiring changes to the TCP stack would hinder
> deployment and work against the goal of ubiquity.

The protocol is designed with incremental deployment in mind which
hopefully will lead to ubiquitous encryption.  Specifically:

* It tries tcpcrypt and falls back to TCP gracefully.  The app doesn't
* have to know anything about tcpcrypt.

Sure, modifying the TCP stack hinders deployment.  So would modifying
all applications (which is potentially even more difficult).  We need to
modify something to get encryption, and for the reasons just mentioned
about incremental deployment we think TCP is the right place to do it.

> The draft describes the RSA public keys as "ephemeral", and the
> companion paper says that the protocol achieves forward secrecy.
> However, if it was really the case that a new RSA keypair was
> generated for each exchange, then the performance would be
> significantly worse than what is shown in the paper, because the
> cost of that operation is significantly higher than that of RSA
> decryption.   I think the claims and/or guidance to implementers
> needs to be clarified.

It's not perfect forward secrecy (i.e., one key per connection).  More
like one key per 10 minute window or whatever the system is configured
to.

> The Security Considerations section looks like boilerplate, while it
> seems that there is a lot to be discussed, such as the security
> properties of Session IDs.

Yes, we agree - this is just a first draft.  Well work on improving
that.  If this is taken on by the IETF, no doubt things we haven't
thought of will be pointed out.

> Is it possible to relate the protocol to a previously analyzed
> protocol?   It is similar to ISO/IEC 11770-3, in that it relies on
> public key encryption of nonces, without signatures.  Perhaps there
> is some analysis of that protocol, or of a protocol with cryptosuite
> negotiation, that could be leveraged.  The companion paper does have
> a brief analysis of the security of the protocol, but it would be
> good if it were possible to benefit from detailed analyses of all
> aspects of protocol security.  (I do realize that the analysis is
> made easier by the relative simplicity of the protocol; that's a
> good thing.)

We agree, and we'll work on this.

> The security analysis defines the parameter "k ~ 256 is the minimum
> of the min-entropy of a public key".  Surely that doesn't match the
> 2048-bit RSA examples in the paper?

The paper says: "where k ~ 256 is the minimum of the min-entropy of a
public key, or the length in bits of NS or NC."

NS and NC are random 256-bit values, so their min entropy is 256.  The
public key is a product of two 1,024-bit primes, so its min entropy is
much higher than 256.

The min entropy is just the probability of running the key generation
function twice and getting the same public key out the second time.
This has nothing to do with the difficulty of breaking RSA (which for
2,048-bit keys would be sort of equivalent to a 112-bit symmetric key).
The difficulty of breaking RSA is irrelevant to our reduction.  We are
saying that if you can break tcpcrypt, we can break the public key
algorithm or one of the other cryptographic functions in a "black box"
way, without regard to what the algorithms actually are.

> As a side note, I am surprised to see a proposal to add so much
> cryptographic functionality into the TCP standard, considering that
> not many years have passed since the transport area declined to add
> (much simpler) key transport functionality into TCP in support of
> TCP-AO.  Perhaps "Experimental" was intended, or perhaps I have
> missed or misunderstood some aspect of this work.

We think the perceived use case for TCP-AO was a replacement for TCP-MD5
in BGP sessions.  Of course TCP-AO is broader than that, but the
perceived use case may have influenced the previous decision.

---

From: Joe Touch <[email-masked]>
Date: Wed, 27 Jul 2011 14:59:39 -0700

Hi, Mark (et al.),

I'm cc-ing this to the TSVWG mailing list for the benefit of those 
attending TSVAREA, where the presentation will occur tomorrow AM.

Since this is the second IETF transport presentation (the first was in 
TCPM at IETF 80), I hope this presentation will clarify how the current 
tcpcrypt code uses the existing TCP option space.

In specific, it appears to use *two* unassigned TCP option codepoints 
(69 and 70), rather than experimental codepoints (and, IMO, it should 
use the latter instead).

I hope the presentation this time will address the plans to correct the 
currently deployed code to appropriately use the experimental codepoints.

Joe

---

From: Mark Handley <[email-masked]>
Date: Thu, 28 Jul 2011 13:15:48 -0400

On 27 July 2011 17:59, Joe Touch <[email-masked]> wrote:
> Since this is the second IETF transport presentation (the first was in TCPM
> at IETF 80), I hope this presentation will clarify how the current tcpcrypt
> code uses the existing TCP option space.
>
> In specific, it appears to use *two* unassigned TCP option codepoints (69
> and 70), rather than experimental codepoints (and, IMO, it should use the
> latter instead).

Hi Joe,

You're correct that our code is currently using two unassigned
codepoints, and we should not be doing so.  I've looked into what we
should do, and the problem is that there are deployed products using
the two experimental options.  We don't wish them to interfere with
our experiments, nor do we wish to interfere with their experiments.

But using unassigned ports is bad too.  I've talked with Wes and
David, and we're working on figuring out the least bad solution.  Wes
will raise the issue with the IESG, and we'll implement whatever they
decide is best.

 - Mark

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 28 Jul 2011 13:35:21 -0400

I was not able to be at today's meeting. So, apologies if my question has been discussed during the meeting already. 

It is definitely a desirable goal to have more end-to-end security being used. 
There are obviously lots of details questions on how to get there, both from the technical side but also from the incentive side. 

Various mechanisms exist already today offering e2e security but what I do not get is how this mechanism will get us to the desired state. 
How is this mechanism going to help with companies who do not want to deploy TLS beyond their initial authentication step? 
For many of them it would be super-easy to just apply the already established TLS session up and protect further message exchange as well. 

Ciao
Hannes

On May 8, 2011, at 12:31 PM, Sean Turner wrote:

> The authors of the following draft have asked that I forward this to saag for comment:
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Jul 2011 11:04:39 -0700

On 7/28/2011 10:15 AM, Mark Handley wrote:
> On 27 July 2011 17:59, Joe Touch<[email-masked]>  wrote:

Hi, Mark,

It's hard to understand how these could interfere, since experiments are 
not supposed to be widely deployed. The only interference would be if 
theirs were widely deployed *and* yours were too, which means you're 
both using those codepoints inappropriately.

> will raise the issue with the IESG, and we'll implement whatever they

AOK. It'd be useful to note this in your talk, IMO.

Thanks,

Joe

---

From: Mark Handley <[email-masked]>
Date: Thu, 28 Jul 2011 14:18:09 -0400

> For many of them it would be super-easy to just apply the already established TLS session up and protect further message exchange as well.

Hi Hannes,

Can I just clarify what you're asking?  Are you referring to companies
that use TLS to secure the initial login to their site, and after that
do unencrypted TCP?

The other tcpcrypt folks may want to chime in, as they're better
qualified than I am, but from my point of view, I don't view tcpcrypt
as being a replacement to TLS in this scenario.  It might go something
like this:

1. Both client and server deploy an SSL library like our one that also
supports tcpcrypt.   WIthout changes to the apps, the SSL library
probes using the getsockopt(SESSION_ID) to see if tcpcrypt enabled
itself and whether the remote end signalled tcpcrypt-based auth
support.

   * If so, the server signs the session ID and sends it to the
client.  Batch signing can speed this up if necessary.  The channel
now provides TLS-equivalent security, except that the connection is
also protected against RST and other TCP desynchronization attacks.

   * If not, tcpcrypt is not enabled, and the SSL library does regular
SSL, exactly as it does right now.

2. After the initial login, with tcpcrypt-enabled clients, the TCP
connections are encrypted and protected against passive eavesdropping
and blind RST or data insertion attacks.  If these sessions are to the
same server, they'll use cached keying material, so be faster.  Also
the client knows the server is tcpcrypt-capable, it could optionally
could insist tcpcrypt succeeds for these, which might protect against
more than passive attacks.  With non-tcpcrypt-enabled clients, the TCP
sessions are in the clear, as they are now.

Depending on the application, different auth can be used for TCP
sessions after the original one, even if they're to a different one of
the company's servers.  For example, if tcpcrypt was used for the
initial session, the tcpcrypt-auth library can pass a session cookie
on the initial session, and then use that for cheap CMAC-based
authentication.  Of course there's nothing to stop the company using
SSL for these, but as they don't, presumably they have a performance
concern?  Would be good to know what their concern really is.

But I'm not sure this was your question.  Anyway, the main thing I
took away from today's meeting is that we really need to write a usage
cases document, to make it clear how we envisage tcpcrypt might be
used.

 - Mark

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Jul 2011 11:52:19 -0700

Hi, Anantha,

On 7/28/2011 11:41 AM, Anantha Ramaiah (ananth) wrote:
> Is there any consideration to allocate more code points for TCP
> experimental usage? With the increasing number of experimental TCP
> drafts (some of which uses TCP  options), it would be useful thing to
> extend the experimental TCP option space. Wondering whether this has
> been brought up before?

It has. In principle, the entire space can be used of the code is 
*ensured* to never leave the lab; these codepoints were assigned for safety.

IMO, nobody should EVER use an experimental codepoint without including 
a nonce that can be used to identify their use of that codepoint; that 
would prevent interference if (when) accidental deployment occurs.

Systems that intend to be widely deployed should get assigned 
codepoints, period. I personally think that posting code on a website 
for public use that includes experimental codepoints MUST NOT be 
tolerated (yes, that means that tcpcrypt code *needs* be taken down 
until this is resolved).

Joe

>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Joe Touch
>> Sent: Thursday, July 28, 2011 11:05 AM
>> To: Mark Handley
>> Cc: [email-masked]; [email-masked]; tsvwg
>> Subject: Re: [saag] Fwd: fyi: tcpcrypt draft
>>
>>
>>

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 29 Jul 2011 17:51:58 +1200

> http://nrg.cs.ucl.ac.uk/mjh/tmp/mboxes.pdf

This is a really interesting paper that affects a rather large number of other 
things (the whole end-to-end argument, IPv6 deployment, network neutrality, 
and so on), any chance of making this publicly available for others to read?  
The 'tmp' in the path implies that it's not for public consumption...

Peter.

---

From: Andrea Bittau <[email-masked]>
Date: Wed, 27 Jul 2011 11:42:57 -0700

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Thu, 28 Jul 2011 11:41:45 -0700

-Anantha

---

From: Mark Handley <[email-masked]>
Date: Fri, 29 Jul 2011 05:44:00 -0400

Thanks Peter - the paper has been accepted for publication in IMC, but it will be revised a little for final publication - in part because Michio has continued gathering data.  That's why this version is at a tmp URL.  I'm fine with you circulating this version further though if it's useful.

- Mark

---

From: Andrea Bittau <[email-masked]>
Date: Fri, 29 Jul 2011 18:45:44 -0700

On Thu, Jul 28, 2011 at 07:33:05AM -0700, David A. McGrew wrote:
> A lot of work has been done on using IPsec to solve these problems,
> and it is important to explain in detail how tcpcrypt improves on
> this work.  Besides the opportunistic encryption effort, there is
> BTNS (draft-ietf-btns-channel-binding-api-00 defines channel
> bindings for IPsec, for instance), RFC 3947 for running IPsec over
> NAT.  (Half joking: would the configuration of
> draft-ietf-ipsec-internet-key-00 with NAT-T solve all or most these
> problems?)

tcpcrypt makes incremental deployment easier because probing is built
into existing packets and fallback comes at no extrea cost.   When a SYN
packet is sent out and tcpcrypt is not supported at the other end, we
can fallback to regular tcpcrypt at no extra cost - just carry on with a
vanilla TCP handshake.  How would this work with BTNS or IPSec?  Do you
probe for IPSec (and then probe for NAT-T), wait for a timeout, and then
send a TCP SYN?  If so, it adds network overhead (extra packets) and
latency (probe timeout).

tcpcrypt also has less protocol (space) overhead.  NAT-T requires
encapsulating IP in UDP, and NAT seems like a common deployment
scenario.  It also requires opening more ports on a firewall and
configuring additional services (NAT-T).

> What TCP applications can't use TLS?   Do you mean that some apps
> don't use TLS in current implementations, or that there is some
> basic incompatibility?

There's a bootstrap problem.  If I have SMTP on TCP/25 I have to assume
it's clear-text (I can't send an SSL handshake packet).  Thankfully,
SMTP is an extensible protocol and I can send STARTTLS and then go on
with SSL.  If the protocol didn't permit any "options" / commands, I'd
be stuck to plain-text.  I'd have to allocate a new port.  That makes
incremental deployment harder - do I send two SYNs?

> What about running TCP on top of DTLS?   That would protect the TCP
> session, while keeping the crypto separate from the TCP stack.

Same answer as per BTNS and NAT-T - we can efficiently incrementally
deploy and have less protocol overhead.

> 1.  How easy to configure will tcpcrypt be once it supports mutual
> authentication, the enforcement of configurable security policies,
> and crypto algorithm agility (e.g. ECDH and ECDSA)?

Authentication is left to the application, so tcpcrypt will support
authentication only if the application supports it.  If the application
supports it, then a mechanism is already in place, e.g., htpasswd in
Apache for passwords.  So in the case of Apache, it'll include
tcpcrypt's session id when doing http digest authentication, for
example.

We're also working on an authentication library that attempts to
authenticate tcpcrypt using DNSSEC+DANE that can be used by all apps if
DANE is deployed.  The configuration will require storing a certificate
fingerprint in DNS.

We expect that most applications (e.g., the ones running clear-text                                          
today) won't care about the crypto algorithms used in tcpcrypt's
handshake.  So the security policy will be set system-wide (e.g., allow
only RSA, SHA1 or whatever).  For security concious applications it'll
be a setsockopt and presumably those applications already have a
configuration file for whatever the already use today for crypto.

> 2.  The comparison of tcpcrypt to TLS is only considering the RSA
> ciphersuites in the latter protocol.  The efficiency and security
> properties of other ciphersuites are quite different.

Yes, but we expect tcpcrypt to be no worse (or better) than TLS.
tcpcrypt fundamentally does however have lower latency for conncection
establishment compared to TLS due to fewer RTTs needed in negotiating a
key (we leverage the 3-way handshake and add only an extra leg),
especially when session caching.

> 3.  Reversing the client and server public/private key operations in
> tcpcrypt, which is used to make the protocol more scalable, is
> applicable only to the RSA algorithm.   In particular, the situation
> with elliptic curve cryptography is quite different.  This raises
> some questions: how does tcpcrypt with RSA compare to an ECDH/ECDSA
> TLS ciphersuite, say, at security levels of 128, 192, or 256 bits?
> How does tcpcrypt perform with other algorithms?   Given the
> interest in ECC as a future direction for cryptography, these
> questions deserve some thought.

Yes, we'll implement those but we do not expect tcpcrypt's performance
to be much different from a TLS implementation - we both do the same
thing (e.g., ECDH).

> What you are describing here is true for the RSA ciphersuites in
> SSL, but is not true for the Diffie-Hellman ciphersuites, or the
> ECDH ones (see Section 7.4.2 of RFC 5246 for instance).

tcpcrypyt's main goal is to be deployed ubiquitously.  Improved
performance in one case is only a bonus.  It has a bunch of other
advantages (single integrated mechanism, incrementally deployable) apart
from RSA performance.

> Why is graceful fallback easier at the TCP layer than at another
> layer?   And if there is some mechanism within TCP that facilitates
> fallback, would it be possible to use that mechanism in conjunction
> with a cryptographic protocol external to TCP?  That last option
> would minimize the impact to TCP implementations, meaning less new
> code inside kernels, and fewer states, and so on.

Gracefully, and efficient, I should add.  The problem is detecting
whether the other end supports crypto mechanism X.  At a below-transport
layer, we'd have to send our IP packet, wait for a timeout, and then
send a SYN.  At a transport layer we're sending out a SYN so we can
easily piggyback options (perfect!).  At an application layer what's the
first thing we send?  STARTTLS?  Does the application-layer protocol
allow such new commands or will it drop the command?

The minimum TCP mechanism needed for a graceful and efficient fallback
is a TCP option in the SYN.  So, tcpcrypt-lite would modify a kernel
with a setsockopt(CRYPTO_OPTION) to include the CRYPTO option in a SYN
and getsockopt(CRYPTO_OPTION) to see if the CRYPTO option was echoed in
the SYN-ACK.  At that point SSL_accept() can be called.  But we lose all
TCP header MACing - e.g., someone can RST our connection.  TCP AO
suggests that MACing TCP headers is important so crypto protocols should
do that (hence why we live in the transport layer).  Also, we can
leverage the existing 3-way handshake to get a head start on crypto
negotiations.  Sesison caching completes within the three way handshake.

> If the RSA keypair is generated using a pseudorandom process (and
> there are standards for doing that), the min entropy could be lower.
> 
> But if it is adequate to have the entropy show up in the nonces, the
> min-entropy of the key would be a moot point.

The pseudo-random generator has to have enough state to generate prime
numbers with min entropy 256.  Depending on the prime number generator,
this might, for instance, require something on the order of 256 + ceil
(log_2 (log_e (2 ^ 1024))) or 266 bits.  We assume most RSA
implementations would have more random state than that.