Never worked there. I could name some other techy corps where executives were moved to "Special Projects" while the terms of their firing were worked out.
But to replace RC4, new software had to be written and released. Interworking with old implementations is still broken today. TLS is a life raft for broken crypto.
Given that you know new software has to be released just tie one algorithm for each purpose to one version.
--> HI_MY_MAX_VERSION_IS_X -- HI_MY_MAX_VERSION_IS_Y Chosen cipher == Lookup_cipher(min(X,Y)) Refuse or allow based on whether we are willing to do min(X,Y). MAC the whole exchange, continue.
This looks like ciphersuite negotiation, but it isn't. It's protocol version negotiation which happens anyway.
As has been pointed out in many forums, the problem with ciphersuites is not just getting new ciphers in. It's getting old ciphers out. Getting old crypto out is just one of TLS's many failings.
It's notable that in the current draft they still don't get it right. IV
The Initialization Vector (IV) SHOULD be chosen at random, and
MUST be unpredictable. Note that in versions of TLS prior to 1.1,
there was no IV field, and the last ciphertext block of the
previous record (the "CBC residue") was used as the IV. This was
changed to prevent the attacks described in [CBCATT]. For block
ciphers, the IV length is of length
SecurityParameters.record_iv_length, which is equal to the
SecurityParameters.block_size.
The implementer is left to interpret 'random' and 'unpredictable' in ways that are useful for an effective cryptographic outcome. Unpredictable to who? Certainly not to the generating end if a CSPRNG is being used.
What kind of random? There are many definitions of random that don't fall into the cryptographically useful set.
We know much more about randomness than we did 5 years ago. It doesn't seem like the TLS authors have really kept up.
I'm not interested in helping TLS by fixing their spec. I'm only interested in destroying it and replacing it with something sane.
And yet, the underlying crypto was sound. The composition was broken. If they had specified a proper random IV and not allowed alternatives, beast could not have happened.
The weight of TLS made the details of the CBC implementation appear minor. But in fact getting that right is a primary task.
If there was less work on the bucket full of protocol, perhaps there would have been time for people to listen to the crypto guys when they say your IV must be random. If CBC was the only privacy mode, you can be sure that someone would have commented on the IV issue because that is pretty much the only requirement on external inputs to CBC.
Apple were very open with their products back then. They didn't conform to any notion of free software though. The claim was they represent nothing free and open. I pointed out that they used to be open. I made no claims about the freedom of their software.
Not that I'm defending Apple's inflexibility, but why would fixed entry points limit the size of the subroutines? Let each entry point have a single instruction "JMP start_of_actual_subroutine". The previous instruction can then be "JMP current_instruction_address + 2" in order to skip over the redirection, and all the surrounding ROM can be used however you see fit.
That was done. I think the Beagle Bros did exactly that with their improved images.
Slashdot Mirror
Everyone needs a hobby.
Yes. Once we rid the world of theism, the world will be a better place.
Necessary isn't necessarily nice.
Theism is evil. It is right to call it every time.
For a superior Apple 2 experience I recommend this.
If it's Intel based, yes, as long as you control the secure boot keys.
> try out Integer Basic in an emulator and then try AppleSoft Basic.
Why in an emulator? I just run them directly on my Apple 2e. The Integer ROM is great because it comes with the mini assembler and sweet 16.
If the contracts are very similar, why do you need to give money to leaches like ASCAP and agents to do it for you?
The ROKU 3 RF remote cures the swinging reaction after a few days.
Not until the sex change.
Well I looked many places and found that after the third go round. Not hard, but not obvious.
OK. I found it on the third go round, behind the locked door with the sign saying "beware of the leopard".
Better yet. I just logged in and I cannot find where to change my password.
Unless you're talking about the Dual EC DRBG.
Prime fields are safer, but they are inconvenient. Elements in a GF(2**n) field map nicely to n bits.
>are moving away from finite fields altogether in favor of elliptic curves
Umm, what about all the elliptic curves in finite fields?
It would be nice if noSQL databases adhered to the promise in the name. They replace the query language with something sane and secure.
Never worked there. I could name some other techy corps where executives were moved to "Special Projects" while the terms of their firing were worked out.
Does the author know that "Special Projects" is corporate speak for "Taken off of primary responsibilities prior to being fired".
What difference does it make when after taking the photo, you just upload it to Facebook?
No. That's "omelette à l'oignon et jambon"
I think the primary thing that makes a omelette a Denver omelette is that it is too large.
But to replace RC4, new software had to be written and released. Interworking with old implementations is still broken today. TLS is a life raft for broken crypto.
Given that you know new software has to be released just tie one algorithm for each purpose to one version.
--> HI_MY_MAX_VERSION_IS_X
-- HI_MY_MAX_VERSION_IS_Y
Chosen cipher == Lookup_cipher(min(X,Y))
Refuse or allow based on whether we are willing to do min(X,Y).
MAC the whole exchange, continue.
This looks like ciphersuite negotiation, but it isn't. It's protocol version negotiation which happens anyway.
As has been pointed out in many forums, the problem with ciphersuites is not just getting new ciphers in. It's getting old ciphers out. Getting old crypto out is just one of TLS's many failings.
It's notable that in the current draft they still don't get it right.
IV
The Initialization Vector (IV) SHOULD be chosen at random, and
MUST be unpredictable. Note that in versions of TLS prior to 1.1,
there was no IV field, and the last ciphertext block of the
previous record (the "CBC residue") was used as the IV. This was
changed to prevent the attacks described in [CBCATT]. For block
ciphers, the IV length is of length
SecurityParameters.record_iv_length, which is equal to the
SecurityParameters.block_size.
The implementer is left to interpret 'random' and 'unpredictable' in ways that are useful for an effective cryptographic outcome.
Unpredictable to who? Certainly not to the generating end if a CSPRNG is being used.
What kind of random? There are many definitions of random that don't fall into the cryptographically useful set.
We know much more about randomness than we did 5 years ago. It doesn't seem like the TLS authors have really kept up.
I'm not interested in helping TLS by fixing their spec. I'm only interested in destroying it and replacing it with something sane.
And yet, the underlying crypto was sound. The composition was broken. If they had specified a proper random IV and not allowed alternatives, beast could not have happened.
The weight of TLS made the details of the CBC implementation appear minor. But in fact getting that right is a primary task.
If there was less work on the bucket full of protocol, perhaps there would have been time for people to listen to the crypto guys when they say your IV must be random. If CBC was the only privacy mode, you can be sure that someone would have commented on the IV issue because that is pretty much the only requirement on external inputs to CBC.
Do you enjoy building strawmen to attack?
Apple were very open with their products back then. They didn't conform to any notion of free software though. The claim was they represent nothing free and open. I pointed out that they used to be open. I made no claims about the freedom of their software.
Not that I'm defending Apple's inflexibility, but why would fixed entry points limit the size of the subroutines? Let each entry point have a single instruction "JMP start_of_actual_subroutine". The previous instruction can then be "JMP current_instruction_address + 2" in order to skip over the redirection, and all the surrounding ROM can be used however you see fit.
That was done. I think the Beagle Bros did exactly that with their improved images.
>Apple does not represent anything free and open.
Any more. My apple ][ comes with the schematics and ROM listing.