-
Notifications
You must be signed in to change notification settings - Fork 463
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Import Key with even parity fails with Parity Exception #509
Comments
The if statement in the decrypt method honors a |
Checkparity is only set by code and is always true. If you are using the console one has no control over it. Based on my limited knowledge, a Thales hsm will allow even parity keys and adjust it to odd parity. |
I guess we could add a Having the ability to early detect bad keys is something I think we should keep. |
I agree with you. |
IMHO, if we are going to auto adjust, because we assume the parity may be
evenly adjusted, we should check it is even before adjusting. Otherwise we
are just making an error that would show up later and more difficult to
understanding.
At the very least, we may show a strong warning if adjusting a non even
parity key. Be it by implementing a command or by using a flag.
Enviado desde mi móvil, disculpas por la brevedad
El vie, 20 de ene. de 2023 22:08, Murtuza Chhil ***@***.***>
escribió:
… I agree with you.
If the parity exception gets thrown, one has the ability to try and adjust
the even parity keys.
—
Reply to this email directly, view it on GitHub
<#509 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA42RO4IOLU2WUC7KPJ3OTTWTNHMPANCNFSM6AAAAAATZ42UWE>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Adjusting an odd parity key has no impact and returns the same key. If the key before and after adjust parity are same, then that implies it was already odd else it was even. Logging should add more clarity to what has happened and what has been done. |
If It was indeed adjusted, but it could just be encrypted under the wrong
key or the user trying to use the wrong key or scheme. That's why I would
adjust the parity only if the parity was odd adjusted, but display a strong
warning or even return an error if it was not adjusted at all.
I wonder what Thales does if the parity is not even or odd adjusted.
Enviado desde mi móvil, disculpas por la brevedad
El sáb, 21 de ene. de 2023 21:00, Murtuza Chhil ***@***.***>
escribió:
… Adjusting an odd parity key has no impact and returns the same key. If the
key before and after adjust parity are same, then that implies it was
already odd else it was even.
Logging should add more clarity to what has happened and what has been
done.
—
Reply to this email directly, view it on GitHub
<#509 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA42RO5Z2WP7VO2UTB452TTWTSIE5ANCNFSM6AAAAAATZ42UWE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
From jpos google group
https://groups.google.com/g/jpos-users/c/sa8LIIg4ZNQ/m/fFdIxt7rCwAJ
I am of the opinion, either have a parameter in IK command of the SMConsole to adjust the parity at input and log appropriate info when adjusted.
or
Change decryptDesKey to adjust parity and use it instead of throwing the exception.
jPOS/jpos/src/main/java/org/jpos/security/jceadapter/JCEHandler.java
Lines 186 to 193 in 096227e
encryptDeskey adjusts the parity and uses the adjusted cryptogram.
jPOS/jpos/src/main/java/org/jpos/security/jceadapter/JCEHandler.java
Lines 140 to 145 in 096227e
The text was updated successfully, but these errors were encountered: