Hi,
I have written this patch to be used with a hardware Crypto PKCS#11
accelerator
which can store keys. It is used in my company in TrustWay SSL accelerator
and,
TrustWay Apache-SSL accelerator with the Bull PCI CC2000 HSM.
Our HSM doesn't require C_Login. I believe that call to C_Login is mandat
Hi, I am having problems with CHOICE in the following ASN.1 sequence:
-
DEFINITIONS IMPLICIT TAGS
Sub_seq200 ::= SEQUENCE
{
sub_field1 Sub_seq100 OPTIONAL,
sub_field2 [0] Sub_seq400 OPTIONAL
}
Seq1 ::= CHOICE
Hi !
When trying to build 0.9.7b fresh from the tarball by entering
ms\mingw32 on the cmd-prompt it stopped right before building
the static libraries when trying to remove the old ones.
My environment:
gcc.exe (GCC) 3.2.3 (mingw special 20030504-1)
Windows 2000 Professional fp3
openssl-0.9.7b
A
In message <[EMAIL PROTECTED]> on Thu, 26 Jun 2003 13:38:45 +0200, "Michael Gerdau"
<[EMAIL PROTECTED]> said:
mgd> Applying the following patch did solve the problem. I have not
mgd> checked wether this might happen with other Win32 environments too.
mgd>
mgd> diff -ur openssl-0.9.7b-orig/util/p
Fernando,
I think all user-defined tags in a CHOICE (e.g., [0]) are EXPLICIT -- I could be wrong
and don't have time to check right now (it's been a while ...).
So I think you want:
ASN1_EXP(Seq1, value.field2,Sub_seq200, 0)
Frank
On Thu, Jun 26, 2003, Fernando Moya wrote:
> Hi, I am having problems with CHOICE in the following ASN.1 sequence:
>
> -
> DEFINITIONS IMPLICIT TAGS
>
> Sub_seq200 ::= SEQUENCE
> {
> sub_field1 Sub_seq100 OPTIONAL,
>
On Thu, Jun 26, 2003, Frank Balluffi wrote:
>
> Fernando,
>
> I think all user-defined tags in a CHOICE (e.g., [0]) are EXPLICIT -- I could be
> wrong and don't have time to check right now (it's been a while ...).
>
> So I think you want:
>
> ASN1_EXP(Seq1, value.field2,Sub_seq200, 0)
>
Th
My bad. The following attempts to describe EXPLICIT tagging of elements of type CHOICE:
FOO DEFINITIONS EXPLICIT TAGS ::=
BEGIN
Foo ::= SEQUENCE
{
foo1 [0] EXPLICIT Goo,
foo2 [1] IMPLICIT Goo -- Error: foo2 must be explicitly tagged.
}
Goo ::= CHOICE
{
integer1 [0] IMPLICIT INTEGE
Thus spake "David Maurus" <[EMAIL PROTECTED]>
> Stephen Sprunk wrote:
> >In the specification of CTR mode, as proposed for AES, you will find the
> >statement "The number /nonce/ is incremented following each encryption."
> >I interpreted this to mean that the top 2^64 bits are to be incremented
fo
Thus spake "Michael Sierchio" <[EMAIL PROTECTED]>
> Argument: let's write an Internet draft that describes the use of AES CTR
> mode in SSLv3/TLSv1. We can do it however we like, modulo the usual
> criticism and review in the IETF working group(s).
>
> Comments? Rich? Richard? Stephen?
I'm a
Actually, SRTP was the first time I saw CTR mode and I believe it predates
NIST (i could be wy wrong there).
In SRTP, the counter is only 16 bits but that doesn't limit them to only
encrypting 64K blocks of data, it only limits them to 64K blocks *in one
rtp(udp) packet*. Obviously this isn't
Brian C Morris wrote:
>
> Hi -
>
> We're entertaining the possibility of porting openssl to the AS/400
> (iSeries).
>
> It seems from searching the archives this effort has been started before
> - but I assume not finished as I don't see reference to the platform in
> the code?
>
> Is there st
In message <[EMAIL PROTECTED]> on Thu, 26 Jun 2003 12:55:22 -0400, "Lee Dilkie"
<[EMAIL PROTECTED]> said:
lee_dilkie> What I was trying (unsuccessfully) to make a point
lee_dilkie> about. Please don't code up your CTR mode to *just* do the
lee_dilkie> NIST or Ipsec version of CTR mode. Please cod
Hello Richard,
Richard Levitte - VMS Whacker wrote:
In message <[EMAIL PROTECTED]>
on Thu, 26 Jun 2003 12:55:22 -0400, "Lee Dilkie" <[EMAIL PROTECTED]> said:
OK, I've been follownig this discussion for a while, and it's time I
ake action. Basically, to provide for all the current and future way
Steven,
Stephen Sprunk wrote:
Thus spake "David Maurus" <[EMAIL PROTECTED]>
I assume that 'number /nonce/' should mean the result of the
concatenated parts of the IV.
No, in the proposal to NIST (by Lipmaa, Rogaway and Wagner), 'nonce' refers
to the top 64 bits and 'ctr' refers to the low
Götz Babin-Ebell wrote:
The application specifies 4 datas:
1. a step size
2. a bit mask.
3. a (optional) pointer to a function that is called if the
step bits that are not in the bit mask:
4. a (optional) pointer to a function doing the counting;
> if (pCounter->Range)
> return pCounter->Range(pCo
Stephen Sprunk wrote:
I'm a bit more ambitious... We should specify NIST-style CTR mode for all
octet stream applications within the IETF's domain, with SSL/TLS as an
example. For record-based systems, I don't know if NIST-style or
IPsec-style would be more appropriate :-(
There is no such thing
Richard Levitte - VMS Whacker wrote:
OK, I've been follownig this discussion for a while, and it's time I
ake action. Basically, to provide for all the current and future ways
of handling the IV, I can see three alternatives:
- have the application provide a function that manipulates the IV.
- ha
In message <[EMAIL PROTECTED]> on Thu, 26 Jun 2003 13:31:37 -0700, Michael Sierchio
<[EMAIL PROTECTED]> said:
kudzu> Richard Levitte - VMS Whacker wrote:
kudzu>
kudzu> > OK, I've been follownig this discussion for a while, and it's time I
kudzu> > ake action. Basically, to provide for all the c
Richard Levitte - VMS Whacker wrote:
Whatever, I used the terms like this:
- IV is a bitstring of some sort (possibly random), of the same size
as the crypto algorithm block. In the AES case, it would be 128
bits.
- For CTR mode, the counter is a part of the IV. The rest of the IV
is some
20 matches
Mail list logo