For performance reasons, VMs work by directly running the virtualized software on the hardware. When the software reaches the edge of the sandbox, by hitting a page fault or by running a privileged instruction, the VM emulates the memory access or instruction in question, then sends the program off on its merry way. (The list of instructions, BTW, is determined by the processor architecture. Reading a segment register on x86 does not trigger a security exception.)
Emulation can trick a program completely, but the performance is terrible. VMs like VMware, Plex86, QEMU, etc. generally perform orders of magnitude faster than true emulators like Bochs. In general, one wouldn't want to use an emulator on a regular basis if it can at all be avoided, and for same-architecture binaries, it can.
(Hypothetically, an emulator could borrow a page from Java and do a Just-In-Time hybrid where native machine code is emitted and cached the first time a virtualized code region is executed. However, it's damn tricky -- mostly due to self-modifying code, which is used more often than one might naïvely expect.)
SSL works by sending the PUBLIC key to a trusted 3rd party and letting them sign it. (They are generally willing to do this if you pay them $100/year or so for the trouble.) Sending the PRIVATE key would be suicide. Note that SSL private keys are, just as with SSH, normally stored unencrypted on the hard drive of whatever computer normally uses that key. This is mandatory in most situations because the SSL application (Apache, Exim, whatever) must start up without human intervention. If the SSL libraries (stupidly) required the private key to be encrypted, then you'd just store the passphrase in plaintext on the server, which isn't the least bit more secure. Likewise, SSH is commonly used in automated scripts to log into remote computers (e.g. a user doing a scheduled backup of his remote home directories), and any automated use of SSH will have the same troubles.
You're quite mistaken if you think that username/password is more secure than public/private key. Since SSH refuses to use a private key with insecure file permissions, only a root compromise on the client machine can reveal the private key. However, it's revealed whether or not it has a passphrase, since root can just snoop the memory of the SSH process to obtain the decrypted key, keylog the user's TTY and steal the passphrase, trojan the SSH program to stash a decrypted copy somewhere, etc., etc. All those same flaws apply to username/password as well, except that now the user is vulnerable to a root compromise on any of the computers he logs in via, rather than just his home machine. If he's smart (most users aren't), he'll have a different password for each computer, and hopefully it'll just be his password on your computer that's leaked.
You're missing the point. The whole point of having a public/private keypair is that the private key never leaves the client's computer. Any crypto system that breaks that rule is less secure than one that follows it, because it has more points of failure. It makes far more sense to just patch ssh-keygen to require an affirmation in triplicate that the user understands the implications of having an unpassphrased private key. A mandatory policy approach is wrong for this situation, and for multiple reasons.
Actually, Overlapped I/O is specific to the NT kernel 4.0+, although Windows 95+ emulates it at the API level (except for serial and parallel port I/O, where it's actually native).
And who would do the signing? Would you ship your private keys over the Internet to a "trusted" 3rd party clearinghouse (e.g. Verisign) to let them digitally sign a little certificate verifying that the private key was encrypted? Anything short of that can be faked trivially.
A passworded SSH key is just a passwordless key that's been symmetrically encrypted with a passphrase, and it has to be decrypted on the client side before it can be used. The SSH protocol could've added a bit to tell the server that the key started off encrypted, but the client could just as easily have been patched to always tell it "true".
SHA-1 is still less broken than MD-5, but both are still acceptable for password hashing. The new attacks are both collision attacks [attacker creates A and B such that H(A)=H(B)] and not preimage attacks [attacker creates A such that H(A)=H(S), where S is unknown to the attacker but H(S) is known]. While the new attacks are important to anyone using digital signatures (e.g. PGP) to sign documents created by others, they're still considered rather solid for password hashing. So what if a user can create two passwords that both hash to the same SHA-1 output? Now they have two passwords to get into their own account, but it doesn't help them get into anyone else's.
FYI, Overlapped I/O is an API for Windows programmers. It's vaguely similar to open(O_ASYNC) and SIGIO in *nix, if you squint your eyes a bit. None of which means a damn thing if you're not actually writing the code, but using someone else's.
Why not just simulate neurons in software? After all, we can simulate analog circuits just fine. Takes a fair amount of computer power, sure, but there's no fundamental difference between what can be computed by an analog circuit and what can be computed by a digital one. I'd be very, very surprised if a brain couldn't in principle be simulated by any Turing-complete machine. (Performance would suck, and the memory requirements would be insane, but in principle, doable.)
...You want that program, well just download it and install it. None of this screwing around trying to compile it, downloading a million different libraries trying to find the right one
Most desktop users and new switchers are just not interested in compiling a program to get it to run. They want it to "just work"(tm).
That's the lovely thing about distributions like Debian (which I use) or Ubuntu. If I want to see the libraries that a program depends on, or what other packages depend on the one I'm looking at, I can just hit "d" or "r" respectively in aptitude. However, most people aren't interested in that level of detail, and they don't get it if they don't ask for it. A simple "apt-get install appname" will take care of all the details for you so you don't have to micromanage if you don't want to. Windows installer apps, OTOH, simply don't offer that level of detail. You can't know what kind of crap they'll install to SYSTEM32 (merrily overwriting older versions, even if the newer version is slightly incompatible) until everything's already said and done and there's no easy way to undo it.
All real-world software has bugs. That a project as massive as Firefox has security bugs, even "extremely critical" ones, is not exactly a shocker. However, if you compare the frequency of security bugs in Firefox 1.0 with the frequency of security bugs in, say, Internet Explorer 4.0 or Netscape Navigator 4.0 (products with a similar code maturity as measured by invested developer-hours), Firefox still comes out smelling like roses.
For IE users just a few short years ago, there was new remote code execution bug in IE on about a monthly basis. Now that IE's had a lot of time to mature and there's no new development for it, the security bugs have mostly settled down since all the low-hanging fruit has been picked.
Firefox, OTOH, has recently gotten popular enough that it's solidly entered the blackhat limelight. Naturally, this means that the blackhats are searching for low-hanging fruit. I actually find it rather assuring that, despite having fully public source code, it took a good 4 months before the first serious bug, and another month for the firstpair of bugs that relate to the browser's actual security architecture.
Personally, I think that (a) writing the browser in XUL/Javascript was a security mistake on the level of IE's Zones, and that (b) whoever invented javascript: URLs should be drawn and quartered. However, what's done is done, and overall I still think that Firefox is on a more solid security footing than IE, especially thanks to the absence of an ActiveX-like auto-installing plugin architecture. I strongly doubt that the current pace of 1 major bug per month will hold true 6 months down the road, much less into the future beyond that. Because Firefox shares so much code with the Mozilla Suite, a lot of that buggy immaturity was stomped out during the Mozilla M18 through 0.9.x beta testing, about 4-5 years ago. I can't see any major shakeups happening with all that testing under Firefox's belt.
Sage is an add-on. It doesn't bloat the default install of Firefox. (Which is, of course, the reason why the Firefox developers put so much emphasis on extensions over built-in functionality.)
It's a very different exploit design with a different set of vulnerable programs, yes, but it's still disturbingly common. Also, even with a separate return stack, you're still subject to overflows into saved registers, so you can still do writes to arbitrary locations in memory (unless saved registers also go on the return stack, of course).
Actually, now that I think about it, leaving the old call stack the way it is but putting local variables on a new stack would help avoid overflows into both registers and parameters. You'd still have the "security_check_passed=1" problem, and any local buffer pointers could still be used for arbitrary memory writes.
That would almost preserve the x86 ABI, except that whichever register (EBP most likely) were now used for local variables would now need new call semantics. You could fudge it a bit by saying that EBP is still undefined at function entry, but have the C library include an internal function that adjusts and returns the top of the local variable stack. The C compiler would insert (pseudocode) EBP = __lstack_adj(n) in the prolog after saving EBP, then call __lstack_adj(-n) in the epilog. That'd hurt performance a bit, but no more than what the compiler has to do to create PIC code anyway.
Actually, it sounds implementable as a simple compiler option. My biggest complaint about split stack was that it broke the ABI for not much gain, but if it can preserve the ABI, I'm all for giving people the option. You could even implement a stack canary without blinking, since the canary code would be in __lstack_adj. Overwrites of variables local to the function would still be doable, of course, but every bit helps.
int main(void) { char buf[256]; do_something(buf); printf("%s\n", buf); }
Now, what segment will p use? DS. What segment should p use? SS. You could make the DS and SS segments overlap, but then you're right back to the current situation. If you don't switch back to the Dantean hell of NEAR/FAR pointers, you simply can't use separate stack/heap segments.
You could split the return stack from the parameter/data stack, but that still permits overflowing the arguments and on-stack data from your ancestor functions in the call stack, which is just as lethal security-wise as a return address overwrite. If you can overwrite the calling function's int security_check_passed with a 1, it doesn't matter if you can return into a buffer or not.
Before digital, with film, yes, you owned your image. However, you did not own the chemical process used to record your image on the film.
This is more like, "You own the image, but you do not own the rights to our PROPRIETARY TECHNIQUE of SHINING LIGHT on your film to see what's recorded on it. Instead, you must buy this PhotoViewer1905(TM) to view your photos. Oh, and since one of them complained in public, we'll let other 'bona-fide' photo viewer makers in on our PROPRIETARY TECHNIQUE, but we'll sue the pants off anyone who tries to view their own photos for free."
Technically, what's actually a secret in my analogy is the exact color of the light to shine on the film to see the colors correctly, but it's a close enough analogy.
One of the perks of being a programmer is that, normally, coding is a refuge from thinking about this kind of crap. GCC doesn't give a fliegende kinderscheisse that I'm gay.
For a while I couldn't readthenewspaper without getting a knot in my stomach, and just looking at the Opinion section can give me a headache these days without even reading it. Between what my own state is up to and the creepy backlash building up at the national level, I've decided that sticking it out in the U.S. just isn't worth it and I'm currently saving up to move to Vancouver.
Now, though, the insanity is even making its way onto the Slashdot front page. Tech companies being gay-friendly has always just been a given in the back of my mind. The fact that the biggest of them all is backing off due to outside pressure has me worried even more. I can't shake the feeling that there's something big and scary happening here in the U.S. right now, and the backlash against gay rights is only the tip of it.
Neither can a lot of straight couples. If a guy is impotent, does that make him unnatural and/or sinful? Should we make it legal to fire people for being infertile, or to evict them from their homes? If a marriage turns out to not produce children, and it turns out the minister knew they were infertile, should he or she be tracked down and arrested for falsely marrying the couple? (After the marriage is declared null and invalid, obviously.)
There's been this bitter rivalry in the civil rights sphere between Coretta Scott King (widow of the late Martin Luther King) and Alveda Celeste King (niece of the same). CSK is strongly pro-gay and considers her support of gay rights a continuation of her late husband's work -- which is probably an accurate assessment considering MLK's staunch support of Bayard Rustin during Strom Thurmond's smear campaign against him. (Bayard Rustin being the behind-the-scenes organizer of the 1963 March, and an openly gay black man.) ACK, on the other hand, is strongly anti-gay and also claims to be following in her uncle's footsteps. Unfortunately, it reflects a rather deep schism.
There isn't really much in the way of danger when replacing a known bad gene with a known good gene. We'll only need a solid understanding of gene interaction once we start creating deliberate mutations and writing new genes from scratch, and we'll have to understand protein folding before we can even reach that step. We have a long way to go.
No. This is one of the consequences of the No Cloning Theorem, which states that it's impossible to copy qubits. The gist is that, for Alice to send information to Bob, Bob would need to make more than one measurement of the same qubit without collapsing it. One measurement just tells him "clockwise" or "counterclockwise"; the only information he now knows is that Alice's qubit is the opposite of his, but he can't tell whether or not Alice had measured hers before he measured his (or otherwise detect anything else Alice had done to her qubit).
If Bob could clone qubits, he could measure his cloned qubits instead; if they all gave the same answer, then Alice had measured her qubit before Bob measured his. If they agree on a pre-determined time for Bob to clone and measure his qubit, they can create a system for transmitting 1s and 0s.
All you have to do with symmetric crypto is double the bits to defeat Grover's algorithm. After the initial doubling, you're back to the same "arms race" between crypto and Moore's Law. That's a trivial situation compared to public key crypto. (Although, Shor's algorithm does require a QC with roughly 2n coherent qubits for an n-bit prime, which provides public key crypto with a bit of a reprieve. If the number of qubits in a QC follows the same pattern of growth that memory size has, another arms race might result. If the number of qubits goes up in sudden spurts, RSA and its relatives might go extinct, because a "safe" number of bits for a future date cannot be estimated.)
Slashdot Mirror
For performance reasons, VMs work by directly running the virtualized software on the hardware. When the software reaches the edge of the sandbox, by hitting a page fault or by running a privileged instruction, the VM emulates the memory access or instruction in question, then sends the program off on its merry way. (The list of instructions, BTW, is determined by the processor architecture. Reading a segment register on x86 does not trigger a security exception.)
Emulation can trick a program completely, but the performance is terrible. VMs like VMware, Plex86, QEMU, etc. generally perform orders of magnitude faster than true emulators like Bochs. In general, one wouldn't want to use an emulator on a regular basis if it can at all be avoided, and for same-architecture binaries, it can.
(Hypothetically, an emulator could borrow a page from Java and do a Just-In-Time hybrid where native machine code is emitted and cached the first time a virtualized code region is executed. However, it's damn tricky -- mostly due to self-modifying code, which is used more often than one might naïvely expect.)
SSL works by sending the PUBLIC key to a trusted 3rd party and letting them sign it. (They are generally willing to do this if you pay them $100/year or so for the trouble.) Sending the PRIVATE key would be suicide. Note that SSL private keys are, just as with SSH, normally stored unencrypted on the hard drive of whatever computer normally uses that key. This is mandatory in most situations because the SSL application (Apache, Exim, whatever) must start up without human intervention. If the SSL libraries (stupidly) required the private key to be encrypted, then you'd just store the passphrase in plaintext on the server, which isn't the least bit more secure. Likewise, SSH is commonly used in automated scripts to log into remote computers (e.g. a user doing a scheduled backup of his remote home directories), and any automated use of SSH will have the same troubles.
You're quite mistaken if you think that username/password is more secure than public/private key. Since SSH refuses to use a private key with insecure file permissions, only a root compromise on the client machine can reveal the private key. However, it's revealed whether or not it has a passphrase, since root can just snoop the memory of the SSH process to obtain the decrypted key, keylog the user's TTY and steal the passphrase, trojan the SSH program to stash a decrypted copy somewhere, etc., etc. All those same flaws apply to username/password as well, except that now the user is vulnerable to a root compromise on any of the computers he logs in via, rather than just his home machine. If he's smart (most users aren't), he'll have a different password for each computer, and hopefully it'll just be his password on your computer that's leaked.
You're missing the point. The whole point of having a public/private keypair is that the private key never leaves the client's computer. Any crypto system that breaks that rule is less secure than one that follows it, because it has more points of failure. It makes far more sense to just patch ssh-keygen to require an affirmation in triplicate that the user understands the implications of having an unpassphrased private key. A mandatory policy approach is wrong for this situation, and for multiple reasons.
Actually, Overlapped I/O is specific to the NT kernel 4.0+, although Windows 95+ emulates it at the API level (except for serial and parallel port I/O, where it's actually native).
See the MSDN articles on struct OVERLAPPED and CreateFile(FILE_FLAG_OVERLAPPED) .
And who would do the signing? Would you ship your private keys over the Internet to a "trusted" 3rd party clearinghouse (e.g. Verisign) to let them digitally sign a little certificate verifying that the private key was encrypted? Anything short of that can be faked trivially.
A passworded SSH key is just a passwordless key that's been symmetrically encrypted with a passphrase, and it has to be decrypted on the client side before it can be used. The SSH protocol could've added a bit to tell the server that the key started off encrypted, but the client could just as easily have been patched to always tell it "true".
SHA-1 is still less broken than MD-5, but both are still acceptable for password hashing. The new attacks are both collision attacks [attacker creates A and B such that H(A)=H(B)] and not preimage attacks [attacker creates A such that H(A)=H(S), where S is unknown to the attacker but H(S) is known]. While the new attacks are important to anyone using digital signatures (e.g. PGP) to sign documents created by others, they're still considered rather solid for password hashing. So what if a user can create two passwords that both hash to the same SHA-1 output? Now they have two passwords to get into their own account, but it doesn't help them get into anyone else's.
FYI, Overlapped I/O is an API for Windows programmers. It's vaguely similar to open(O_ASYNC) and SIGIO in *nix, if you squint your eyes a bit. None of which means a damn thing if you're not actually writing the code, but using someone else's.
Yes.
Why not just simulate neurons in software? After all, we can simulate analog circuits just fine. Takes a fair amount of computer power, sure, but there's no fundamental difference between what can be computed by an analog circuit and what can be computed by a digital one. I'd be very, very surprised if a brain couldn't in principle be simulated by any Turing-complete machine. (Performance would suck, and the memory requirements would be insane, but in principle, doable.)
That's the lovely thing about distributions like Debian (which I use) or Ubuntu. If I want to see the libraries that a program depends on, or what other packages depend on the one I'm looking at, I can just hit "d" or "r" respectively in aptitude. However, most people aren't interested in that level of detail, and they don't get it if they don't ask for it. A simple "apt-get install appname" will take care of all the details for you so you don't have to micromanage if you don't want to. Windows installer apps, OTOH, simply don't offer that level of detail. You can't know what kind of crap they'll install to SYSTEM32 (merrily overwriting older versions, even if the newer version is slightly incompatible) until everything's already said and done and there's no easy way to undo it.
All real-world software has bugs. That a project as massive as Firefox has security bugs, even "extremely critical" ones, is not exactly a shocker. However, if you compare the frequency of security bugs in Firefox 1.0 with the frequency of security bugs in, say, Internet Explorer 4.0 or Netscape Navigator 4.0 (products with a similar code maturity as measured by invested developer-hours), Firefox still comes out smelling like roses.
For IE users just a few short years ago, there was new remote code execution bug in IE on about a monthly basis. Now that IE's had a lot of time to mature and there's no new development for it, the security bugs have mostly settled down since all the low-hanging fruit has been picked.
Firefox, OTOH, has recently gotten popular enough that it's solidly entered the blackhat limelight. Naturally, this means that the blackhats are searching for low-hanging fruit. I actually find it rather assuring that, despite having fully public source code, it took a good 4 months before the first serious bug, and another month for the first pair of bugs that relate to the browser's actual security architecture.
Personally, I think that (a) writing the browser in XUL/Javascript was a security mistake on the level of IE's Zones, and that (b) whoever invented javascript: URLs should be drawn and quartered. However, what's done is done, and overall I still think that Firefox is on a more solid security footing than IE, especially thanks to the absence of an ActiveX-like auto-installing plugin architecture. I strongly doubt that the current pace of 1 major bug per month will hold true 6 months down the road, much less into the future beyond that. Because Firefox shares so much code with the Mozilla Suite, a lot of that buggy immaturity was stomped out during the Mozilla M18 through 0.9.x beta testing, about 4-5 years ago. I can't see any major shakeups happening with all that testing under Firefox's belt.
Sage is an add-on. It doesn't bloat the default install of Firefox. (Which is, of course, the reason why the Firefox developers put so much emphasis on extensions over built-in functionality.)
It's a very different exploit design with a different set of vulnerable programs, yes, but it's still disturbingly common. Also, even with a separate return stack, you're still subject to overflows into saved registers, so you can still do writes to arbitrary locations in memory (unless saved registers also go on the return stack, of course).
Actually, now that I think about it, leaving the old call stack the way it is but putting local variables on a new stack would help avoid overflows into both registers and parameters. You'd still have the "security_check_passed=1" problem, and any local buffer pointers could still be used for arbitrary memory writes.
That would almost preserve the x86 ABI, except that whichever register (EBP most likely) were now used for local variables would now need new call semantics. You could fudge it a bit by saying that EBP is still undefined at function entry, but have the C library include an internal function that adjusts and returns the top of the local variable stack. The C compiler would insert (pseudocode) EBP = __lstack_adj(n) in the prolog after saving EBP, then call __lstack_adj(-n) in the epilog. That'd hurt performance a bit, but no more than what the compiler has to do to create PIC code anyway.
Actually, it sounds implementable as a simple compiler option. My biggest complaint about split stack was that it broke the ABI for not much gain, but if it can preserve the ABI, I'm all for giving people the option. You could even implement a stack canary without blinking, since the canary code would be in __lstack_adj. Overwrites of variables local to the function would still be doable, of course, but every bit helps.
Now, what segment will p use? DS. What segment should p use? SS. You could make the DS and SS segments overlap, but then you're right back to the current situation. If you don't switch back to the Dantean hell of NEAR/FAR pointers, you simply can't use separate stack/heap segments.
You could split the return stack from the parameter/data stack, but that still permits overflowing the arguments and on-stack data from your ancestor functions in the call stack, which is just as lethal security-wise as a return address overwrite. If you can overwrite the calling function's int security_check_passed with a 1, it doesn't matter if you can return into a buffer or not.
PNG supports 48-bit color and 16-bit grayscale. Also, while pure PNG doesn't support lossy compression, JNG is essentially JPEG compression in a MNG wrapper. (And yes, MNG can do still images as well, despite the name.)
This is more like, "You own the image, but you do not own the rights to our PROPRIETARY TECHNIQUE of SHINING LIGHT on your film to see what's recorded on it. Instead, you must buy this PhotoViewer1905(TM) to view your photos. Oh, and since one of them complained in public, we'll let other 'bona-fide' photo viewer makers in on our PROPRIETARY TECHNIQUE, but we'll sue the pants off anyone who tries to view their own photos for free."
Technically, what's actually a secret in my analogy is the exact color of the light to shine on the film to see the colors correctly, but it's a close enough analogy.
One of the perks of being a programmer is that, normally, coding is a refuge from thinking about this kind of crap. GCC doesn't give a fliegende kinderscheisse that I'm gay.
For a while I couldn't read the newspaper without getting a knot in my stomach, and just looking at the Opinion section can give me a headache these days without even reading it. Between what my own state is up to and the creepy backlash building up at the national level, I've decided that sticking it out in the U.S. just isn't worth it and I'm currently saving up to move to Vancouver.
Now, though, the insanity is even making its way onto the Slashdot front page. Tech companies being gay-friendly has always just been a given in the back of my mind. The fact that the biggest of them all is backing off due to outside pressure has me worried even more. I can't shake the feeling that there's something big and scary happening here in the U.S. right now, and the backlash against gay rights is only the tip of it.
first they cant have childern naturally.
Neither can a lot of straight couples. If a guy is impotent, does that make him unnatural and/or sinful? Should we make it legal to fire people for being infertile, or to evict them from their homes? If a marriage turns out to not produce children, and it turns out the minister knew they were infertile, should he or she be tracked down and arrested for falsely marrying the couple? (After the marriage is declared null and invalid, obviously.)
There's been this bitter rivalry in the civil rights sphere between Coretta Scott King (widow of the late Martin Luther King) and Alveda Celeste King (niece of the same). CSK is strongly pro-gay and considers her support of gay rights a continuation of her late husband's work -- which is probably an accurate assessment considering MLK's staunch support of Bayard Rustin during Strom Thurmond's smear campaign against him. (Bayard Rustin being the behind-the-scenes organizer of the 1963 March, and an openly gay black man.) ACK, on the other hand, is strongly anti-gay and also claims to be following in her uncle's footsteps. Unfortunately, it reflects a rather deep schism.
I'm gay, and I have no frelling clue.
There isn't really much in the way of danger when replacing a known bad gene with a known good gene. We'll only need a solid understanding of gene interaction once we start creating deliberate mutations and writing new genes from scratch, and we'll have to understand protein folding before we can even reach that step. We have a long way to go.
So does lying. Lying is a subset of speech, and fraud is a subset of lying.
(Am I being pedantic? Probably. Just ignore me.)
No. This is one of the consequences of the No Cloning Theorem, which states that it's impossible to copy qubits. The gist is that, for Alice to send information to Bob, Bob would need to make more than one measurement of the same qubit without collapsing it. One measurement just tells him "clockwise" or "counterclockwise"; the only information he now knows is that Alice's qubit is the opposite of his, but he can't tell whether or not Alice had measured hers before he measured his (or otherwise detect anything else Alice had done to her qubit).
If Bob could clone qubits, he could measure his cloned qubits instead; if they all gave the same answer, then Alice had measured her qubit before Bob measured his. If they agree on a pre-determined time for Bob to clone and measure his qubit, they can create a system for transmitting 1s and 0s.
All you have to do with symmetric crypto is double the bits to defeat Grover's algorithm. After the initial doubling, you're back to the same "arms race" between crypto and Moore's Law. That's a trivial situation compared to public key crypto. (Although, Shor's algorithm does require a QC with roughly 2n coherent qubits for an n-bit prime, which provides public key crypto with a bit of a reprieve. If the number of qubits in a QC follows the same pattern of growth that memory size has, another arms race might result. If the number of qubits goes up in sudden spurts, RSA and its relatives might go extinct, because a "safe" number of bits for a future date cannot be estimated.)