Hello,
in addition to my last thread about a new config option to make strict-kex mandatory,
I also wonder if a new mechanism for ciphers/macs can be introduced and is reliable
by simple both sides using it.
So there could be a Chacha20-Poly1305v2@openssh.com which uses AD data to chain the
messages together, so it will be resistant against terrapin even without the strict-kex.
Consequently the hmac-etmv2@openssh.com mode could be deviced in a similar manner, to
also include the transcript hash or similar things.
The impact of removing the only "alternative" cipher cc20p1305 because of terrapin hardening as well
as falling back to the old eam-macs is really bad for ssh best practice. And while "enforce strict-key"
could gain some of the trust back, the attack also shows, that those constructs are just very fragile.
And while a redesign of the protocol might be a good option, its not the fastest to standardize and implement.
Whereas openssh project has done it before both new ciphers.
On that note - maybe combine it with PQ hybrid modes?
I have a related question:
Has anybody analyzed the aes-ctr / hmac-etm properties, whats making this resist and is it rigid?
It looks like it is only the counter position which saves it?
So is keeping hmac-etm iff aes-ctr is offered used still a safe option (or just "not broken"). Because luckily many
have removed CBC already.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
in addition to my last thread about a new config option to make strict-kex mandatory,
I also wonder if a new mechanism for ciphers/macs can be introduced and is reliable
by simple both sides using it.
So there could be a Chacha20-Poly1305v2@openssh.com which uses AD data to chain the
messages together, so it will be resistant against terrapin even without the strict-kex.
Consequently the hmac-etmv2@openssh.com mode could be deviced in a similar manner, to
also include the transcript hash or similar things.
The impact of removing the only "alternative" cipher cc20p1305 because of terrapin hardening as well
as falling back to the old eam-macs is really bad for ssh best practice. And while "enforce strict-key"
could gain some of the trust back, the attack also shows, that those constructs are just very fragile.
And while a redesign of the protocol might be a good option, its not the fastest to standardize and implement.
Whereas openssh project has done it before both new ciphers.
On that note - maybe combine it with PQ hybrid modes?
I have a related question:
Has anybody analyzed the aes-ctr / hmac-etm properties, whats making this resist and is it rigid?
It looks like it is only the counter position which saves it?
So is keeping hmac-etm iff aes-ctr is offered used still a safe option (or just "not broken"). Because luckily many
have removed CBC already.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev